The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Оценка рисков, связанных с уязвимостями в Red Hat Enterprise Linux 4

20.08.2011 13:32

Марк Кокс (Mark J. Cox), возглавляющий команду, занимающуюся решением проблем безопасности в продуктах Red Hat, представил подробный отчет (PDF, 600 Кб) в котором представлен анализ уязвимостей, исправленных за шесть лет существования дистрибутива Red Hat Enterprise Linux 4. В отчете анализируется степень риска при игнорировании обновлений с устранением проблем безопасности и оценка влияния отдельных уязвимостей на защищенность системы.

Следует отметить две важных особенности, отличающих подход Red Hat от других вендоров. Во первых, в Red Hat критический статус присваивается не только проблемам, подверженным удаленным атакам, но и уязвимостям которые могут эксплуатироваться автоматически (например, в результате активности червей), а так же уязвимостям, которые могут привести к выполнению кода злоумышленника в процессе работы пользователя (например, уязвимости в web-браузерах). Во вторых, Red Hat заводит CVE-идентификаторы для всех без исключения узявимостей, не делая исключений для проблем, найденных собственными силами. Это существенно отличает Red Hat от таких компаний как Microsoft и Adobe, которые умалчивают информацию о проблемах безопасности, найденных в процессе внутреннего аудита, и придают огласке только уязвимости, информация о наличии которых поступила со стороны. Например, в последнем обновлении Flash-плеера было официально устранено 13 уязвимостей, хотя фактически было исправлено около 400 проблем безопасности.

Используемая в Red Hat политика полной открытости в области устранения уязвимостей, позволяет пользователям дистрибутива реально оценить имеющиеся риски, а не полагаться на случай, как происходит при использовании продуктов, уязвимости в которых исправляются скрыто. Следует отметить, что многие открытые проекты также практикуют скрытое устранение уязвимостей или, как ядро Linux, принципиально не делают отличий между проблемами влияющими на безопасность и исправлениями, устраняющих безобидные ошибки.

Отмечается, что в наборе пакетов, устанавливаемых по умолчанию в серверной редакции RHEL 4 AS, за всю историю было найдено 20 критических уязвимостей. При рассмотрении всех пакетов из репозитория RHEL 4 AS число критических уязвимостей составляет 252 (из них 227 - уязвимости в web-браузерах). В устанавливаемом по умолчанию наборе пакетов в редакции дистрибутива для настольных систем RHEL 4 AS в сумме найдено 247 уязвимостей.

Распределение критических ошибок по группам пакетов:

  • Продукты Mozilla (Firefox, Mozilla, SeaMonkey, Thunderbird) - 194 (среднее время выхода обновления - в тот же день)
  • Media Player Plugin (HelixPlayer) - 25 (среднее время выхода обновления - 21 день)
  • Другие web-браузеры (Lynx, Links, KDE, Qt) - 8 (обновления вышли в день обнаружения проблемы)
  • Другое ПО (Samba, Exim, Sendmail, Pidgin, kerberos, openssh, dhcp, ntp, evolution) - 25 (обновления вышли в день обнаружения проблемы)

Десять самых опасных приложений:

  1. firefox - 185 критических/34 опасных проблем;
  2. mozilla/seamonkey - 148/26
  3. thunderbird - 49/22
  4. ядро Linux - 0/154
  5. HelixPlayer - 25/0
  6. samba - 6/2
  7. cups - 0/34
  8. krb5 - 4/11
  9. kdegraphics - 0/31
  10. xpdf - 0/30

Некоторые выводы:

  • 85% критических ошибок были исправлены не позднее чем через 1 день после публичного обнародования уязвимости;
  • Для 80 уязвимостей в публичном доступе можно было найти готовый эксплоит, но для применения большинства из них требовалось изменение настроек по умолчанию или стимулирование пользователя к выполнению определенных действий. При этом удачное выполнение большого числа из данных эксплоитов блокировалось стандартными механизмами безопасности RHEL 4. 15 эксплоитов использовали ошибки в Linux-ядре, 22 - в web-браузерах, 8 - в PHP скриптах, 13 - в сетевых сервисах, остальные в пользовательских приложениях;
  • Наиболее вероятным исходом использования готовых эксплоитов для неисправленной уязвимости является получения прав root локальным пользователем. Наиболее опасным признан эксплоит позволяющий удаленно получть root-доступ через почтовый сервер Exim;
  • За историю существования дистрибутива RHEL4 зафиксировано два самораспространяющихся червя, но они поражали систему только через сторонние web-приложения на языке PHP, не входящие в репозитории RHEL;
  • При использовании пользователями словарных паролей было зафиксировано несколько успешных "Brute force" атак, при которых пароли были подобраны через SSH.
  • По данным Red Hat для 51.5% из всех исправленных в RHEL 4 уязвимостей изначально информация не была сразу публично обнародована разработчиками. Из них, в 25.1% случаях информация об уязвимости была получена из рук разработчиков проектов, которые предварительно уведомили дистрибутивы, до момента придания широкой огласки. В 16.3% случаев данные об уязвимостях были получены в процессе взаимодействия с вендорами (другими дистрибутивами). 5.5% проблем было выявлено сотрудниками Red Hat. В 4.6% случаях были получены иные виды уведомлений. В среднем данные по публично необнародованным уязвимостям стали известны общественности только через 23 дня после того, как работники Red Hat уже имели информацию об их наличии.
  • 48.5% уязвимостей были исправлены после того как информация по ним была опубликована публично. При этом, данные по наличию таких уязвимостей в 24.8% случаев были получены из специализированных списков рассылки, 12.8% - получено уведомление от других вендоров (производителей других дистрибутивов), 6.3% - через CVE-уведомления, 2.8% - присланы иные уведомления, 1.7% - найдены сотрудниками Red Hat.

Дополнительно, могут представлять интерес два других отчета Red Hat. Доступен отчет об уязвимостях, исправленных за 6 месяцев после релиза RHEL 5.6, но до выхода релиза RHEL 5.7. За указанный период в пакетах, устанавливаемых по умолчанию, было найдено 109 уязвимостей (во всех пакетах - 172 уязвимости). Из опасных проблем отмечаются уязвимости в OpenJDK, Firefox, dhcp и glibc. Кроме того, представлен отчет с обзором наиболее опасных проблем безопасности за 2010 год, которым присвоен уровень опасности от 7 до 10. Большинство из упомянутых в отчете проблем найдены в ядре Linux. Также упомнянуты: openswan, openssh, systemtap, kvm, xorg-x11-serve, samba, cobbler, glibc, openssl и exim. Единственной проблемой, которой был присвоен 10 уровень опасности стала уязвимость в Kerberos 5.

  1. Главная ссылка к новости (http://www.awe.com/mark/blog/2...)
  2. OpenNews: Анализ рисков, связанных с проблемами безопасности в Red Hat Enterprise Linux 4
  3. OpenNews: Рейтинг самых опасных ошибок, зафиксированных в 2009 году
  4. OpenNews: Анализ проблем безопасности и оценка времени поддержки Red Hat Enterprise Linux
  5. OpenNews: Анализ рисков, связанных с проблемами безопасности в Red Hat Enterprise Linux
  6. OpenNews: В Adobe Flash 10.3.183.5 устранено 400 потенциальных уязвимостей (дополнено)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/31548-redhat
Ключевые слова: redhat, security, rhel
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (36) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, anonymous (??), 14:56, 20/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    На правах конспирологии: знаменитейшее проникновение в серверы RedHat в 2008 CVE-2008-3844 , намек на то что у кого то из топовых разработчиков по просту сперли пароли, странный уход второго человека в иерархии ядра Alan Cox в интел (не выдержал пыток водой при внутреннем расследовании? ) ... До этого случая часто на вопрос "почему выбрали RedHAt" отвечали "потому что Alan Cox".
     
     
  • 2.4, Аноним (-), 15:26, 20/08/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Что самое забавное, клиенты вроде как не пострадали а все меры типа смены ключей носили профилактический характер. В общем то логично что в таком случае лучше перебдеть.
     
     
  • 3.22, коксюзер (?), 02:47, 22/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько я помню, ключи они не меняли.
     

  • 1.8, анон (?), 20:15, 20/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Мозиловцы вместо того, чтобы в писюльки играть с убиранием версии из About, да в догонялки с хромом аудитом кода лучше бы занялись. Досадно, что альтернатив-то нет.
     
     
  • 2.10, pavlinux (ok), 20:41, 20/08/2011 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > Досадно, что альтернатив-то нет.

    SLES/Debian/AIX/Solaris/SCO OpenServer/MacOS/Windows ...

     
     
  • 3.11, klalafuda (?), 21:00, 20/08/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > SLES/Debian/AIX/Solaris/SCO OpenServer/MacOS/Windows ...

    Павлин а мозила то тут каким боком и их проблемы с аудитом?

     
     
  • 4.12, анон (?), 23:01, 20/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> SLES/Debian/AIX/Solaris/SCO OpenServer/MacOS/Windows ...
    > Павлин а мозила то тут каким боком и их проблемы с аудитом?

    да ему всё-равно. Главное вбросить! )

     
  • 4.14, pavlinux (ok), 01:08, 21/08/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    тема вроде "Red Hat Enterprise Linux 4"
     
     
  • 5.15, Аноним (-), 02:37, 21/08/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >тема вроде "Red Hat Enterprise Linux 4"

    Да вы настоящий Ъ - вам достаточно прочитать только заголовок, и можно уже смело врубаться в обсуждение.

     
  • 2.13, Аноним (-), 01:01, 21/08/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    По моим наблюдениям, это общая болезнь всех браузеров. Если бы в репах RHEL числились хромиум и опера, и их разработчики не замалчивали бы об уязвимостях, фуррифоксу бы пришлось потесниться на доске почета.
     
     
  • 3.42, Sergey722 (ok), 09:39, 23/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Может и так, но я, посмотрев на эту статистику, подумал: "Может хромиум везде, где можно, использовать?". В хроме ведь постоянно пишут: "Мы поправили 30 ошибок, из них 7 опасных, но ни одной критической. Из нашего сандбокса хрен сбежишь!".
     

  • 1.16, Аноним (-), 09:34, 21/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Очередной пиар ход от RedHat. "ах смотрите какие мы клевые"..
    стоит только посмотреть на статистику.
    ядро - 154 уязвимости и не одной критической?!

    А как же local root которые были? или это не фига не критическое для какого нить хостинга ?

     
     
  • 2.17, konst (??), 09:50, 21/08/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Очередной пиар ход от RedHat...

    Негодяи! Ну делают какие-то исследования - пусть делают МОЛЧА! Нафиг всем сообщать!!!
    Эти негодяи еще после каждого обновления имеют наглость сообщать об этом root'у... Как будто сисадминам делать больше нечего, кроме как читать подобные отчеты...

     
     
  • 3.24, Аноним (-), 10:10, 22/08/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>Очередной пиар ход от RedHat...
    > Негодяи! Ну делают какие-то исследования - пусть делают МОЛЧА! Нафиг всем сообщать!!!
    > Эти негодяи еще после каждого обновления имеют наглость сообщать об этом root'у...
    > Как будто сисадминам делать больше нечего, кроме как читать подобные отчеты...

    Именно что негодяи. Показывающие исследования с подтасовкой фактов.
    Хотя видимо вы верите безоговорочно в то что говорит RedHat и не пытаетесь критически оценивать это ?

    Как можно верить отчету который не называет критическими уязвимостями local root для которого эксплойт был в публичном доступе ?!

     
     
  • 4.32, Аноним (-), 15:52, 22/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Как можно верить отчету который не называет критическими уязвимостями local root для
    > которого эксплойт был в публичном доступе ?!

    Вот только этот эксплойт на RHEL4 почему-то не работал.

    >Именно что негодяи. Показывающие исследования с подтасовкой фактов.

    Ваша некомпетентность не дает вам права называть негодяями компетентных специалистов.

     
     
  • 5.37, Аноним (-), 09:14, 23/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ой ли? может вы не смогли поправить некоторые настройки. после чего оно вполне себе работало.
     
  • 2.19, Аноним (-), 17:35, 21/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Очередной пиар ход от RedHat. "ах смотрите какие мы клевые"..

    Очередной вброс от фанов Oracle. "ах смотрите какие нехорошие у нас конкуренты"

     
     
  • 3.25, Аноним (-), 10:13, 22/08/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >>Очередной пиар ход от RedHat. "ах смотрите какие мы клевые"..
    > Очередной вброс от фанов Oracle. "ах смотрите какие нехорошие у нас конкуренты"

    за любым критическим замечанием видим след Оракла ? а вас параноя еще не замучала ?
    так спуститесь с небес на землю. Поищите в гугл 2.6.9 security vulnerable и умилитесь тому столько вещей в открытом доступе.

     
     
  • 4.33, Аноним (-), 15:54, 22/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > за любым критическим замечанием видим след Оракла ? а вас параноя еще не замучала ?

    Когда вместо критики идет наглая подтасовка фактов и обман публики - понятно, что оракловы уши торчат.

    > так спуститесь с небес на землю. Поищите в гугл 2.6.9 security vulnerable
    > и умилитесь тому столько вещей в открытом доступе.

    Вот только при чем здесь RHEL4? Там эти чудо-сплойты почему-то никогда не работали.

     
     
  • 5.38, Аноним (-), 09:16, 23/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> за любым критическим замечанием видим след Оракла ? а вас параноя еще не замучала ?
    > Когда вместо критики идет наглая подтасовка фактов и обман публики - понятно,
    > что оракловы уши торчат.

    ой. какая параноя.

    >> так спуститесь с небес на землю. Поищите в гугл 2.6.9 security vulnerable
    >> и умилитесь тому столько вещей в открытом доступе.
    > Вот только при чем здесь RHEL4? Там эти чудо-сплойты почему-то никогда не
    > работали.

    А вы не в курсе? RHEL4 это 2.6.9, если отсортировать то что идет только на vanila - можно найти стопку тех которые именно под  RHEL4.
    А то что они не работали - так может просто руки кривые и не смогли правильно их собрать ?

     
  • 2.20, anonymous (??), 20:34, 21/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А вы не стесняйтесь, напомните :)

    Что там за local root такой был, к которому уязвим RHEL 4?

     
     
  • 3.23, Аноним (-), 10:07, 22/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    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:lQqDmUND6uIJ:www.xakep.r

    дальше будем искать ?

    И при этом не одной критической уязвимости ?!

     
     
  • 4.26, Аноним (-), 11:31, 22/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > И при этом не одной критической уязвимости ?!

    Red Hat не считает эту уязвимость критической:
    https://rhn.redhat.com/errata/RHSA-2010-0718.html "Severity: Important"
    В CVE вес тоже небольшой "Base Score: 7.2"

    Видимо это из-за того, что проявляется дыра только на 64-разрядных системах с установленной "32-bit compatibility" прослойкой, которая не ставится по дефолту в RHEL 4.

     
     
  • 5.28, Аноним (-), 15:28, 22/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    32bit compat ставится в RHEL4.

     
  • 4.27, anonymous (??), 14:00, 22/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    То, что баг в левом openvz ядре (или каком-нибудь centosplus) - не фактор. RHEL4 багу не подвержен, т.к. там не было той функции, а фикс выпустили "на будущее", чтобы другую лазейку вдруг не обнаружили: https://access.redhat.com/kb/docs/DOC-40265
     
     
  • 5.29, Аноним (-), 15:39, 22/08/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > То, что баг в левом 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 было много.

     
     
  • 6.34, Аноним (-), 15:59, 22/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > 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 это чудо не срабатывало. Очевидно, индус Баян звездит.

     
     
  • 7.39, Аноним (-), 09:16, 23/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> 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 это чудо не срабатывало. Очевидно, индус Баян
    > звездит.

    А я помню что работало ;-) кому верить ?


     
  • 5.30, Аноним (-), 15:44, 22/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > То, что баг в левом openvz ядре (или каком-нибудь centosplus) - не
    > фактор. RHEL4 багу не подвержен, т.к. там не было той функции,
    > а фикс выпустили "на будущее", чтобы другую лазейку вдруг не обнаружили:
    > https://access.redhat.com/kb/docs/DOC-40265

    http://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 - выглядело бы интереснее?

     
     
  • 6.35, Аноним (-), 16:03, 22/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > это только часть того что в ядре связанное с увеличением привелегий.
    > И все - не критичные..

    Раз не критичные, значит, их эксплуатация конкретно в RHEL4 малореальна, только и всего.

     
     
  • 7.41, Аноним (-), 09:18, 23/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> это только часть того что в ядре связанное с увеличением привелегий.
    >> И все - не критичные..
    > Раз не критичные, значит, их эксплуатация конкретно в RHEL4 малореальна, только и
    > всего.

    Да? А по моему кто-то просто занижает статистику что бы выглядеть привлекательными.

     
  • 6.36, Аноним (-), 16:20, 22/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Никто и не отрицает того, что они были. В отчете честно отмечено:

    >Для 80 уязвимостей в публичном доступе можно было найти готовый эксплоит, но для применения большинства из них требовалось изменение настроек по умолчанию или стимулирование пользователя к выполнению определенных действий. При этом удачное выполнение большого числа из данных эксплоитов блокировалось стандартными механизмами безопасности RHEL 4. 15 эксплоитов использовали ошибки в Linux-ядре

     

     
     
  • 7.40, Аноним (-), 09:17, 23/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Никто и не отрицает того, что они были. В отчете честно отмечено:
    >>Для 80 уязвимостей в публичном доступе можно было найти готовый эксплоит, но для применения большинства из них требовалось изменение настроек по умолчанию или стимулирование пользователя к выполнению определенных действий. При этом удачное выполнение большого числа из данных эксплоитов блокировалось стандартными механизмами безопасности RHEL 4. 15 эксплоитов использовали ошибки в Linux-ядре
    >  

    Если не отрицают - почему в поле "критические уязвимости" стоит 0 ?
    Или дырка для которой были публичные эксплойты - не является критической?
    Тогда что является критической?


     
     
  • 8.43, Diden05 (?), 18:55, 23/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Упорство конечно дело благородное, но мозг включать тоже полезно Если не продел... текст свёрнут, показать
     
     
  • 9.44, Аноним (-), 21:48, 23/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Вот вот - мозг включать надо Если сторонние источники говорят - что данная дырк... текст свёрнут, показать
     
  • 4.31, Аноним (-), 15:50, 22/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    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.

    https://access.redhat.com/kb/docs/DOC-40265

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру