The OpenNET Project / Index page

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

Уязвимости в Drupal, QEMU и Nagios

20.12.2012 10:25

Несколько недавно обнаруженных уязвимостей:

  • В стандартных компонентах, входящих в базовую поставку системы управления web-контентом Drupal, обнаружено несколько уязвимостей. Проблемы устранены в корректирующих выпусках Drupal 7.18 и 6.27.

    Уязвимость в модуле загрузки файлов из состава Drupal 6.x и 7.x позволяет удалённому злоумышленнику инициировать выполнение произвольного PHP-кода на сервере через обход механизмов проверки корректности имени загружаемого файла, что позволяет загрузить файл как скрипт .php и выполнить его через обращение по URL. Для успешной атаки злоумышленник должен иметь доступ к функциям загрузки файлов, а http-сервер не должен блокировать выполнение php-скриптов в директории, используемой для сохранения загружаемых данных (при использовании apache выполнение таких скриптов по умолчанию запрещается в поставляемом с Drupal файле .htaccess);

  • В коде эмуляции сетевого адаптера e1000, используемом в QEMU, qemu-kvm и Xen, исправлено переполнение буфера, которое может потенциально эксплуатироваться через отправку специально оформленных пакетов, адресованных извне в гостевое окружение. При наихудшем сценарии не исключена возможность выполнения кода с привилегиями ядра на стороне гостевой системы. Тем не менее, проблема помечена как неопасная, так как для успешного проведения атаки конфигурация сети должна допускать прохождение больших пакетов к гостевой системе, что нетипично. Проблема устранена в QEMU 1.3.
  • В web-интерфейсе системы мониторинга Nagios найдена уязвимость, позволяющая выполнить код на сервере через манипуляции с содержимым параметра "host" при обращении к скрипту history.cgi. Проблема подтверждена в версии 3.4.3, исправление пока недоступно.


  1. Главная ссылка к новости (http://seclists.org/fulldisclo...)
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: drupal, nagios, security
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (24) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, бедный буратино (ok), 10:40, 20/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > что позволяет загрузить файл как скрипт .php и выполнить его через обращение по URL

    Такие уязвимости в php будут всегда, что говорится "by design". Ведь на сегодня это единственная более-менее популярная веб-технология, работающая в режиме "что вижу, то и пою".

     
     
  • 2.3, jedie (?), 11:14, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    толсто
     
  • 2.4, Аноним (-), 11:20, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Cохранять полученный файл в паблик-директории сервера с именем, под которым его отправил пользователь — это не «by design», это «by идиотизм».
     
     
  • 3.5, б.б. (?), 11:38, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Причём здесь это? Можно через два года попасть на то, что часть корня сайта доступна для записи по ftp. Или ещё как, вариантов много. Т.е., веб-сервер "отражает" кучу файлов, и на некоторые у него при некоторых условиях могут быть права на запуск. Что вижу, то и пою. Ничего более идиотского для веба и придумать нельзя. Это так "по-русски", сделать проблему на ровном месте, а потом с пеной у рта защищать её, потому что "у нас свой путь". Никто так не делает, никто. И у всех нормальные роуты, и у всех нет "что вижу, то и пою", а у php "свой путь". Россия в мире ПО, только "пьют и воруют".
     
     
  • 4.6, Анончик (?), 11:52, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это скорее проблема стандартного способа использования с апачи. Правильно запиленный nginx и php-fpm позволят избежать такого бреда
     
     
  • 5.7, б.б. (?), 12:05, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Из-за неразберихи по тому, как именно разбирать запрос, есть проблемы с ссылками вида /index.php/hello/world, просто по причине того, что разбор с начала и разбор с конца дают РАЗНЫЕ результаты. Это php, детка :)
     
  • 4.10, metallic (ok), 14:27, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А казалось бы, причем тут политика?
     
     
  • 5.12, бедный буратино (ok), 15:08, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    не при чём. я говорил про истерику в политике а не про политику в истерики. это просто как пример, политика тут совсем не при чём.
     
     
  • 6.15, Аноним (-), 15:20, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > не при чём. я говорил про истерику в политике

    Пока что я вижу истерику по поводу пыха у одного деревянного субъекта. Который втирает как будто бы баги есть только в софте написанном на пыхе. Что, мягко говоря, вранье.

     
  • 4.11, Аноним (-), 14:50, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    э… спокойно, батенька. Какой ещё «путь», какая Россия, это вы к чему вообще?

    Все нормальные PHP-фреймворки давно пропускают все запросы к PHP через Front Controller. Ну загуглите на тему роутинга в Symfony1/2, ZF, да хоть Code Igniter. Короче, если хотите вести диалог, конкретизируйте свои претензии. И желательно без потока эмоций.

     
  • 4.14, Аноним (-), 15:18, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Причём здесь это? Можно через два года попасть на то, что часть
    > корня сайта доступна для записи по ftp.

    И что? Если некто может аплоадить произвольное файло на сайт - он, очевидно, может перезалить этот сайт. И? Пых виноват в кретинизме администратора? Буратино такое буратино.

     
     
  • 5.17, б.б. (?), 15:37, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >> И что? Если некто может аплоадить произвольное файло на сайт - он, очевидно, может перезалить этот сайт. И? Пых виноват в кретинизме администратора?

    Он может напортить это в системе "что вижу, то и пою".

    php виноват в том, что он единственный работает по такой схеме. и проблема в том, что там даже через три симлинка через независимый сайт может случайно попасть .php. И ОН ИСПОЛНИТСЯ, ПОТОМУ ЧТО PHP ДЕБИЛЕН ПО УМОЛЧАНИЮ. И там, где другим не нужно защищать, в php нужно. И это проблема. Даже в cgi исполнялись только файлы с chmod +x в /cgi-bin/, а php по умолчанию поётся ВЕЗДЕ. Это не дыра, это ДЫРИЩА. Дырища по имени php.

     
     
  • 6.22, зачем имя анониму (?), 21:35, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    1. попейте валерьянки
    2. перестаньте писать капсом
     
  • 4.24, Аноним (-), 03:58, 22/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Причём здесь это? Можно через два года попасть на то, что часть
    > корня сайта доступна для записи по ftp. Или ещё как, вариантов
    > много. Т.е., веб-сервер "отражает" кучу файлов, и на некоторые у него
    > при некоторых условиях могут быть права на запуск. Что вижу, то
    > и пою. Ничего более идиотского для веба и придумать нельзя. Это
    > так "по-русски", сделать проблему на ровном месте, а потом с пеной
    > у рта защищать её, потому что "у нас свой путь". Никто
    > так не делает, никто. И у всех нормальные роуты, и у
    > всех нет "что вижу, то и пою", а у php "свой
    > путь". Россия в мире ПО, только "пьют и воруют".

    открой для себя mod_perl и mod_python и черти знает, что еще.

     
  • 3.8, Andrey Mitrofanov (?), 12:35, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >это не «by design», это «by идиотизм».

    By Idiotten Disign! Не ссорьтесь, ма-альчики.

     
  • 2.13, Аноним (-), 15:17, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Такие уязвимости в php будут всегда, что говорится "by design".

    Странно. А чего же тогда в Zope дырки? Или вон яндекс недавно эпически облажался: http://habrahabr.ru/post/163039/

    Оказывается, это пых виноват. А вовсе не ж@порукие буратины. Вот если заменить пых на что-то еще - программисты сразу перестанут баги делать.

     

  • 1.2, Аноним (-), 10:45, 20/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    буквально на днях кто то написал "вот поэтому я использую друпал" и такой фейл!
     
     
  • 2.9, demimurych (ok), 12:46, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В установке Drupal, идет htaccess файл для apache который делает невозможным эксплуатировать уязвимость с аплоадом php файла.
    Это не совпадение, а сделано намеренно о чем сказано в самом htaccess файле.

    Используешь дургой сервер, будь добр внимательно ознакомиться с правилами установки.

     
  • 2.16, ОнанВарвар (?), 15:37, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Обновился :).
    фейла нет, ибо нет идеального кода.
     
  • 2.23, Michael Shigorin (ok), 01:05, 22/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > буквально на днях кто то написал "вот поэтому я использую друпал" и такой фейл!

    Кажется, там было в контексте дырок joomla (бишь совсем не fail, особенно с учётом характера проблемы в данном разе -- её предусмотрели, но возможность наступить на грабли с не-апачем осталась).

    Другое дело, что remote code exec штука крайне неприятная в любом проявлении -- однажды и на TYPO3 пришлось спешно подрываться и затыкать, лет пять тому, что ли.  И в этом плане не такая уж и разница -- веб-сервер не смотрит в .htaccess или в модуле ляп оказался...

     

  • 1.18, Аноним (-), 20:37, 20/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Меня всегда удивляет насколько яро можно говорить о негативных качествах PHP забывая при этом то что ошибки присуще любому ПО
     
     
  • 2.19, Andrey Mitrofanov (?), 21:20, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Меня всегда удивляет насколько яро можно говорить о негативных качествах PHP забывая
    > при этом то что ошибки присуще любому ПО

    Не всякому ПО прсуще свойство эти ошибки взращивать. Массово, постоянно и всенепременно.

     
     
  • 3.20, Аноним (-), 21:25, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это такой толстый намек на python?
     
     
  • 4.21, Andrey Mitrofanov (?), 21:27, 20/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Это такой толстый намек на python?

    На posix шел.

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



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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