LINUX.ORG.RU

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

 , ,


0

0

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

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

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

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

★★

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

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

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

Предлагаете обработку прерываний и шедулер задач на Питоне писать? Какой вуз/кафедру окончили? %)

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

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

Пеши исчо!

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

Глядишь и не обновят :) lighttpd находится в universe, а вот что космнавты пишут про universe:

http://www.ubuntu.com/community/ubuntustory/components

The basic toolchain and system libraries from main are still used to build this software and it is normally maintained in step with them, so it should install and work well with the software in main, but it comes with no guarantee of security fixes and support.

и где тот анонимус, который так фанатично любит hardy и у которого стрелки в less не работали...

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

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

В TCP интенсивно используется буферизация (и алгоритм Нейгла). Как минимум отправитель должен использовать опцию сокета NODELAY (полагаю, тогда можно и часто).

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

> Как минимум отправитель должен использовать опцию сокета NODELAY (полагаю, тогда можно и часто).

Кажется, я вру. Если не спать хоть чуточку, то буферизация всё равно будет и при NODELAY. Так что надо немного спать.

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

Т.е., судя по описанию алгоритма, дело не в принимающей стороне, а в том, что отсылающая сторона кэширует малые пакеты (пока не получен отклик на предыдущий, но это не принципиально)?

Тогда понятно. А то я думал, там хитрые оптимизации таймаутов/очередей/буферов на принятие пакетов и т.п. С передающей-то стороны кэшировать такие вещи гораздо логичнее.

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

> и где тот анонимус, который так фанатично любит hardy и у которого стрелки в less не работали...

кстати, да, это я, в lenny - обновилось, в hardy - нет. но universe в убунте и main в debian находятся на одинаковом положении - поддерживаемые сообществом.

корень проблемы вообще в том, почему lighttpd не в маин. лучше бы сделали нищебродский стек OLPS OpenVZ / Lighttpd / Php-Fcgi / SQlite

от того, что какой-то патч попал в debian раньше, чем в hardy (всё таки lenny - это текущий релиз, а как там с этим в etch?) не значит, что lenny перестанут поддерживать вообще целиком через год с копейками, тогда как main hardy - до 2013 года.

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

Кто-то бухает, а кто-то колется.

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

Вы конфигурацию всех индейцев видели? У Apache — ужас, у Cherokee — вообще страшный мрак, основным конфигуратором является веб-гуй, который генерит текстовый файл, создание текстового конфига не предусмотрено и документации по нему нет. А вот Hiawatha — конфетка.

Camel ★★★★★
()
Ответ на: КО в тред. от Camel

> Спросил анонимус в треде о РЕШЕТЕ.

Неуловимый Джо, не из вашего, случаем, племени?

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

Hiawatha rules.

Неуловимый Джо, не из вашего, случаем, племени?

Да ты чё! Hiawatha установлен на 3,5 локалхостах!

На самом деле нормальный веб-сервер. Я его использую на домашнем сервере (видно из интернетов), работает, есть не просит.

Camel ★★★★★
()
Ответ на: Hiawatha rules. от Camel

я его там же и тыкал, php-fcgi умеет, а большее я не тыкал. есть ли рерайтинг урл, есть ли удобный vhost, т.е. какие приемущества перед lighttpd, кроме того, что lighttpd решето?

фичи, производительность?

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

Вменяемость.

я его там же и тыкал, php-fcgi умеет, а большее я не тыкал. есть ли рерайтинг урл, есть ли удобный vhost,

Я не знаю что такое php-fcgi, но PHP'шная программа у меня прекрасно работает через FastCGI (Wordpress). На том же хосте в вирт.хосте работает MediaWiki. Rewrite URL есть. Что ещё надо?

Hiawatha не умеет reverse proxy, и не надо. Я использую для этого дела Pound и очень доволен, unix way'но.

Camel ★★★★★
()
Ответ на: Вменяемость. от Camel

LOR такой LOR

уязвимость реализуется в парсере HTTP/1.1 chunk encoding т.е. при аплоаде файла или длинного POST

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

Вата это неприлично.

А вот Hiawatha — конфетка.

Это - не пробовал. Для меня название читается сугубо матерно ;-).

Вас смущает слово «вата»? :-]

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

Huewatha.

Для непонятливых: при беглом просмотре оно выглядит как hUiawatha.

Да хоть Huewatha, всё равно по-русски оно на самом деле читается «Гайявата». О как.

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

У тебя крупные проблемы с беглым просмотром.

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