Марк Кокс (Mark J. Cox), возглавляющий команду, занимающуюся решением проблем безопасности в продуктах Red Hat, представил (http://www.awe.com/mark/blog/20110817.html) подробный отчет (http://www.redhat.com/f/pdf/security/RHEL4_RiskReport_6yr_wp...) (PDF, 600 Кб) в котором представлен анализ уязвимостей, исправленных за шесть лет существования дистрибутива Red Hat Enterprise Linux 4. В отчете анализируется степень риска при игнорировании обновлений с устранением проблем безопасности и оценка влияния отдельных уязвимостей на защищенность системы.URL: http://www.awe.com/mark/blog/20110817.html
Новость: http://www.opennet.me/opennews/art.shtml?num=31548
На правах конспирологии: знаменитейшее проникновение в серверы RedHat в 2008 CVE-2008-3844 , намек на то что у кого то из топовых разработчиков по просту сперли пароли, странный уход второго человека в иерархии ядра Alan Cox в интел (не выдержал пыток водой при внутреннем расследовании? ) ... До этого случая часто на вопрос "почему выбрали RedHAt" отвечали "потому что Alan Cox".
Что самое забавное, клиенты вроде как не пострадали а все меры типа смены ключей носили профилактический характер. В общем то логично что в таком случае лучше перебдеть.
Насколько я помню, ключи они не меняли.
Мозиловцы вместо того, чтобы в писюльки играть с убиранием версии из About, да в догонялки с хромом аудитом кода лучше бы занялись. Досадно, что альтернатив-то нет.
> Досадно, что альтернатив-то нет.SLES/Debian/AIX/Solaris/SCO OpenServer/MacOS/Windows ...
> SLES/Debian/AIX/Solaris/SCO OpenServer/MacOS/Windows ...Павлин а мозила то тут каким боком и их проблемы с аудитом?
>> SLES/Debian/AIX/Solaris/SCO OpenServer/MacOS/Windows ...
> Павлин а мозила то тут каким боком и их проблемы с аудитом?да ему всё-равно. Главное вбросить! )
тема вроде "Red Hat Enterprise Linux 4"
>тема вроде "Red Hat Enterprise Linux 4"Да вы настоящий Ъ - вам достаточно прочитать только заголовок, и можно уже смело врубаться в обсуждение.
По моим наблюдениям, это общая болезнь всех браузеров. Если бы в репах RHEL числились хромиум и опера, и их разработчики не замалчивали бы об уязвимостях, фуррифоксу бы пришлось потесниться на доске почета.
Может и так, но я, посмотрев на эту статистику, подумал: "Может хромиум везде, где можно, использовать?". В хроме ведь постоянно пишут: "Мы поправили 30 ошибок, из них 7 опасных, но ни одной критической. Из нашего сандбокса хрен сбежишь!".
Очередной пиар ход от RedHat. "ах смотрите какие мы клевые"..
стоит только посмотреть на статистику.
ядро - 154 уязвимости и не одной критической?!А как же local root которые были? или это не фига не критическое для какого нить хостинга ?
>Очередной пиар ход от RedHat...Негодяи! Ну делают какие-то исследования - пусть делают МОЛЧА! Нафиг всем сообщать!!!
Эти негодяи еще после каждого обновления имеют наглость сообщать об этом root'у... Как будто сисадминам делать больше нечего, кроме как читать подобные отчеты...
>>Очередной пиар ход от RedHat...
> Негодяи! Ну делают какие-то исследования - пусть делают МОЛЧА! Нафиг всем сообщать!!!
> Эти негодяи еще после каждого обновления имеют наглость сообщать об этом root'у...
> Как будто сисадминам делать больше нечего, кроме как читать подобные отчеты...Именно что негодяи. Показывающие исследования с подтасовкой фактов.
Хотя видимо вы верите безоговорочно в то что говорит RedHat и не пытаетесь критически оценивать это ?Как можно верить отчету который не называет критическими уязвимостями local root для которого эксплойт был в публичном доступе ?!
> Как можно верить отчету который не называет критическими уязвимостями local root для
> которого эксплойт был в публичном доступе ?!Вот только этот эксплойт на RHEL4 почему-то не работал.
>Именно что негодяи. Показывающие исследования с подтасовкой фактов.
Ваша некомпетентность не дает вам права называть негодяями компетентных специалистов.
Ой ли? может вы не смогли поправить некоторые настройки. после чего оно вполне себе работало.
>Очередной пиар ход от RedHat. "ах смотрите какие мы клевые"..Очередной вброс от фанов Oracle. "ах смотрите какие нехорошие у нас конкуренты"
>>Очередной пиар ход от RedHat. "ах смотрите какие мы клевые"..
> Очередной вброс от фанов Oracle. "ах смотрите какие нехорошие у нас конкуренты"за любым критическим замечанием видим след Оракла ? а вас параноя еще не замучала ?
так спуститесь с небес на землю. Поищите в гугл 2.6.9 security vulnerable и умилитесь тому столько вещей в открытом доступе.
> за любым критическим замечанием видим след Оракла ? а вас параноя еще не замучала ?Когда вместо критики идет наглая подтасовка фактов и обман публики - понятно, что оракловы уши торчат.
> так спуститесь с небес на землю. Поищите в гугл 2.6.9 security vulnerable
> и умилитесь тому столько вещей в открытом доступе.Вот только при чем здесь RHEL4? Там эти чудо-сплойты почему-то никогда не работали.
>> за любым критическим замечанием видим след Оракла ? а вас параноя еще не замучала ?
> Когда вместо критики идет наглая подтасовка фактов и обман публики - понятно,
> что оракловы уши торчат.ой. какая параноя.
>> так спуститесь с небес на землю. Поищите в гугл 2.6.9 security vulnerable
>> и умилитесь тому столько вещей в открытом доступе.
> Вот только при чем здесь RHEL4? Там эти чудо-сплойты почему-то никогда не
> работали.А вы не в курсе? RHEL4 это 2.6.9, если отсортировать то что идет только на vanila - можно найти стопку тех которые именно под RHEL4.
А то что они не работали - так может просто руки кривые и не смогли правильно их собрать ?
А вы не стесняйтесь, напомните :)Что там за local root такой был, к которому уязвим RHEL 4?
1. http://forum.openvz.org/index.php?t=msg&goto=7368&
2. https://bugzilla.redhat.com/show_bug.cgi?id=634457
3. http://webcache.googleusercontent.com/search?q=cache:lQqDmUN...дальше будем искать ?
И при этом не одной критической уязвимости ?!
> И при этом не одной критической уязвимости ?!Red Hat не считает эту уязвимость критической:
https://rhn.redhat.com/errata/RHSA-2010-0718.html "Severity: Important"
В CVE вес тоже небольшой "Base Score: 7.2"Видимо это из-за того, что проявляется дыра только на 64-разрядных системах с установленной "32-bit compatibility" прослойкой, которая не ставится по дефолту в RHEL 4.
32bit compat ставится в RHEL4.
То, что баг в левом openvz ядре (или каком-нибудь centosplus) - не фактор. RHEL4 багу не подвержен, т.к. там не было той функции, а фикс выпустили "на будущее", чтобы другую лазейку вдруг не обнаружили: https://access.redhat.com/kb/docs/DOC-40265
> То, что баг в левом openvz ядре (или каком-нибудь centosplus) - не
> фактор. RHEL4 багу не подвержен, т.к. там не было той функции,
> а фикс выпустили "на будущее", чтобы другую лазейку вдруг не обнаружили:
> https://access.redhat.com/kb/docs/DOC-40265Наверно читать и ходить по ссылкам не модно? но вы не стесняйтесь - никто вас за это не осудит.
прямая ссылка на эксплойт
http://isc.sans.edu/diary.html?storyid=1482
>>>This vulnerability enables an attacker to get elevated privileges on a local machine. There have been several exploits released and we can confirm that they work. We've tested this on unpatched SuSE and RedHat Enterprise Linux machines:
>>>Слово RedHat Enterprise вам тут не понятно ?
А остальные ссылки надеюсь понятны ? в третей так вобще готовый эксплойт.можно еще вспомнить стопку NULL pointer deref + атака продемонтрированная позже и которая позволяла выполнить любой код. А NULL pointer deref было много.
> This vulnerability enables an attacker to get elevated privileges on a local
> machine. There have been several exploits released and we can confirm
> that they work. We've tested this on unpatched SuSE and RedHat
> Enterprise Linux machines:Точно помню, что на RHEL4 это чудо не срабатывало. Очевидно, индус Баян звездит.
>> This vulnerability enables an attacker to get elevated privileges on a local
>> machine. There have been several exploits released and we can confirm
>> that they work. We've tested this on unpatched SuSE and RedHat
>> Enterprise Linux machines:
> Точно помню, что на RHEL4 это чудо не срабатывало. Очевидно, индус Баян
> звездит.А я помню что работало ;-) кому верить ?
> То, что баг в левом openvz ядре (или каком-нибудь centosplus) - не
> фактор. RHEL4 багу не подвержен, т.к. там не было той функции,
> а фикс выпустили "на будущее", чтобы другую лазейку вдруг не обнаружили:
> https://access.redhat.com/kb/docs/DOC-40265http://www.cvedetails.com/cve/CVE-2006-5753/
http://www.cvedetails.com/cve/CVE-2005-0750/
http://www.cvedetails.com/cve/CVE-2005-0091/
http://www.cvedetails.com/cve/CVE-2005-0736/это только часть того что в ядре связанное с увеличением привелегий.
И все - не критичные..
Может просто им стыдно признаться что у них столько дырок ?
А вот число 0 - выглядело бы интереснее?
> это только часть того что в ядре связанное с увеличением привелегий.
> И все - не критичные..Раз не критичные, значит, их эксплуатация конкретно в RHEL4 малореальна, только и всего.
>> это только часть того что в ядре связанное с увеличением привелегий.
>> И все - не критичные..
> Раз не критичные, значит, их эксплуатация конкретно в RHEL4 малореальна, только и
> всего.Да? А по моему кто-то просто занижает статистику что бы выглядеть привлекательными.
Никто и не отрицает того, что они были. В отчете честно отмечено:>Для 80 уязвимостей в публичном доступе можно было найти готовый эксплоит, но для применения большинства из них требовалось изменение настроек по умолчанию или стимулирование пользователя к выполнению определенных действий. При этом удачное выполнение большого числа из данных эксплоитов блокировалось стандартными механизмами безопасности RHEL 4. 15 эксплоитов использовали ошибки в Linux-ядре
> Никто и не отрицает того, что они были. В отчете честно отмечено:
>>Для 80 уязвимостей в публичном доступе можно было найти готовый эксплоит, но для применения большинства из них требовалось изменение настроек по умолчанию или стимулирование пользователя к выполнению определенных действий. При этом удачное выполнение большого числа из данных эксплоитов блокировалось стандартными механизмами безопасности RHEL 4. 15 эксплоитов использовали ошибки в Linux-ядре
>Если не отрицают - почему в поле "критические уязвимости" стоит 0 ?
Или дырка для которой были публичные эксплойты - не является критической?
Тогда что является критической?
Упорство конечно дело благородное, но мозг включать тоже полезно. Если не проделывать тех действий к которым надо "стимулировать пользователя", то вот же незадача, стандартная система безопасности RHEL4 успешно их блокировала, новость не так ли?
Да и как видно из отчета, основная проблема по прежнему именно в браузерах, что на винде, что на Linux, и надо сказать это достаточно печально.
Вот вот - мозг включать надо.
Если сторонние источники говорят - что данная дырка позволяла поднять привилегии в системе.
А RedHat говорит что это не критическая бага - то что-то в консерватории не так.
Red Hat Enterprise Linux 4 and Red Hat Enterprise MRG are not affected by the publicly-circulated exploit.The Red Hat Enterprise Linux 4 and Red Hat Enterprise MRG kernels do not include a backport of the upstream git commit 42908c69; therefore, those kernels do not include compat_mc_getsockopt(). However, it may be possible to abuse this in other areas of the Linux kernel. We plan to backport the missing compat_alloc_user_space() sanity checks in future Red Hat Enterprise Linux 4 and Red Hat Enterprise MRG updates.