В lighttpd найдена критическая уязвимость.

Ну вот б..... боевой сервак положил, теперь отрывать зад и тащить его к серверу для ребута...

рукоблудник, нефиг всякую каку в прдакшн пускать

Что самое интересное, вроде же можно завесить с модема одним компом и всего за несколько минут. Тут даже ботнет не нужен

Рядом с серваком в клетке сидит белк, если белк получаит током он нажимает резет.

гринпис бы на чью-то голову...

Рядом с серваком в клетке сидит гринписовец, если белк получает орешек, то нажимает кнопку, гринписовец получает током и давит резет.

Какое «найдена», когда она уже исправлена. Найдена она была 6 января.

ох жеж, ну и решето... такого я не ожидал :(

всего лишь DoS и уже исправлена.

Стиль новости своеобразный:
«кушает память»

Охщи. У меня как раз оно ._.

Не зря я выбрал nginx, хотя тут был эпический тред в котором многие достойные лоровцы хвалили лайти.

> Не зря я выбрал nginx, хотя тут был эпический тред в котором многие достойные лоровцы хвалили лайти.

Мир вообще захватывает решето. Чем больше упоминаний в багтрекере - тем больше рекламы, и тем больше популярности. Windows, Firefox, nginx это прекрасно доказывают. Вот и глобальный и надёжный решил попробовать по-мелочи, до nginx ему вообще далеко.

Да и nginx же только генератор 502 ошибок, как полноценный сервер его сложно использовать? А lighttpd не нуждается в доп. костыле для работы.

В Debian эту дырку закрыли ещё 2 числа.

Решето

и какое только г*вно не юзают нищеброды чтобы не добавлять на сервак памяти и не юзать нормальный апач...

> чтобы не добавлять на сервак памяти и не юзать нормальный апач

Два вопроса:

1) Кто сказал, что апач - нормальный? (Багтрек у него нимало не меньше).

2) На конфигурацию lighttpd, mathopd или nginx не смотрели? Весьма советую - индеец нервно курит всторонке.

я сам использую nginx - но только в качестве фронтенда к апачу :) так что на его конфиг я смотрел.

> я сам использую nginx - но только в качестве фронтенда к апачу :) так что на его конфиг я смотрел.

А можно его и как морду к lighttpd или mathopd использовать. Намного легче настраивается. Только модулей сторонних заметно меньше.

>Не зря я выбрал nginx

Бегло, так:
http://www.linux.org.ru/forum/admin/4044049
http://www.linux.org.ru/news/security/4045266
http://www.linux.org.ru/news/security/4174030
...

Толсто.

> Стиль новости своеобразный: «кушает память»

Просто это интеллигентный баг. Вот если бы он был в быдлопрограмме, то обязательно написали бы «жрёт память», а после, возможно, добавили: «скотина».

> боевой сервак положил, теперь отрывать зад и тащить его к серверу для ребута.

Перегрузка зада в серверной? Нет пути.

Откатываюсь на 1.4.25

>Откатываюсь на 1.4.25

?

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

Решето!

Всего лишь DoS — не решето.

Вот в embedded не обрадуются...

> Вот если бы он был в быдлопрограмме, то обязательно написали бы «жрёт память», а после, возможно, добавили: «скотина».

LOL :)))))))))))))))))

По-хорошему, весь линуксофт - некое подобие быдлоподелий. Каждый творит в меру своей развитости - одни постоянно делают dim a(10), другие вот память выделяют под каждый запрос... :) Это нормально. Ненормально - это продолжать юзать атавизмы вроде си-сипипи, провоцирующие всякие низкоуровневые ляпы.

>Ненормально - это продолжать юзать атавизмы вроде си-сипипи, провоцирующие всякие низкоуровневые ляпы.

К сожалению (или к счастью) пока что есть ниши которые C/C++ не отдаст никому. И, кстати, вебсерверы (особенно легковесные с прицелом на embedded)- одна из таких ниш.

отправляемых через НЕбольшие промежутки времени

Может вот так?

> есть ниши которые C/C++ не отдаст никому

А кто его будет спрашивать? :)
Как я понимаю, Си - это высокоуровневый ассемблер. Ежегодно тратить время на однообразные утилиты - непозволительная роскошь, поэтому задвинуть этот архаизм 70-ых - только на пользу. Я сильно сомневаюсь, что хотя бы 1% софта (даже системного) нужен такой «типамощный» язык с доступом к регистрам, битам, произвольным указателям... По сути, даже драйвер диска есть та же «прикладуха» с алгоритмами оптимального доступа, распределения буферов, разве что на последних стадиях (самых кратких) идут всякие DMA и I/O с портами. Ну и накой ляд там Си? Даже Пистон, не к ночи будет упомянут, прекрасно справится с этой задачей, заюзав внешние asm-библиотечки. Так что роль Си настолько узкая, что легко ужимается до ассемблерных вставок, остальное прекрасно разрулит высокоуровневый язык. А «прикладухе» вообще этот Си не упёрся - там не то что биты, даже работа с памятью может быть полностью спрятана под капот. Ну и?

>Я сильно сомневаюсь, что хотя бы 1% софта (даже системного) нужен такой «типамощный» язык с доступом к регистрам, битам, произвольным указателям...

На вскидку: 1. Само собой ядро 2. Любой софт в задачах чувствительных к быстродействию и памяти (хотя бы те же нагруженые серверы и embedded).

По сути, даже драйвер диска есть та же «прикладуха» с алгоритмами оптимального доступа, распределения буферов, разве что на последних стадиях (самых кратких) идут всякие DMA и I/O с портами. Ну и накой ляд там Си? Даже Пистон, не к ночи будет упомянут, прекрасно справится с этой задачей, заюзав внешние asm-библиотечки.

... и потом оно будет тооооормозить и жрать оперативку. Улыбнуло.

> Да и nginx же только генератор 502 ошибок

наверное когда тебя родители генерировали, то у них резиновый шлюз протек ненароком

как полноценный сервер его сложно использовать?

угу. но ты не печалься, специально для тебя сделали ИИС - пользуйся

Какая старая новость, Debian обновил lighttpd, ещё три дня назад ;-)

О самом lighttpd ничего плохого сказать не могу — не юзаю ;-))))

Не так. Для сервака вряд ли можно считать маленьким промежуток времени в 0.01 секунду, особенно для хорошо нагруженного.

Простите, я в этом дилетант.

Да, действительно,

If you send the request data very slow (e.g. sleep 0.01 after each byte)...

Я тоже не специалист в серверах, но мне как программисту скорее интересно, почему этот глюк не происходит, если данные посылать часто.

> А «прикладухе» вообще этот Си не упёрся - там не то что биты, даже работа с памятью может быть полностью спрятана под капот.

Простая задача - работа с большим списком CIDR (IP/mask если кто не вкурсе). Списочек скромен, около 10 милионов записей. Чистая «прикладуха» - автоматизация собственного труда. Однако в Вашу концепцию не вписявается НИКАК!

1) Работа с битими и битовыми масками (иначе памяти жрет не просто МНОГО, а БЕЗУМНО много).

2) Тот-же PERL по сравнению с чистым C тормозит не то, что в разы. Он тормозит на ПОРЯДОК и более. (0.8 сек. против 13 сек.)

3) По памяти под приложение - перловая кашица жрала тоже на порядок больше памяти. (50 МБ против > 512 МБ).

Наверняка сию приблуду можно было написать на каком-нибудь там паскале чи модуле, только при наличии C что-то как-то неохота, как-то что-то лень...

>Я тоже не специалист в серверах, но мне как программисту скорее интересно, почему этот глюк не происходит, если данные посылать часто.

Рискну предположить, что частые запросы в таком случае будут объединены в один большой и глюка не будет.

Моно, очевидно же :-)

Ну и ничего. Исправят баг и сервер станет еще лучше. :)

Боюсь ступить, но если данные посылаются непрерывным потоком без задержек, то на них всех выделяется один кусок памяти. То есть всё работает нормально.

А если по байту и с задержкой, то получается, что лайти «понимает»,что это один запрос(хоть и разбитый), а с памятью для этого разбитого запроса работает как с разными запросами. Хм, как-то запутанно сказал... ну вы поняли.

> Моно, очевидно же :-)

Ага, только этого «монстрика» и графической оболочки мне на сервере и недостает. ;-)

Уж лучше сразу форточки поставить. Только потом еще придется долго учится их «правильно готовить» Ибо неумею я, темный человек, измученный нарзаном (тоесть UNIX/Linux).

Если я правильно понял, то тут дело не в частых запросах, а в одном, но разбитом на куски.

как писал заявитель бага:

I wrote a C program which sends a HTTP request to lighttpd very slowly, one byte each second (write 1 bytes, then sleep 1 second

написано HTTP request, а не HTTP requests

то есть таки один запрос, а не много.

Опаньки, а в убунте еще не обновили. Надо бы от дядюшки дебиана взять пакетик.

Новость-то с душком, в дженту уже первого февраля исправили.

01 Feb 2010; Christian Hoffmann <hoffie@gentoo.org> +lighttpd-1.4.25-r1.ebuild, +files/1.4.25-fix-CVE-2010-0295.patch

> угу. но ты не печалься, специально для тебя сделали ИИС - пользуйся

дальше спрашивать не буду, но видимо по этому тянет сравнивать именно нжнх с иис? какая разница, какой сорт ... лучше, если есть нормальный lighttpd?

Дуршлак.