Несколько недавно обнаруженных уязвимостей:- В стандартных компонентах, входящих в базовую поставку системы управления web-контентом Drupal (http://drupal.org/), обнаружено (http://seclists.org/fulldisclosure/2012/Dec/176) несколько уязвимостей (http://drupal.org/SA-CORE-2012-004). Проблемы устранены (http://drupal.org/drupal-7.18) в корректирующих выпусках Drupal 7.18 и 6.27.
Уязвимость в модуле загрузки файлов из состава Drupal 6.x и 7.x позволяет удалённому злоумышленнику инициировать выполнение произвольного PHP-кода на сервере через обход механизмов проверки корректности имени загружаемого файла, что позволяет загрузить файл как скрипт .php и выполнить его через обращение по URL. Для успешной атаки злоумышленник должен иметь доступ к функциям загрузки файлов, а http-сервер не должен блокировать выполнение php-скриптов в директории, используемой для сохранения загружаемых данных (при использовании apache выполнение таких скриптов по умолчанию запрещается в поставляемом с Drupal файле .htaccess);- В коде эмуляции сетевого адаптера e1000, используемом в QEMU, qemu-kvm и Xen, исправлено (http://permalink.gmane.org/gmane.comp.security.oss.general/9013) переполнение буфера, которое может быть потенциально эксплуатировано через отправку специально оформленных пакетов, адресованных из вне в гостевое окружение. При наихудшем сценарии не исключена возможность выполнения кода с привилегиями ядра на стороне гостевой системы. Тем не менее, проблема помечена как неопасная, так как для успешного проведения атаки конфигурация сети должна допускать прохождение больших пакетов к гостевой системе, что нетипично. Проблема устранена в QEMU 1.3.
- В web-интерфейсе системы мониторинга Nagios найдена уязвимость (http://archives.neohapsis.com/archives/fulldisclosure/2012-12), позволяющая выполнить код на сервере через манипуляции с содержимым параметра "host" при обращении к скрипту history.cgi. Проблема подтверждена в версии 3.4.3, исправление пока недоступно.
URL: http://seclists.org/fulldisclosure/2012/Dec/176
Новость: http://www.opennet.ru/opennews/art.shtml?num=35653
> что позволяет загрузить файл как скрипт .php и выполнить его через обращение по URLТакие уязвимости в php будут всегда, что говорится "by design". Ведь на сегодня это единственная более-менее популярная веб-технология, работающая в режиме "что вижу, то и пою".
толсто
Cохранять полученный файл в паблик-директории сервера с именем, под которым его отправил пользователь — это не «by design», это «by идиотизм».
Причём здесь это? Можно через два года попасть на то, что часть корня сайта доступна для записи по ftp. Или ещё как, вариантов много. Т.е., веб-сервер "отражает" кучу файлов, и на некоторые у него при некоторых условиях могут быть права на запуск. Что вижу, то и пою. Ничего более идиотского для веба и придумать нельзя. Это так "по-русски", сделать проблему на ровном месте, а потом с пеной у рта защищать её, потому что "у нас свой путь". Никто так не делает, никто. И у всех нормальные роуты, и у всех нет "что вижу, то и пою", а у php "свой путь". Россия в мире ПО, только "пьют и воруют".
Это скорее проблема стандартного способа использования с апачи. Правильно запиленный nginx и php-fpm позволят избежать такого бреда
Из-за неразберихи по тому, как именно разбирать запрос, есть проблемы с ссылками вида /index.php/hello/world, просто по причине того, что разбор с начала и разбор с конца дают РАЗНЫЕ результаты. Это php, детка :)
А казалось бы, причем тут политика?
не при чём. я говорил про истерику в политике а не про политику в истерики. это просто как пример, политика тут совсем не при чём.
> не при чём. я говорил про истерику в политикеПока что я вижу истерику по поводу пыха у одного деревянного субъекта. Который втирает как будто бы баги есть только в софте написанном на пыхе. Что, мягко говоря, вранье.
э… спокойно, батенька. Какой ещё «путь», какая Россия, это вы к чему вообще?Все нормальные PHP-фреймворки давно пропускают все запросы к PHP через Front Controller. Ну загуглите на тему роутинга в Symfony1/2, ZF, да хоть Code Igniter. Короче, если хотите вести диалог, конкретизируйте свои претензии. И желательно без потока эмоций.
> Причём здесь это? Можно через два года попасть на то, что часть
> корня сайта доступна для записи по ftp.И что? Если некто может аплоадить произвольное файло на сайт - он, очевидно, может перезалить этот сайт. И? Пых виноват в кретинизме администратора? Буратино такое буратино.
>> И что? Если некто может аплоадить произвольное файло на сайт - он, очевидно, может перезалить этот сайт. И? Пых виноват в кретинизме администратора?Он может напортить это в системе "что вижу, то и пою".
php виноват в том, что он единственный работает по такой схеме. и проблема в том, что там даже через три симлинка через независимый сайт может случайно попасть .php. И ОН ИСПОЛНИТСЯ, ПОТОМУ ЧТО PHP ДЕБИЛЕН ПО УМОЛЧАНИЮ. И там, где другим не нужно защищать, в php нужно. И это проблема. Даже в cgi исполнялись только файлы с chmod +x в /cgi-bin/, а php по умолчанию поётся ВЕЗДЕ. Это не дыра, это ДЫРИЩА. Дырища по имени php.
1. попейте валерьянки
2. перестаньте писать капсом
> Причём здесь это? Можно через два года попасть на то, что часть
> корня сайта доступна для записи по ftp. Или ещё как, вариантов
> много. Т.е., веб-сервер "отражает" кучу файлов, и на некоторые у него
> при некоторых условиях могут быть права на запуск. Что вижу, то
> и пою. Ничего более идиотского для веба и придумать нельзя. Это
> так "по-русски", сделать проблему на ровном месте, а потом с пеной
> у рта защищать её, потому что "у нас свой путь". Никто
> так не делает, никто. И у всех нормальные роуты, и у
> всех нет "что вижу, то и пою", а у php "свой
> путь". Россия в мире ПО, только "пьют и воруют".открой для себя mod_perl и mod_python и черти знает, что еще.
>это не «by design», это «by идиотизм».By Idiotten Disign! Не ссорьтесь, ма-альчики.
> Такие уязвимости в php будут всегда, что говорится "by design".Странно. А чего же тогда в Zope дырки? Или вон яндекс недавно эпически облажался: http://habrahabr.ru/post/163039/
Оказывается, это пых виноват. А вовсе не ж@порукие буратины. Вот если заменить пых на что-то еще - программисты сразу перестанут баги делать.
буквально на днях кто то написал "вот поэтому я использую друпал" и такой фейл!
В установке Drupal, идет htaccess файл для apache который делает невозможным эксплуатировать уязвимость с аплоадом php файла.
Это не совпадение, а сделано намеренно о чем сказано в самом htaccess файле.Используешь дургой сервер, будь добр внимательно ознакомиться с правилами установки.
Обновился :).
фейла нет, ибо нет идеального кода.
> буквально на днях кто то написал "вот поэтому я использую друпал" и такой фейл!Кажется, там было в контексте дырок joomla (бишь совсем не fail, особенно с учётом характера проблемы в данном разе -- её предусмотрели, но возможность наступить на грабли с не-апачем осталась).
Другое дело, что remote code exec штука крайне неприятная в любом проявлении -- однажды и на TYPO3 пришлось спешно подрываться и затыкать, лет пять тому, что ли. И в этом плане не такая уж и разница -- веб-сервер не смотрит в .htaccess или в модуле ляп оказался...
Меня всегда удивляет насколько яро можно говорить о негативных качествах PHP забывая при этом то что ошибки присуще любому ПО
> Меня всегда удивляет насколько яро можно говорить о негативных качествах PHP забывая
> при этом то что ошибки присуще любому ПОНе всякому ПО прсуще свойство эти ошибки взращивать. Массово, постоянно и всенепременно.
Это такой толстый намек на python?
> Это такой толстый намек на python?На posix шел.