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

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

wfrr (05.02.2010 1:01:47)

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

nevar (05.02.2010 1:15:31)

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

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

nevar (05.02.2010 1:29:25)

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

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

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

isden (05.02.2010 3:06:03)

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

d1337r (05.02.2010 3:10:49)

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

Xenius (05.02.2010 3:26:42)

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

pevzi (05.02.2010 5:01:02)

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

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

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

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

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

morbo (05.02.2010 7:02:07)

Решето

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

Komintern (05.02.2010 8:11:07)

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

Два вопроса:

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

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

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

Komintern (05.02.2010 8:25:46)

> я сам использую 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
...

KRoN73 (05.02.2010 8:38:30)

Толсто.

KRoN73 (05.02.2010 8:39:06)

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

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

Byron (05.02.2010 9:03:28)

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

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

Byron (05.02.2010 9:05:56)

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

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

?

KRoN73 (05.02.2010 9:15:36)

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

nevar (05.02.2010 9:51:06)

Решето!

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

fractaler (05.02.2010 10:18:19)

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

yurkis (05.02.2010 10:37:33)

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

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

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

matumba (05.02.2010 10:56:56)

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

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

yurkis (05.02.2010 11:00:22)

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

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

queen3 (05.02.2010 11:12:56)

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

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

matumba (05.02.2010 11:16:01)

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

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

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

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

yurkis (05.02.2010 11:31:51)

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

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

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

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

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

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

rjaan (05.02.2010 11:35:13)

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

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

nevar (05.02.2010 11:37:28)

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

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

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

queen3 (05.02.2010 11:54:11)

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

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

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

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

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

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

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

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

Dead (05.02.2010 12:15:25)

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

queen3 (05.02.2010 12:29:42)

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

Shalakhin (05.02.2010 12:32:20)

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

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

nevar (05.02.2010 12:35:33)

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

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

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

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

nevar (05.02.2010 12:38:07)

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

>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 (05.02.2010 12:42:18)

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

rave (05.02.2010 12:45:52)

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

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

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

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

Дуршлак.