Представлен (http://mailman.nginx.org/pipermail/nginx-announce/2013/00011...) внеплановый стабильный выпуск http-сервера nginx 1.4.1 (http://nginx.org/#2013-05-07), а также первый выпуск новой экспериментальной ветки 1.5.0, в которых отмечается устранение уязвимости (http://mailman.nginx.org/pipermail/nginx-announce/2013/00011...) (CVE-2013-2028), которая может привести к перезаписи областей стека рабочего процесса при обработке специально оформленных chunked-запросов. При успешной эксплуатации не исключается возможность исполнения кода злоумышленника на сервере.Проблема проявляется только в выпусках nginx, начиная с версии 1.3.9. Прошлая стабильная ветка 1.2.x, которая ещё поставляется в большинстве дистрибутивов, уязвимости не подвержена. Для исправления проблемы можно использовать патч (http://nginx.org/download/patch.2013.chunked.txt). В качестве обходного пути защиты от проявления уязвимости, в каждом из блоков server{} можно использовать следующую конструкцию:
<font color="#461b7e">
if ($http_transfer_encoding ~* chunked) {
return 444;
}
</font>
URL: http://mailman.nginx.org/pipermail/nginx-announce/2013/00011...
Новость: http://www.opennet.dev/opennews/art.shtml?num=36875
это уже интересно...
Без Игоря не какого контроля качества, быдл0 кодит...
● Ошибки так же неисчерпаемы, как и атом.
● Аксиома: В любой программе есть ошибки.
● Закон пропорциональности: Чем более программа необходима, тем больше в ней ошибок.
● Следствие: Ошибок не содержит лишь совершенно ненужная программа.● Фундаментальный закон теории ошибок. На ошибках учатся.
- Следствие 1. Программист, написавший программу, становится ученым.
- Следствие 2. Чем больше программист делает ошибок, тем быстрее он делается ученым.
- Следствие 3. Крупный ученый-программист никогда не пишет правильные программы.
Замечание. На то он и ученый.Указание начинающему программисту. Если вы с первого раза сумели
написать программу, в которой транслятор не обнаружил ни одной
ошибки, сообщите об этом системному программисту. Он исправит
ошибки в трансляторе.● Закон необходимости ошибок. Программист может обнаружить ошибку
только в чужой программе.
- Следствие. Ошибке не все равно, кто ее обнаружит.Совет начинающему программисту. Никогда не исправляйте найденные
ошибки, ибо это повлечет за собой появление неизвестного числа
не найденных. Лучше опишите их в сопроводительной документации как
особенность программы.Ошибки могут вызывать друг друга и сами себя (рекурсивность ошибок).
Ошибки допускают многократное вложение друг в друга. Две одинаковые
вложенные ошибки называются четной ошибкой и ошибкой не являются.● Свойство четности ошибок. Если написанная программа сработала
правильно, то это значит, что во время ее работы выполнилось
четное число ошибок или программист не понял задание.● Языковый редактор (IDE), призванный уберечь программиста от
синтаксических ошибок, позволяет вносить в программу весьма
хитроумные ошибки, которые не удается обнаружить ни транслятором,
ни отладчиком. Обычный текстовый редактор таких возможностей не
предоставляет.
А говорят деньги не портят человека, но продукт все же гробят именно деньги и тупые сотрудники у руля этого карабля
Жаль разработчиков, столько трудились и в один момент капитально подорвана репутация и потеряно доверие к проекту :-( Из нерушимых остаются только Postfix и vsftpd, в которых только мелкие и неопасные уязвимости находили.
Во-первых, не ошибается тот, кто ничего не делает. А во-вторых, я думаю разработчики потерю репутации в твоих глазах переживут. Это будет не легко, но они справятся.
в-третьих nginx далеко не оплот нерушимости и непогрешности
http://nginx.org/en/security_advisories.html
тут достаточно много всегомне интересно другое, тут недавно китайцы из Qihoo хвастались что дырку нашли (неподтвердилась), интересно iSight какое то отношение к аудиту из-за этой дырки имеют или нет, дырка правда совсем другая ;)
> в-третьих nginx далеко не оплот нерушимости и непогрешности
> http://nginx.org/en/security_advisories.html
> тут достаточно много всегоЭто смотря как считать.
С версии 1.0 и старше major'ов три -- из них один на "specially crafted BACKEND response", что само по себе уже смешно. :)
А так -- http_mp4 и эта. Впрочем, тоже нехорошо.
> Во-первых, не ошибается тот, кто ничего не делает. А во-вторых, я думаю разработчики потерю репутации в твоих глазах переживут. Это будет не легко, но они справятся.А теперь представь, что в техническом плане все то же самое но фамилия разработчика - не Сысоев, а Дреппер (или Поттеринг).
Стал бы ты их оправдывать? То-то же.Репутация - это прежде всего личные симпатии и антипатии. Реальное качество продукта не играет никакой роли.
а почему бы и нет? еще раз - не ошибается лишь тот, кто ничего не делает.
Что за фигню ты написал? Дреппер высококласный специалист но не очень культурный и резковатый человек, а Поттеринг постоянно косячит.
> Что за фигню ты написал? Дреппер высококласный специалист но не очень культурный и резковатый человек, а Поттеринг постоянно косячит.Типичный пример сугубо эмоциональной оценки.
По факту, они оба хорошие спецы в своих областях, хотя и не безгрешны. Но отношение к ним определяется не уровнем их квалификации, а исключительно пиаром. В Adobe очень "любят" Дреппера, а Поттеринга очень "уважают" в Canonical.
> Что за фигню ты написал? Дреппер высококласный специалист но не очень культурный
> и резковатый человек, а Поттеринг постоянно косячит.А высококлассного специалиста украшает дворовое воспитание или вообще его полное отсутствие?
> А высококлассного специалиста украшает дворовое воспитание или вообще его полное отсутствие?Высококлассный специалист - это тот, кто не занимается гуманитарным словоблудием, как ты сейчас.
В спорах часто побеждает не тот, кто прав, а тот, кто увереннее в своей правоте. Если ты будешь мямлить, хоть и будешь прав, а потом брюзжать "а я ведь предупреждал", то к тебе постоянно будут относиться как к размазне и брюзге. Определённой категории людей понятен только агрессивный и самоуверенный тон, только таких они могут считать правыми. Конечно, нужно не слишком часто ошибаться, потому что тогда уже отношение может смениться на противоположное - "выскочка и пустобрёх". Успех состоит из двух компонентов - профессиональной компетентности и социальной компетентности.
В спорах часто побеждает не тот, кто уверенней в своей правоте, а тот, у кого лучше подвешен язык. Если же спор затеян не с целью помериться писюнами, а с целью нахождения истины, тогда люди спокойно аргументируют свою позиции и оппоненты вместе разрешают спор. Что бы ты не делал, всегда найдутся те, кто будет осуждать тебя, поэтому и "успешным" и "неуспешным" управленцам мнение социума интересно только в контексте манипуляции массами. Среди начальства табун "самодуров", но их не увольняют, значит выскочки и пустобрехи на своем месте. Людей которые пытаются решить проблема агрессивным и самоуверенным тоном - дави интеллектом или не общайся с ними вообще. Про анатомию успеха расскажи отечественным и зарубежным олигархам.Свои новые открытия по конфликтологии и социологии немедленно пиши на опеннет, они тут так в тему.
> манипуляции массами. Среди начальства табун "самодуров", но их не увольняют, значит... это Россия. Как говорится - угадай страну.
Fixed.
чем раньше ты поймёшь, что непогрешимого софта не было, нет и не будет, тем лучше. я к тому, что доверия быть не должно :)
> чем раньше ты поймёшь, что непогрешимого софта не было, нет и не
> будет, тем лучше. я к тому, что доверия быть не должно
> :)Бывает софт, в котором регулярно находят крупные дыры (например, proftpd), а бывает софт, в котором их не найдешь, хоть весь код перекопай (vsftpd, djbdns).
И nginx из золотой середины начал скатываться в сторону proftpd.
> И nginx из золотой середины начал скатываться в сторону proftpd.не утрируй. на тенденцию это вряд ли тянет. но да, парни стали компанией, получили инвестиции, надо тщательней.
> не утрируй. на тенденцию это вряд ли тянет.Одна новость - да. А вот если сходить по ссылке выше - вполне.
У proftpd тоже далеко не все дыры давали remote shell.
http://www.phpmyadmin.net/home_page/security/
на тенденцию вот что тянет )у nginx есть положительный момент в том, что дырки у них 1) исправляются быстро 2) находятся тоже быстро в пределах ветки разработки или нескольких стабильных версий куда новую "фишку" бекпортировали 3) быстро выложили патч и информацию о том почему следует обновиться (я обновила быстрее чем новость на опеннете вышла)
10 дыр (без windows специфичных) за всю историю проекта, не так уж и много, и уж тем более если сравнить с альтернативами (lighttpd, apache)
> находятся тоже быстро в пределах ветки разработки или нескольких стабильных версий куда новую "фишку" бекпортироваликстати, в авторах CVE некая контора iSight. это что, парни аудит заказали? :)
> быстро выложили патч и информацию о том почему следует обновиться (я обновила быстрее чем новость на опеннете вышла)угу.
>кстати, в авторах CVE некая контора iSight. это что, парни аудит заказали? :)мне вот тоже кажется что заказали, в связи с http://www.securityfocus.com/archive/1/526439/30/0/threaded
> 10 дыр (без windows специфичных) за всю историю проекта, не так уж
> и много, и уж тем более если сравнить с альтернативами (lighttpd,
> apache)Только стоит ещё учесть историю: apache и lighttpd постарше, чем nginx. Может быть nginx не хорош, а просто ещё очень молод?
Где вы начитались про vsftpd? Хорошая программа, но серебрянной пули не существует: http://www.exploit-db.com/search/?action=search&filter_page=...Про nginx я слышал, что ещё ни одной уязвимости с возможностью удалённого выполнения кода не существовало. Сейчас появилась - закрыли тут же. Код проекта предельно чист.
> Где вы начитались про vsftpd? Хорошая программа, но серебрянной пули не существует:
> http://www.exploit-db.com/search/?action=search&filter_page=...Ты дурачёк? Ты сам по своей ссылке ходил? Два бага, оба DoS, один из которых требует успешной аутентификации.
> Ты дурачёк?Хуже - анимешник
> Хуже - анимешникЧем тебе анимешники не угодили? /злобно, выгибая пальцы для вставки в глаза оппонента/
>> Хуже - анимешник
> Чем тебе анимешники не угодили? /злобно, выгибая пальцы для вставки в глаза
> оппонента/Анимешники - г@вно.
> Анимешники - г@вно.@вно - это ты, а анимешники - большое коммюнити. От млада до велика.
Ня!
Репутация портится не у тех, у кого находят уязвимости, а у тех, кто их подолгу не исправляет.
>> Из нерушимых остаются только Postfix и vsftpd, в которых только мелкие
>> и неопасные уязвимости находили.Тогда я вам порекомендую в качестве HTTP-сервера программу "Hello World!", в ней вообще за всё огромную историю существования ни одной уязвимости не нашли.
> Тогда я вам порекомендую в качестве HTTP-сервера программу "Hello World!", в ней
> вообще за всё огромную историю существования ни одной уязвимости не нашли.Да ладно. Бывают спецы, которые и приветмир дырявый могут сделать.
> vsftpdна до же бы ло ска зать pure-ftpd
Не радует.
Что ни говори, а код у nginx ужасный. Ужасный код не может быть безопасным.
> Что ни говори, а код у nginx ужасный. Ужасный код не может
> быть безопасным.Вы наверное PHP-шник? Пример в студию. Сорцы nginx одни из самых читабельных среди всего, что мне доводилось видеть.
Собственно, весь обсуждаемый ngx_http_parse.c написан упоротым оптимизатором, которому даже strncmp использовать западло. Взамен это:#define ngx_str3_cmp(m, c0, c1, c2, c3) \
*(uint32_t *) m == ((c3 << 24) | (c2 << 16) | (c1 << 8) | c0)#define ngx_str3Ocmp(m, c0, c1, c2, c3) \
*(uint32_t *) m == ((c3 << 24) | (c2 << 16) | (c1 << 8) | c0)#define ngx_str4cmp(m, c0, c1, c2, c3) \
*(uint32_t *) m == ((c3 << 24) | (c2 << 16) | (c1 << 8) | c0)
#define ngx_str5cmp(m, c0, c1, c2, c3, c4) \
*(uint32_t *) m == ((c3 << 24) | (c2 << 16) | (c1 << 8) | c0) \
&& m[4] == c4
#define ngx_str6cmp(m, c0, c1, c2, c3, c4, c5) \
*(uint32_t *) m == ((c3 << 24) | (c2 << 16) | (c1 << 8) | c0) \
&& (((uint32_t *) m)[1] & 0xffff) == ((c5 << 8) | c4)
#define ngx_str7_cmp(m, c0, c1, c2, c3, c4, c5, c6, c7) \
*(uint32_t *) m == ((c3 << 24) | (c2 << 16) | (c1 << 8) | c0) \
&& ((uint32_t *) m)[1] == ((c7 << 24) | (c6 << 16) | (c5 << 8) | c4)#define ngx_str8cmp(m, c0, c1, c2, c3, c4, c5, c6, c7) \
*(uint32_t *) m == ((c3 << 24) | (c2 << 16) | (c1 << 8) | c0) \
&& ((uint32_t *) m)[1] == ((c7 << 24) | (c6 << 16) | (c5 << 8) | c4)#define ngx_str9cmp(m, c0, c1, c2, c3, c4, c5, c6, c7, c8) \
*(uint32_t *) m == ((c3 << 24) | (c2 << 16) | (c1 << 8) | c0) \
&& ((uint32_t *) m)[1] == ((c7 << 24) | (c6 << 16) | (c5 << 8) | c4) \
&& m[8] == c8А в старых версиях, помнится, было и вовсе: if m[0] == 'P' && m[1] == 'O' && m[2] == 'S' && m[3] == 'T'. И весь парсер состоит из вложенных switch... case... switch... case... switch... case... на пятнадцать экранов, с адресной арифметикой и кучей глобальных переменных состояния. Вот вы можете головой поручиться, что там нет логических ошибок? Лично я б за вашу голову много не дал. Безопасный сетевой код так не пишут.
В lighttpd2 вон перестали заниматься хернёй и начали использовать glib для строк и ragel для парсеров, потому ковбойские времена K&R уже прошли, и кто не использует библиотечные функции и кодогенераторы, тот школота и мерзавец. Повторяю: ШКОЛОТА И МЕРЗАВЕЦ.
Сам ты мерзавец :)
uint32_t ? хм .. в каком веке мы живем...
Не просто uint32_t, а *(uint32_t*)
А в общем и целом - действительно, код упорот на голову. Одна из причин, по которой я крайне предвзято смотрю на nginx. Неплохо бы уже слегка понять, что современные архитектуры с uint32_t оперируют слегка это, неоптимально... А в указанном случае - и вообще довериться компилеру, ибо при поддержке SSEx этот код будет слегка оптимальнее.
AVX инструкции на процессорах от Intel могут сразу тремя переменными оперировать в векторе за такт
> AVX инструкции на процессорах от Intel могут сразу тремя переменными оперировать в
> векторе за такт
> AVX инструкции на процессорах от Intel могут сразу тремя переменными оперировать в
> векторе за тактДа, смысла городить "оптимизационные" велосипеды никакого.
Ну, так огульно всё ж не стоит.
Смысл как был, так и есть, в определенных местах. Другой вопрос что оптимизация оптимизации рознь. Такая микро- как выше, конечно, смысла имеет мало. А вот учитывать иерархичность памяти, размеры кэшей процессоров, выравнивать структуры данных и проч. - не особо сложно, а помогает весьма
> Смысл как был, так и есть, в определенных местах.Так, как выше приведено - нет в принципе.
> А вот учитывать иерархичность памяти, размеры кэшей процессоров, выравнивать структуры
> данныхСогласен. Но это задачи в основном для ядра и ядрёного программирования, в коде аппликух этим обычно уже занимается компилятор + glibc. Кроме того, такой подход порождает массу #define - поскольку надо учитывать под каждый проц. Ну и с выходом новых процов всё становится печально. Отличный пример - виндоприложения.
http://pastebin.com/y6Tbj5pF
Не в обиду, шко.лот.ой являются авторы лайти. Они продо.л.б.али шанс стать вторыми в мире. Они не поддеривают преемственность версий. Они все крушат до основания, не имея ни таймлайна выпуска новой версии, ни внятной поддержки старой версии, на которую они уже по.л.ожили. Это отст0й: применять сие в продакшне невозможно. Потому что на выбор жуткий недопил0к с странными зависимостями (glib на сервере? ну-ну, удачи) и хрень с известными большими проблемами, на котоорые шко.л.ота забила, вдарившись за крутыми концепциями, но не имея ресурсов довести до ума хоть что-то. Меня это достало и я перевел мои серваки на нжинкс. У этих по крайней мере какая-то логика прослеживается, а не просто метания ст.у.дней между концепциями.Вывод: по управлению проектом в целом нжинкс намного вменяемее. По на либы.По на эстетику. В конце концов засчитывается как оно работает. Нэинкс при эксплуатации намного лучше, с какой стороны ни глянь.
зы а настоящий м3рзавец - тот кто гномовую глЫбу на сервер сватать удумал.
$ ldd /usr/bin/mc | grep glib
libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb73d2000)Что же делать! *Побежал сносить mc со всех серверов.*
> $ ldd /usr/bin/mc | grep glib
> libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb73d2000)
> Что же делать! *Побежал сносить mc со всех серверов.*вместо mc используй mc-light, он вроде не тянет гнома
> вместо mc используй mc-light, он вроде не тянет гномаglib -- это не гном, чукчи :)
Разрабатываемая в рамках и лежащая в основах проектов GTK+ и GNOME, GLib широко используется в приложениях
> GLib широко используется в приложениях...самого разного плана, необязательно gnome и даже gtk -- например, consolehelper или gammu:
gammu/libgammu/CMakeLists.txt:# Own or glib based MD5 implementationВообще это одно из распространённых заблуждений, и не надо стесняться приводить педивикию в качестве своего (единственного?) источника таковых.
то что оно родилось вместе с гномом никогда не отобьет у многих "привкус" гнома, даже от библиотеки которая по сути является в некотором роде надстройкой над libc, также как apr (apache portable runtime) или nspr (рантайм мозиллы), никакого GUI и прочей специфики все эти библиотеки не содержат, всегото управление памятью, потоками итп.в приципе приведенных пары примеров должно быть достаточно для того, чтобы показать что многим libc недостаточно ;) это у nginx зависимости только на libc, zlib, pcre, openssl, libgcc
> вместо mc используй mc-light, он вроде не тянет гноманенене... про mc-light vim-light уже наскакивали.
Вот еще немного вебсерверов- Cherokee ( http://cherokee-project.com/ ) очень юзерфрендли и не нужно редактировать conf (есть админка на вебпорте)
- G-WAN ( http://gwan.com/ )
- Varnish [HTTP accelerator/VCL/] ( https://varnish-cache.org/ )
- Tengine (форк nginx)
- HAproxy (TCP/HTTP баланировщик) http://haproxy.1wt.eu/
- hiawatha ( http://www.hiawatha-webserver.org/ )
- nxweb ( https://bitbucket.org/yarosla/nxweb/wiki/Home )Немного ссылок по теме:
- http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-v.../
- http://webperformance.ru/2011/06/03/varnish-speed-up/
- http://www.tuicool.com/articles/zMJzIf
Хороши.
Еще Appweb - но для разрабов (+ембедед). Вообще nginx не уперся ни с какого бока, много более лучших (c) альтернатив.
А G-WAN - разве не платный? В свое время очень понравился.
> Не в обиду, шко.лот.ой являются авторы лайти. Они продо.л.б.али шанс стать вторыми
> в мире. Они не поддеривают преемственность версий.Это говорит пользователь веб-сервера, у которого полторы недели назад появилась стабильная ветка?
> Они все крушат до
> основания, не имея ни таймлайна выпуска новой версии, ни внятной поддержки
> старой версии, на которую они уже по.л.ожили.Не знаю, что они там крушат. Пользуюсь lighttpd с 2008 года, когда у nginx'а ещё не было стабильной ветки. Никогда не было с ним никаких проблем с lighttpd и ничто не ломалось. Возможно потому что я пользуюсь на серверах Debian, в который не вкатывают каждую новую версию просто потому, что она появилась.
> Это отст0й: применять сие
> в продакшне невозможно. Потому что на выбор жуткий недопил0к с странными
> зависимостями (glib на сервере? ну-ну, удачи)Ты хоть знаешь, что такое glib?
> и хрень с известными большими
> проблемами, на котоорые шко.л.ота забила, вдарившись за крутыми концепциями, но не
> имея ресурсов довести до ума хоть что-то.Какие крутые концепции, какие проблемы, что не доведено до ума? Это веб-сервер, который просто работает.
> Меня это достало и
> я перевел мои серваки на нжинкс. У этих по крайней мере
> какая-то логика прослеживается, а не просто метания ст.у.дней между концепциями.Просто личная неприязнь, как у меня к apache, хотя я не имею ничего против него, если он стоит не на моих серверах.
> Вывод: по управлению проектом в целом нжинкс намного вменяемее. По на либы.По
> на эстетику. В конце концов засчитывается как оно работает. Нэинкс при
> эксплуатации намного лучше, с какой стороны ни глянь.Покажите мне эти стороны. Я пока что ни одной конкретной причины предпочесть один веб-сервер другому от вас не услышал, одна брехня и неграмотность.
> зы а настоящий м3рзавец - тот кто гномовую глЫбу на сервер сватать
> удумал.
> Никогда не было с ним никаких проблем с lighttpd и ничто не ломалось.И файлики с плюсиком в имени там не чинили?
Debian + Apache + Postgres - поездили, поездят и буду поездить нашу поездатую родину!
А знаете, что самое смешное?http://sysoev.ru/apache/chunked.html
Фактически такая же уязвимость. :))))))
забавно http://sysoev.ru/apache/patch.chunked.txt
Смешной патч. Патчить надо было саму функцию, которая возвращает с какого-то перепугу отрицательные размеры...
unsigned __int64
> Фактически такая же уязвимость.Ага, только 11 лет назад.
> А знаете, что самое смешное?Да-да, тоже вспомнилось на даче.
Зачастили как-то релизы nginx-а...