[nginx] уязвимость

- --------------------------------------------------------------------------
Debian Security Advisory DSA-1884-1                    security@debian.org
http://www.debian.org/security/                                 Nico Golde
September 14th, 2009                    http://www.debian.org/security/faq
- --------------------------------------------------------------------------

Package        : nginx
Vulnerability  : buffer underflow
Problem type   : remote
Debian-specific: no
CVE ID         : CVE-2009-2629

Chris Ries discovered that nginx, a high-performance HTTP server, reverse
proxy and IMAP/POP3 proxy server, is vulnerable to a buffer underflow when
processing certain HTTP requests.  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.

Оно?

P.S. Все, я побежал...

Для дебиана вышел апдейт.

[SECURITY] [DSA 1884-1] New nginx packages fix arbitrary code execution

....

For the oldstable distribution (etch), this problem has been fixed in version 0.4.13-2+etch2.

For the stable distribution (lenny), this problem has been fixed in version 0.6.32-3+lenny2.

For the testing distribution (squeeze), this problem will be fixed soon.

For the unstable distribution (sid), this problem has been fixed in version 0.7.61-3.

Обновляйтесь, граждане

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

Оно, родимое.

Запостил в новости.

>Обновляйтесь, граждане

Дык. В такой ситуации обновление проигнорирует только полный ламер.

У нас, кстати, было весело. Учитывая, что опции сборки джинкса нам нужны нестандартные. Пришлось как всегда, пересобирать пакет, тестировать и выкладывать во внутреннем репозитарии. Ну а потом — дело техники. Рутинная, в общем-то, процедура. Но сегодня она шла в очень бодром темпе ;)

<p mode="fat">Представляю себе бедных фряшных админов, которым нужно будет пересобрать джинкс на нескольких десятка или даже сотнях серверов XD

> <p mode="fat"></p>

iZEN'а в тред!

><p mode="fat">Представляю себе бедных фряшных админов, которым нужно будет пересобрать джинкс на нескольких десятка или даже сотнях серверов XD

fail, make package спасет отцов ;]

>fail, make package спасет отцов ;]

fail, труЪ фряшные админы ставят только из портов ;)

еще один миф раздуваете, батенька
и да, почему не вспомнили генту-глазиков?

>iZEN'а в тред!

+512
Смех продлевает жизнь.
Изен добавил к моей жизни лет пять минимум :)

>еще один миф раздуваете, батенька
Это не миф, а реальность. Лично знаю штук десять экземпляров, не признающих бинарные пакеты в принципе. Собственно, в системе портов (и еще блондинистом фаерволе, разумеется) они видят главное преимущество фряхи над «линупсом». Кстати, эти экземпляры работают в крупнейших питерских хостинговых компаниях (валуй, мажордомо).

>и да, почему не вспомнили генту-глазиков?
Сервера на генте — редкость (по моим наблюдениям). В основном это такое милое домашнее животное.

На самом деле, именно зачаточное состояние системы бинарных пакетов во фре — одна из основных причин, почему мы (да и многие другие конторы) отказались от ее использования на серверах.
Такие инструменты, как локальный репозитарий, вкупе в фичами типа apt pinning/yum priorities, цифровых подписей и т.п., позволяет гибко рулить инфраструктурой из десятков и сотен серверов.
Гораздо проще поставить apt-get update && apt-get upgrade или yum update в крон, чем на сотне серверов вбивать pkg_delete бла-бла-бла && pkg_add бла-бла-бла.tgz.

В то же время, реализация сорцовых пакетов в демьяне и центосе пока что тоже особо не радует. Портам и ебилдам они таки уступают.
Но тут уж из двух зол приходится выбирать меньшее.

ну незнаю, кроме локального репозитария серьезных доводов не вижу

расшарить /usr/ports/distfiles по nfs
и использовать portupgrade в бинарном режиме, там все в достаточной мере автоматизированно и удобно ;]

>Гораздо проще поставить apt-get update && apt-get upgrade или yum update в крон, чем на сотне серверов вбивать pkg_delete бла-бла-бла && pkg_add бла-бла-бла.tgz.

Что, не осилили команды "portupgrade -ap" на эталонном (мастер) сервере и команду "env PKG_PATH=/mnt/nfs-master/usr/ports/packages/All portupgrade -aPPy" на рабочих серверах?

>и использовать portupgrade в бинарном режиме, там все в достаточной мере автоматизированно и удобно ;]
Не буду с серьезным лицом рассуждать о вопросе, в котором я не являюсь экспертом.

Могу сказать лишь одно: за свою жизнь я неоднократно слышал о попытках создать масштабируемую инфраструктуру для поддержки больших группировок серверов на фряхе, но никогда не видел и даже не слышал об успешных реализациях этой идеи. В то время как реализации под дебиан и центос видел неоднократно. И у нас, и у других контор.

>Что, не осилили команды "portupgrade -ap" на эталонном (мастер) сервере и команду "env PKG_PATH=/mnt/nfs-master/usr/ports/packages/All portupgrade -aPPy" на рабочих серверах?

А где здесь ставить и проверять цифровые подписи? Как расставлять приоритеты для разных веток репозитария?

Да, и зеркалировать как?

> Это не миф, а реальность. Лично знаю штук десять экземпляров, не признающих бинарные пакеты в принципе.

И они настолько суровые и бородатые, что даже избегают копировать бинарники между однородными серверами?

>И они настолько суровые и бородатые, что даже избегают копировать бинарники между однородными серверами?

Разумеется. Я же говорю, установку из бинарников им запрещает религия. По их словам, установка только из сорцов — это Ъ-BSD way.

iZEN, не слушай их, мы успешно обновили все фряшки :).

Ну, кто из суровых бородатых фряшников может объяснить, почему при make buildworld не фильтруются CFLAGS и в итоге мы получаем конфликт при стандартной оптимизации:

cc -pg -O2 -mtune=nocona -pipe -fomit-frame-pointer -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/sys/fcntl.c -o fcntl.po

cc: -pg and -fomit-frame-pointer are incompatible

А сплоита нет ещё? ^^ доброта.png

то что вы не слышали - не значит что таких систем не существует. tobez@freebsd.org расказывал о реализации централизованой инфрактруктуры для не маленького провайдера в европе. Это с учетом бэкапов конфигов, поддержки обновлений и тп.. Может мисье просто не осилил ?

>то что вы не слышали - не значит что таких систем не существует.

А я и не говорил, что их не существует. Но реально функционирующих систем, которые бы нас устраивали, в свое время найти не удалось.

>tobez@freebsd.org расказывал о реализации централизованой инфрактруктуры для не маленького провайдера в европе.

Пруф?
Полагаю, там все просто, как швабра. Конфиги по rsync, обновления через distfiles по NFS. С нашими потребностями, это не инфраструктура, а муляж оной. Извините.

>Может мисье просто не осилил ?

Кто не осилил? Что не осилил?
Такая инфраструктура — это масштабный проект. «Осиливание» отдельно взятым человеком ничего не решает. Будь он разработчиком или админом.

>tobez@freebsd.org расказывал о реализации централизованой инфрактруктуры для не маленького провайдера в европе

Вот что интересно, когда приводишь пример такого монстра, как wikipedia.org, написанного на PHP, это не катит за пример распространённости или использования этого языка в крупных проектах :)

Поправь Makefile

PS впервые слышу о системе устранения коллизий во флагах компилятора. Где ты такое видел?

> Полагаю, там все просто, как швабра. Конфиги по rsync, обновления через distfiles по NFS. С нашими потребностями, это не инфраструктура, а муляж оной. Извините.

я тоже самое про любую ось могу сказать. Особенно про редхатоподобные.

Всё зависит от потребностей.

>Всё зависит от потребностей.

Конкретно в нашем случае, Debian и CentOS удовлетворяют нашим потребностям, а фряха — нет.

Возможно, но это ничего не значит. Вот моим потребностям редхаты не удовлетворяют. Какой из этого можно сделать вывод? Никакого.

конкретно в случае этого топика и вашего вброса - фряха полностью устраивает, о чем вам и указали пару раз :-\

>Какой из этого можно сделать вывод? Никакого.

Ну есть еще вариант, что вы просто не умеете их готовить ;)
А чем они вам не угодили-то? (просто интересно)

>конкретно в случае этого топика и вашего вброса - фряха полностью устраивает, о чем вам и указали пару раз :-\

1. У меня с детства аллергия на костыли.
2. Как я уже говорил, большинство знакомых мне фряшных админов презирают это «чит для слабаков».

Собственно, в рамках этих пунктов я и иронизировал.

>фряха полностью устраивает

Поясню, что я имел в виду в предыдущем посте, говоря про костыли.

Расшаривание distfiles по NFS — это именно костыль, а не рекомендованный и тщательно оформленный разработчиками way.

Он уступает «методу локального репозитария» по многим (в частности, критичным для нас) параметрам, как-то: безопасность (подписывание пакетов и репозитариев против дырявой NFS), гибкость (страшно представить себе фряшно-бинарный аналог apt-pinning или даже просто приоритетов yum), надежность (простое распределение нагрузки через DNS против ручного руления монтированием на каждом сервере или аналогичных костылей).

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

Посему считаю целесообразным изменить формулировку
>фряха полностью устраивает
на
>в самых простейших случаях сгодится и фряха

Да я уже говорил чем не угодили. Древним python-mysqldb мохнатых годов, мусклом жутко древним и глючным в котором отказались фиксить проблемы с тем что некоторые запросы сегфолты вызывают(в дебиане это пофиксиили, в итоге его и поставил)...

Такая политика по отношению к мусклу и жутко древний софт меня(вернее программистов и существующие проекты) не устраивают. Тот же canonical раз в два года LTS-дистры выпускает и вполне удалось всё запустить на 8.04. А редхат? 5.1, 5.2, 5.3 ... а изменений с гулькин нос.

>Древним python-mysqldb мохнатых годов, мусклом жутко древним и глючным в котором отказались фиксить проблемы с тем что некоторые запросы сегфолты вызывают(в дебиане это пофиксиили, в итоге его и поставил)...

Интересно. Ссылочкой не поделитесь?

>А редхат? 5.1, 5.2, 5.3 ... а изменений с гулькин нос.

Можете рассматривать вторую цифру в релизах RH как третью цифру в релизах Debian. Вы же не жалуетесь, что в debian 5.0.3 изменений с гулькин нос по сравнению с 5.0? :)
В четверке, помнится, так и писали — RHEL 4 update 3.

Да, RH слишком увлекся труЪ ынтерпрайзом. В результате завис во времени. Но в определенных ситуациях это может быть и плюсом.

>Тот же canonical раз в два года LTS-дистры выпускает

Ну, того же эффекта можно достичь и без каноникал :)
Ставите демьян и обновляетесь до unstable. Пока весь этот софт до testing дойдет, затем релиз, stable, потом oldstable — как раз срок LTS и набежит. Кстати, именно так это срок и определили (я полагаю).

> Интересно. Ссылочкой не поделитесь?

Посмотри версию мускла, поищи в багтрекере уязвимости этой версии и попробуй запустить. Три способа сегфолтнуть мускул я нашёл. Потом читал в рассылке о том что security team сказал что это не проблема безопасности и фиксить не будет.

Выполни вот это, например: SELECT id from example WHERE id IN(1, (SELECT IF(1=0,1,2/0))); Год назад это рушило редхатовский мускул. Если не упадёт ещё дам пару запросов.

> Можете рассматривать вторую цифру в релизах RH как третью цифру в релизах Debian. Да, я неправильно выразился. Я хотел сказать что слишком редко выпускает мажорные релизы.

> Да, RH слишком увлекся труЪ ынтерпрайзом. В результате завис во времени. Но в определенных ситуациях это может быть и плюсом.

Да я не спорю. Возможно, карма у меня такая, не на те проекты работаю :).

>Выполни вот это, например: SELECT id from example WHERE id IN(1, (SELECT IF(1=0,1,2/0))); Год назад это рушило редхатовский мускул. Если не упадёт ещё дам пару запросов.

Сейчас времени уже нет, но ближе к вечеру — обязательно. Если не забуду :)

> Ставите демьян и обновляетесь до unstable.

Стрёмно в продакшн его. С оглядкой на etch таки поставил stable в надежде что хотя бы года три он протянет. Правда, кое-что из бэкпортов таки пришлось ставить.

А в репозитории CentOS это скоро добавят? Или придется почувствовать себя маунтейнером?

>Стрёмно в продакшн его.

А убунту сразу после выпуска — не стремно?
Меж тем это практически одно и то же.

Нет, мы таки не юзаем сид в продакшне :)

mysql> use test;
Database changed

mysql> create table example (id int not null primary key auto_increment, test varchar(10));
Query OK, 0 rows affected (0.00 sec)

mysql> describe example;
+-------+-------------+------+-----+---------+----------------+
| Field | Type        | Null | Key | Default | Extra          |
+-------+-------------+------+-----+---------+----------------+
| id    | int(11)     |      | PRI | NULL    | auto_increment |
| test  | varchar(10) | YES  |     | NULL    |                |
+-------+-------------+------+-----+---------+----------------+
2 rows in set (0.00 sec)

mysql> insert into example set test='aa';
Query OK, 1 row affected (0.00 sec)

mysql> insert into example set test='bb';
Query OK, 1 row affected (0.00 sec)

mysql> SELECT id from example WHERE id IN(1, (SELECT IF(1=0,1,2/0)));
+----+
| id |
+----+
|  1 |
+----+
1 row in set (0.00 sec)

mysql> select * from example;
+----+------+
| id | test |
+----+------+
|  1 | aa   |
|  2 | bb   |
+----+------+
2 rows in set (0.00 sec)

mysql> 

Результат идентичен на RHEL 4 update 8 и CentOS 5.3. Поехали дальше по списочку? ;)

>А в репозитории CentOS это скоро добавят? Или придется почувствовать себя маунтейнером?

Ничего вы не понимаете! Вам предоставляется уникальная возможность испытать новые для себя ощущения, а вы... :D

Если серьезно, то в нормальных конторах «серверного профиля» уже давно есть собственные отделы сопровождения ПО.

to true_admin:

В Gentoo это есть, например...

Поправить Makefile?? Дома на одной машине, если очень хочется поставить - да, можно покопаться и поправить. Но я никогда не буду ставить систему, в которой возникают такие банальные ошибки, клиенту.

А теперь посмотри когда вышла дырка и когда к ней обновления: https://bugzilla.redhat.com/show_bug.cgi?id=240813

Вот он тру-интерпрайз. Я тестил в марте 2008-го дыры 2007-го. Завтра ещё скину ссылочку. Хотя, может и ту проблему закрыли. Но если они по 12 месяцев то мне жаль кастомеров.

Кстати, какая версия мускла у тебя? Что говорит \s?

Простите. а при чём тут дебаговые сборки и клиентские сервера?

Ты понимаешь что делает -pg?

И у меня в генте ничего не фильтруется, специально проверил(у меня, правда, очень старая гента). Ты проверял будет ли у тебя фильтроваться?

Видимо, они весь этот год его воспроизвести пытались :D

Нашел в нашем музее вычислительной техники экземпляр RHEL 4u6 (офиц. релиз 17 ноября 2007 года). Даже он не падает! Кстати, вот \s с него:

mysql> \s
--------------
mysql  Ver 14.7 Distrib 4.1.20, for redhat-linux-gnu (i686) using readline 4.3

Connection id:          201209
Current database:
Current user:           root@localhost
SSL:                    Not in use
Current pager:          stdout
Using outfile:          ''
Using delimiter:        ;
Server version:         4.1.20
Protocol version:       10
Connection:             Localhost via UNIX socket
Server characterset:    latin1
Db     characterset:    latin1
Client characterset:    latin1
Conn.  characterset:    latin1
UNIX socket:            /var/lib/mysql/mysql.sock
Uptime:                 31 min 10 sec

Threads: 1  Questions: 18  Slow queries: 0  Opens: 14  Flush tables: 1  Open tables: 7  Queries per second avg: 0.001
--------------

\s с центоса 5.3 (тоже не падает):

mysql> \s
--------------
mysql  Ver 14.12 Distrib 5.0.45, for redhat-linux-gnu (x86_64) using readline 5.0

Connection id:          3
Current database:
Current user:           root@localhost
SSL:                    Not in use
Current pager:          stdout
Using outfile:          ''
Using delimiter:        ;
Server version:         5.0.45 Source distribution
Protocol version:       10
Connection:             Localhost via UNIX socket
Server characterset:    latin1
Db     characterset:    latin1
Client characterset:    latin1
Conn.  characterset:    latin1
UNIX socket:            /var/lib/mysql/mysql.sock
Uptime:                 11 days 10 hours 33 min 32 sec

Threads: 13  Questions: 39466108  Slow queries: 0  Opens: 71  Flush tables: 1  Open tables: 64  Queries per second avg: 39.929
--------------

Впрочем, как я понял, этот баг специфичен только для ветки 5.0.

На единственном нашедшемся в нашем бардаке центосе 5.2 mysqld не оказалось :(

Такие дела.

Эээ, а каким образом у тебя mysql оказался 5.0.45 если в rhel5.1 оно было 5.0.27? 5.0.45 этому тупо не подвержена. А воспроизводилось оно у всех. И ты читал ту ссылку что я кидал? Они забили на баг а не пофиксили.