В web-сервере Nginx обнаружена (http://www.lexa.ru/nginx-ru/msg27388.html) удаленная критическая уязвимость (http://www.securityfocus.com/bid/36384) (CERT VU#180065, CVE-2009-2629 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2629)): переполнение буфера, которое может привести к выполнению произвольного кода с правами рабочих процессов или к осуществлению атаки "отказ в обслуживании" через передачу специальным образом сформированного URL.
Уязвимые версии: 0.1.0-0.8.14. С исправлением выпущены версии nginx-0.8.15 (nginx/nginx-0.8.15.tar.gz),
nginx-0.7.62 (nginx/nginx-0.7.62.tar.gz),
nginx-0.6.39 (nginx/nginx-0.6.39.tar.gz) и
nginx-0.5.38 (nginx/nginx-0.5.38.tar.gz). Доступен патч (http://sysoev.ru/nginx/patch.180065.txt) и обновления для Debian (http://www.debian.org/security/2009/dsa-1884), Fedora (https://admin.fedoraproject.org/updates/nginx-0.7.62-1.fc10), FreeBSD (http://www.vuxml.org/freebsd/152b27f0-a158-11de-990c-e5b1d4c...). Информации о наличии эсплоита в публичном доступе пока нет.
URL: http://sysoev.ru/nginx/patch.180065.txt
Новость: http://www.opennet.me/opennews/art.shtml?num=23417
Судя по патычу, надо в строке чего-то натыкать....Index: src/http/ngx_http_parse.c
===================================================================
--- src/http/ngx_http_parse.c (revision 2410)
+++ src/http/ngx_http_parse.c (revision 2411)
@@ -1134,11 +1134,15 @@
#endif
case '/':
state = sw_slash;
- u -= 4;
- if (u < r->uri.data) {
- return NGX_HTTP_PARSE_INVALID_REQUEST;
- }
- while (*(u - 1) != '/') {
+ u -= 5;
+ for ( ;; ) {
+ if (u < r->uri.data) {
+ return NGX_HTTP_PARSE_INVALID_REQUEST;
+ }
+ if (*u == '/') {
+ u++;
+ break;
+ }
u--;
}
break;--------
Аа-а-а-а-а.... ну там выше по коду написано... http://www.evanmiller.org/lxr/http/source/http/ngx_http_pars.../*
962 * we use "ch = *p++" inside the cycle, but this operation is safe,
963 * because after the URI there is always at least one charcter:
964 * the line feed
965 */Вот и пришел always :)
Чего бы туда вставить, вместо нуля...
вот и первые показатели того, что Nginx становится действительно очень популярным :)
Он уже года три как очень популярен. Какой бы сайт ни выдал сообщение о том, что он перегружен - везде приписка, nginx. Редко когда уже что-то другое.
Негативный показатель.
Не обязательно. Nginx-то работает, а бекенды к нему падают.
>Негативный показатель.Да, отсутствие ума - негативный показатель, даже очень! А при наличии мозга - и ежу понятно что если нжинкс рисует сообщение - он при этом стало быть ЖИВОЙ. А сдох то как раз апп-сервер бывший за ним :D.Как то опач или кто там еще в этой роли был. О чем нжынкс и информирует. А что ему еще остается делать, если он всосал при попытке отдать запрос серверу приложений?
кстати, да.
с другими лично мне не попадалось.
>кстати, да.
>с другими лично мне не попадалось.А других не так уж и часто используют как лоад-балансеры, реверс-прокси и прочая перед апп-серверами. Вот и весь секрет, имхо.
Например lighttpd (следующий по популярности легкий сервак способный выдерживать тысячи соединений без проблем для себя) в роли такого прокся - довольно дурно смотрится из-за того что у него логика работы такова что он кеширует ответы бэкэнда в RAM. Так что если вдруг ответом на запрос будет не дай боже iso-sized файл ... ну вы понимаете сколько тогда скушает оперативы лайти, да? Из-за этого свойства лайти, очевидно, не особо популярен как прокси перед апп-серверами. Остальных легких и шустрых в большом количестве (достойного внимания неткрафта например) - не замечено.
Других легких и популярных способных быть проксей в балансирах и т.п. при адской нагрузке - эээ а они где? И главное - где сайты с ними? Ну или чью лэйбу вместо нжинксы вы хотите увидеть в качестве реверс-прокси сообщающего о безвременной кончине бэкэнда?
И на Сысоева бывает проруха.
а недавний ботнет не эксплойт к этой дыре использовал ? там тоже нжинкс фигурировал
Нет. Там и Linux фигурировал, из чего куча троллей сделала вывод, что виноват он.
тролей ли?
образ врага надо формировать. и слухи для этого отлично подходят.
Именно троллей. Никто из владельце серверов даже не сомневается, что у них эксплойта нет и быть не может.
>Именно троллей. Никто из владельце серверов даже не сомневается, что у них эксплойта нет и быть не может.вопрос с владельцами - понятен.
а вот вопрос с будущими владельцами/клиентами - действительно вопрос.
скорее воркеры падать будут, чем левый код выполняться.Изменения в nginx 14.09.2009
*) Безопасность: при обработке специально созданного запроса в рабочем
процессе мог произойти segmentation fault.
Спасибо Chris Ries.
>скорее воркеры падать будут, чем левый код выполняться.http://www.debian.org/security/2009/dsa-1884
"An attacker can use this to execute arbitrary code with the rights of the worker process (www-data on Debian) or possibly perform denial of service attacks by repeatedly crashing worker processes via a specially crafted URL in an HTTP request."
В Debian очень сильный security team, напрасно словами они не бросаются.
_or_ possibly perform denial of service attacks by repeatedly crashing worker processes via a specially crafted URL in an HTTP request."
---
о чем и говорят - получится DoS - но с выполнением кода там проблемы
Просто _пока_ нет готового эксплойта.
да и не будет. обновление пройдёт быстро и никому незаметно.
Даже Сысоев пишет (http://www.lexa.ru/nginx-ru/msg27419.html) "Вероятность исполнения кода есть, но на сайтах с большим числом запросом в секунду очень мала."
обновился за 30 секунд )
аналогично.
обновление занимает не более минуты на всех серверах.
>аналогично.
>обновление занимает не более минуты на всех серверах.А что уже есть обновления для RHEL/CentOS?
собирать из сорца уже не модно?
>собирать из сорца уже не модно?у меня несколько десятков серверов.
Да, собирать из сорцов это не модно.
Обновил на 10 разноплатформенных серверах за 20 минут. Ждите апдейтов, ага.
свою rpm собрать не дано ?
>свою rpm собрать не дано ?Помогите - не умею.
ASP Linux
>>свою rpm собрать не дано ?
>Помогите - не умею. ASP Linuxhttp://www.altlinux.org/SpecTips, секция "Документы" -- там есть ссылки и на федорино руководство, и на его русский перевод -- должно сгодиться.
В случае уже доступного пакета алгоритм в случае nginx примерно таков:
- rpm -qi nginx, смотрим Source RPM
- гуглим найденный src.rpm
- качаем из наиболее достоверного источника
- rpm -i nginx-*.src.rpm
- идём в RPM/SOURCES, который будет или под /usr/src, или в $HOME
- качаем текущий тарбол
- идём в ../SPECS
- vim nginx.spec
- ищем Version:, заменяем на соответствующую тарболу
- рядом Release: сбрасываем в что-нить вроде 1 (или alt0.1, или 1mypkg...)
- ищем %changelog, пишем по образу и подобию в его начало запись о содеянном (в альте для этого есть утилитка add_changelog)
- rpm -ba nginx.spec (если будет ругаться, что чего-то нужного из BuildRequires: не стоит, то ставим и повторяем)
- при удаче получаем собранные исходный и бинарный пакеты, последний доставляем-ставим
- при неудаче смотрим, что взорвалось -- старые патчи отвалились, новый компилятор не собирает -- и принимаем действия по необходимости (см. тж. Software-Building-HOWTO)(пойду-ка зафиксирую на http://www.linux.kiev.ua/ru/docs/articles/rpm-spec-howto/)
>[оверквотинг удален]
>- ищем %changelog, пишем по образу и подобию в его начало запись
>о содеянном (в альте для этого есть утилитка add_changelog)
>- rpm -ba nginx.spec (если будет ругаться, что чего-то нужного из BuildRequires:
>не стоит, то ставим и повторяем)
>- при удаче получаем собранные исходный и бинарный пакеты, последний доставляем-ставим
>- при неудаче смотрим, что взорвалось -- старые патчи отвалились, новый компилятор
>не собирает -- и принимаем действия по необходимости (см. тж. Software-Building-HOWTO)
>
>
>(пойду-ка зафиксирую на http://www.linux.kiev.ua/ru/docs/articles/rpm-spec-howto/)Спасибо. А ASPLinux и ALTLinux схожи по структуре?
>А ASPLinux и ALTLinux схожи по структуре?Не особенно IMHO; в любом разе базовые навыки по сборке RPM более-менее переносимы. Скажем, меня отучал от спекобоязни Владимир Бормотов, тогда ещё активно контрибутивший в Black Cat Linux :)
Да - nginx эта не та программа, с обновлением которой могут быть проблемы.Вот обновлять тот же Perl с 5.8.8 до 5.8.9 при наличие 100-ни p5-модулей нужно аккуратно :)
[tiger@notebook]~%pkg_info -xI ^perl
perl-threaded-5.10.1 Practical Extraction and Report Language
[tiger@notebook]~%pkg_info -xI ^p5|wc -l
104
все нормально;( обновлял и машины с > 200 p5- без проблем
Не, это обычно с php-обновлениями такое бывает ;)
>Не, это обычно с php-обновлениями такое бывает ;)А попробуйте просто так на системе с Perl 5.8.8 и сотней p5-модулей сделать portupgrade -rR perl
И после попробуйте сделать: portupgrade -rR 'p5-*'
Будете очень неприятно удивлены.
PS: Штатный рекомендованный разработчиками Perl способ: man perl-after-update (такая же штука есть и у Python - python-update).
А почему еще эксплойт в паблике не появился?
да потомучто его нет. как нет и большого смысла его делать. какая радость воркеры грохать? всё равно мастер их ещё назапускает. а чтоб код выполнился - так это только под определённую комбинацию системы и её окружения затачивать надо. что трудоёмко и не универсально - вообщем не вижу смысла в этом занятии для кого-либо. да и уязвимость просуществовала крайне непродолжительный срок.
>Уязвимые версии: 0.1.0-0.8.14Т.е. все. Это типа "крайне непродолжительный срок" ?
Напомнить про другие дырки, которые не были открыты с 2001-го года?
Как Вы думаете, сколько таких дырок в проприетарном ПО существует _сейчас_?Это не zero-day, все кто хотел, вовремя обновился. Всех предупредили заранее, а дырки бывают в любом ПО...
ага. даже до первой версии не дожила. ;-D
Игорь говорит, что 1.х.х -- стабильное API, а он API стабильным делать пока не хочет
>да и уязвимость просуществовала крайне непродолжительный срок.Если Вы случайно работаете системным администратором, сильно рекомендую сменить отношение к уязвимостям :-(
Важно не то, сколько "просуществовала" в принципе незаткнутая дырка, а то, когда на системах под вашим (как минимум) управлением этой дырки не стало. Этот срок обычно "подпирается" снизу временем публикации исправления; если возможно оперативное исправление своими силами, то временем публикации информации о проблеме; если проводится самостоятельный аудит кода, то может быть локально исправлено ранее, чем даже будет опубликована кем-либо информация.
Насчёт "назапускает" -- см. про DoS.
Насчёт "затачивать" -- бывают достаточно широко используемые комбинации, чтобы был смысл возиться при желании их задействовать в своих целях.
Вижу Вы за пару минут уже написали сплойт для всех распространнённых BSD и linux систем и свысока поглядываете на окружающих, которые тратят на обновление в полтора раза больше времени, чем вы на взлом. Что-ж, это ваша проблема. отношения же к уязвимостям - это ваши измышления, основанные исключительно на вашей способности листать астрал как открытую книгу и поучать остальных, отвлёкшись от своего основного призвания, в целом состоящего из способности бегать и голосить на тему пожар-кашмар-мы_все_умрём.
:-\
>Вижу Вы за пару минут уже написали сплойт для всех распространнённых BSD
>и linux системНу вы иногда на milw0rm.com и т.п. сайты захаживайте для приличия? Так, для профилактики спокойного сна :).Нет, я не хочу сказать что там сплойт для нжинксы уже есть (это была бы жесть) но его содержимое от спокойного сна админам - помогает, да. Там же и шеллкоды для <ваша_любимая_ОС> можно нарыть, удостоверившись что в принципе хаксоры не возражают против освоения новых горизонтов :).Ну, ладно, шеллкод для пингвинов на ARM я там не нашел, да. Жалко - хакерам еще есть над чем поработать :)
Еще хороший помощник от спокойного сна - http://securityvulns.ru/ (он же security.nnov.ru). Невзрачный и не очень известный сайтик одного любителя безопасности, вполне способный лишить иной раз спокойного сна любого мало-мальски вменяемого админа :)
> security.nnov.ruСогласен, daily рассылка самое занимательное чтиво с утренним кофе. Бодрит. ;-)
>и не очень известный сайтик одного любителя безопасности, вполне способный лишить
>иной раз спокойного сна любого мало-мальски вменяемого админа :)на самом деле довольно известный, но в узких кругах :)
а 3proxy по моему знает любой юниксовый ru админ.
>на самом деле довольно известный, но в узких кругах :)Где-то так. ИМХО весьма приличный сайт по уязвимостям.
>а 3proxy по моему знает любой юниксовый ru админ.
Не заметил что-то. Хотя он того явно стоит. Совершенно забойная прокся которая при мизерном размере по фичности спокойно делает множество платных коммерческих программ.
http://virtualserver.ru/http_dos.py DoS
кстате, http_dos.py не работает, баг даже не срабатывает. нафиг такое выкладывать?