LINUX.ORG.RU

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

 , ,


0

0

Lighttpd версий до 1.4.26 и 1.5.x, выделяет буфер памяти для каждой операции чтения во время запроса. Это позволяет вызвать отказ в обслуживании (lighttpd начинает кушать всю доступную память), если разбить запрос на множество кусочков, отправляемых через большие промежутки времени. Принцип атаки: разбиваем запрос на байты и после каждого отправленного байта делается относительно небольшая пауза, например, в десятые доли секунды.

Баг трекер (код для атаки + патч)

Пререлиз 1.4.26 (исправленный)

>>> Подробности

★★

Проверено: svu ()
Последнее исправление: nevar (всего исправлений: 1)

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

anonymous
()

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

nevar ★★
() автор топика
Ответ на: комментарий от nevar

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

anonymous
()

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

isden ★★★★★
()

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

d1337r
()

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

pevzi ★★★★★
()

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

anon000
()
Ответ на: комментарий от anon000

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

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

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

anonymous
()

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

morbo
()

Решето

anonymous
()

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

Komintern ★★★★★
()
Ответ на: комментарий от Komintern

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

Два вопроса:

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

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

sergv
()
Ответ на: комментарий от Komintern

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

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

sergv
()
Ответ на: комментарий от Xenius

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

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

Byron
()
Ответ на: комментарий от anonymous

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

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

Byron
()
Ответ на: комментарий от roolebo

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

nevar ★★
() автор топика

Решето!

anonymous
()

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

fractaler ★★★★★
()

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

yurkis
()
Ответ на: комментарий от Byron

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

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

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

matumba ★★★★★
()
Ответ на: комментарий от matumba

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

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

yurkis
()
Ответ на: комментарий от yurkis

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

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

matumba ★★★★★
()
Ответ на: комментарий от matumba

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

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

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

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

yurkis
()
Ответ на: комментарий от anonymous

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

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

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


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

anonymous
()

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

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

rjaan ★★
()
Ответ на: комментарий от queen3

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

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

nevar ★★
() автор топика
Ответ на: комментарий от nevar

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

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

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

queen3 ★★★★★
()
Ответ на: комментарий от matumba

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

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

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

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

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

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

sergv
()
Ответ на: комментарий от queen3

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

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

Dead ★★★★
()
Ответ на: комментарий от queen3

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

Shalakhin
()
Ответ на: комментарий от queen3

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

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

nevar ★★
() автор топика
Ответ на: комментарий от queen3

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

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

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

sergv
()
Ответ на: комментарий от Dead

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

nevar ★★
() автор топика
Ответ на: комментарий от Dead

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

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

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

nevar ★★
() автор топика

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

rave
()

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

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

livid
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.