Жалко httpd имени Берштейна нет :)
А то бы сейчас подняли флейм :)

дело конечно поганое хоть на 32х битных юниксах и дос только однако пересобирать один хрен придеться ... а в месте с ним и php и mysql :-(((((((((( .... мля

западло и mod_ssl и mod_auth_pgsql ;))

ммм. народ, вы бы на http://apache.lexa.ru сходили, там как раз это только что обсуждали. смысл этого переполнения:

----------- On Tue, 18 Jun 2002, Igor Sysoev wrote:

> On Tue, 18 Jun 2002, Yury Bokhoncovich wrote: > > > Ну, и что общественность по этому поводу думает? > > На самом деле, vulnerability не так страшна, как её малюют. > > Во всех стандартных модулях, которые читают тело запроса - > mod_cgi, mod_proxy, mod_isapi - при chunked возвращается ошибка. > В mod_accel, кстати, тоже. Насколько я знаю, ни один бразуер это > просто не поддерживает. > > Единственное место, где в стандартном Apache воспринимается > chunk'нутое тело запроса - это ap_discard_request_body(). > Но там используется 8K буфер, а его размер просто не попадает под > vulnerability.

Взглянув на патч ещё раз, заметил, что vulnerability проявляется только при размере буфера больше 2G. Я сильно сомневаюсь, что где-то используются такие буфера.

Так что это не vulnerability, а пшик. А шуму-то:

Apache: ISS X-Force has discovered a serious vulnerability in the default version of Apache HTTP Server . A flawed mechanism that calculates the size of "chunked" encoding may lead to modified Web content, denial of service, or further compromise. Apache accounts for over 63% of all active Web sites.

Игорь Сысоев -----------

Почитайте там же по треду позднее. Смысл переполнения совсем в другом и дырка все же есть. Но на Russian Apache проявляется только если его функционал отключен (CharsetDisable On).

to anonymous (*) (2002-06-18 15:41:34.14) httpd имени Бернштейна есть - publicfile тока оно тока для статического контента

Ы да ладно половина серверов особенно тех которые на php и mysql досится просто большой нагрузкой. Написал скрипт в шеле с циклом а в цикле wget blablabla & и половина серверов динамических выпадет.

Apache тяжеловат и дыряв. Использую его только в качестве прокси, который раздает
запросы backend-серверам. Если бы нашел нормальный легкий проксик, который может ProxyPass,
выбросил бы апачу уже давно. Может кто подскажет что-то похожее?

Интересно !!!

Использовать WEB-сервер только в качестве PROXY??

Круто!

>пересобирать один хрен придеться

ха-ха. В правильных дистрибутивах достаточно apt-get update; apt-get dist-upgrade. Или больше заняться нечем, кроме как компилить,компилить, компилить?

2 anonymous (*) (2002-06-19 08:41:47.403) > Apache тяжеловат и дыряв.

с дуба рухнул ?

2 anonymous (*) (2002-06-19 09:09:07.902) > ха-ха. В правильных дистрибутивах достаточно apt-get update мальчик идика лучше сессию здавать ... дяди сами разберуться ...

> Использовать WEB-сервер только в качестве PROXY??

Да-да-да. Только не абстрактный WEB-сервер, а конкретно апач. Убираю из него все, что можно,
то есть максимально облегчаю, и вперед за работу в качестве прокси. Только в этом
случае я добиваюсь приемлимого использования памяти, которое растет не более чем на 20-30% от
исходного состояния после старта. Для сервера это очень важно - четкое прогнозирование
и желательно умеренное использование памяти. Классический одиночный апач с mod_perl/mod_php
в этом смысле полный отстой.

А что тогда не отстой?

2 anonymous (*) (2002-06-19 10:59:24.399):
Тебя и спрашивают не рухнул ли ты с дуба. Что тот же сквид хуже apache как прокси?

> тяжеловат и дыряв
тяжеловат... может быть... thttpd его по слухам делает на большом траффике, но дыряв... за сколько времени это первая уязвимость? И отмазка что не ищут - не принемается... он стоит на большей части серверов в инете...

> Тебя и спрашивают не рухнул ли ты с дуба. Что тот же сквид хуже apache как прокси?

Наверно имелся ввиду proxy на стороне сервера ?

> Что тот же сквид хуже apache как прокси?

А не рухнул ли ты с баобаба? Более глупого совета придумать невозможно.
Возникает сомнение, знаешь ли ты вообще предназначение прокси...

> тяжеловат... может быть... thttpd его по слухам делает на большом траффике,

Вот-вот, похоже все твои знания о предмете основаны на слухах. А дыры в апаче появляются
не реже чем раз в полгода без всяких слухов. Кому-то это нормально, а меня не устраивает.
Я ставлю сервер на автономную работу с расчетом на год и более. Единственные
проблемные сервисы - апаче и mysql. С остальным проблемы решены давно.
С апаче проблема частично решается переводом его в чистый прокси.

А squid не может работать у сервера как прокси? в доках про это было...

2 anonymous (*) (2002-06-19 13:31:05.077) мля какие дыры в апаче последняя дыра в апаче была на моей памяти много много лет назад ... ты тогда еще под стол пешком ходил ... чуш не пари ... развели сдесь ...

2anonymous (*) (2002-06-19 13:51:05.453)
А если глаза разуть? grep security apache/src/CHANGES. Потом есть много
фактов наличия дыр в его модулях. Было несколько DoS типа последнего.
Короче, хватает, если приглядеться. Но главная проблема лично для меня -
его немерянный аппетит к ресурсам.

> А squid не может работать у сервера как прокси?
А squid можешь засунуть себе в задницу. Если апач тяжел как прокси, то
squid эта ваще туши свет зажигай факел ложись под сервер.

2 anonymous (*) (2002-06-19 14:13:55.058) все эти так называемые дыры фуфло полное .... причем здесь количество упоминаний .... ты реально какие из них пользуеш ;-) ... вот вот ... эта единственная более менее приличная ... в смысле перспектив на 64x битных плотформах ... а так ... в принципе значимость у нее 0 когда эксплоиты выйдут из undeground'а этим уже никого не возьмеш (я про 64 бита)

про то что индеец тормазит ? ты его чего на 486 пускаеш ? не смеши ...

Нелюбителю squid'a - попробуй oops

> Нелюбителю squid'a - попробуй oops

Еще один "доброжелатель". Мне работать нужно, а не трахаться с очередным глюкалом.
Короче, проксик должен быть не более 100K объемом бинарника и виртуально
не потреблять вообще памяти (то есть 0,5-1 Мб максимум). И естественно быть
абсолютно надежным и непробиваемым.

2anonymous (*) (2002-06-19 14:22:11.968)
Дыры там не фуфло, а дыры. Просмотр содержимого закрытого каталога для тебя
может и фуфло, а для меня дыра. Тормозит на большом количестве коннекций,
когда раздувается настолько, что попадает в своп. А в своп попадает потому, что
суксь и bloatware. Потому и ставлю его только на раздачу, а работу делают нормальные
веб-сервера. Но и на раздаче ему не место, потому ищу ему замену и на этой непыльной работе...

Кстати дыры - это не только сам апаче, это и mod_ssl, имевший их несколко раз,
и mod_php и т.д.

А чего же такие классные вебсервера сами боятся стоять на раздаче?

У них просто отсутствует аналог апачевского ProxyPass, да и не нужен он
нормальному вебсерверу. Пойми, эта работа _прокси_, а не вебсервера. Сложно, да? ;)

2anonymous (*) (2002-06-19 10:59:24.399) память жрут тяжелые модули типа mod_php, согласен. НО! решается это просто: maxrequiestrepchild 1000

и занимаемый объем оперативки становиться легко прогнозируемым :)))

просвятите меня пожалуйста нелюбитель апача:
что есть нормальный веб-сервер(апач тут уже закидали)?
что используете?

Nickolay

> НО! решается это просто: maxrequiestrepchild 1000

Да неужели? А до того как счет дойдет до 1000 все OK значит?
Пробовали. Те же яйца, только вид с боку. Реально память забивается на
первых 100 запросах.

> что есть нормальный веб-сервер

Просвещаю. Все доводы как обычно IMHO, но подкреплены многолетним опытом, иногда горьким ;(
Код должен быть небольшой и по возможности прозрачный, чтобы секьюрность была
видна на лицо и проверялась элементарно. Ничего лишнего. Каждая отдельная операция
должна выполняться отдельной прогой под своим uid/gid. Как правило это должен быть
select/poll-based серверок. Должон легко делать несколько тысяч запросов
на статике до 30Кб на проце от 1Ггц. Должен кушать в районе не более 10-20 Мб памяти
для 500-1000 одновремнных http-1.1 запросов. Вот такая в кратце картина...

О просвещенный anonymous, ты не гони, ты имя назови ;)

Для статики, думается мне, можно вообще на коленке сервер склепать за неделю. Будет ужас какой легкий и производительный. И секьюрный вполне, ибо аудится легко по прицине миниатюрности.

Апач же не для этого делался, надо думать.

kaa

2 anonymous (*) (2002-06-19 15:48:53.028) мля mod_rewrite mod_хуяят чего ты париш ты этими модулями пользуешся ??? и ненадо тут заливать просто когда индейца собираеш остовляй только те модули что тебе действительно нужны php и ssl это уже савсем другой разговор ... ты бы так отстраненно свои посты почитал уписаться можно ... да ты наверное прав apache очень дыря не в пример там tux'ам энтерпрайсам и иис ;-)

> Просвещаю. Все до...
Имя брат, имя!!!
что вы используете в качестве прокси так не любимый вами апач это все уже поняли, а вот что вы используете в качестве веб-сервера???
народ требует имя!!!

Nickolay

А имя ЕМУ - Легион ;) (c) Евангелие от Матфея

Да IIS у него сервак, трудно догадаться что-ли :)

IIS к-сожалению не подходит ни под одно условие ;(

2 anonymous (*) (2002-06-19 13:29:58.057):
Ага... Это я понял, но решенние, когда web-сервер начинает кэшировать запросы имеет кучу недостатков, в частности сниженние масштабируемости самого вебсервера. Со сквидом посередине это дело можно неплохо распараллелить. Хотя каюсь не вкупился... мозги зашарило слету в то, о чем была речь.

anonymous (*) (2002-06-19 13:31:05.077):
> Вот-вот, похоже все твои знания о предмете основаны на слухах.
Ок. Слух - это результат беседы с ребятами, что занимаются созданием решенния для хостинга. Траффик 250Mb в кластере на каждую машину - Apache настолько шустро начинает форкаться, что съедает все pid'ы... на thttpd живет все просто за...сь.


> не реже чем раз в полгода без всяких слухов.
Да уж... если у меня слухи, то у тебя в голове в общем - то вообще ветер гуляет. Вот тебе почитать на досуге. (Ветка 1.3 началась афаир в 1998 году,... подтверди пожалуйста свои слова о дырке раз в полгода, а то как то по пи...льски твое заявленние видится):
http://www.apache.org/dist/httpd/CHANGES_1.3

ебать копать (русское народное не матное выражение) заглянитика на пакетшторм ... мля ... кто там говарил про не ЭКСПЛУАТИРУЕМОСТ 32х ЮНИКСОВ .... да труба ..

Поздравляю, засранцы!
Появился эксплоит: http://online.securityfocus.com/bid/5033/exploit/

Об этом говорилось в бюллетене от CERT, по крайней мере. И об этом же говорил Дэвид Литчфильд из NGGSOFTWARE. Видать-ошибались... http://www.cert.org/advisories/CA-2002-17.html

> Ага... Это я понял, но решенние, когда web-сервер начинает кэшировать запросы

Нихрена ты, следовательно, не понял. Про кеширование здесь никто даже не заикался.
Эт тебе померещилось. Прокси = squid = кеширование. Вот твое убогое мышление в зеркале.

Kudos to
* the OpenBSD developers (Theo, DugSong, jnathan, *@#!w00w00, ...) and
* their crappy memcpy implementation that makes this 32-bit impossibility
* very easy to accomplish.

Отличное наказание за рисовку насчет "Five years without a remote hole in the default install".
default package = kernel ;))))

Я всегда знал, что эти лозунги - дешевка.

все openbsdшники лохи

2 anonymous (*) (2002-06-20 23:21:23.75):
> Нихрена ты, следовательно, не понял.
Взял бы и объяснил. Или знаний не хватает? Пердеть в космос все мостаки.

> Вот твое убогое мышление в зеркале.
Ах да. Господин с IQ>999. А по лексике и по обоснованности заявленний я бы предположил у тебя что - нибудь около 90.

А в опсе сломали кешинг на диск... Правда при использовании его как http accel это нафиг ненужно ;)

> Взял бы и объяснил.

Могила тебя поправит. Там и знаний наберешься.

---

Тому, у кого апач память забивает... А ulimits+mod_accel не пробовали? Странно, но помогает!

Уфф... опять этот прыщ вылез ;((
Научил я его на свою голову, как использовать ulimit, даже кажется переучил.
Ну дык почти полтора года обучение длилось, всякие накладки могли быть...
Кажись переборщил малость, он сейчас этот ulimit чуть ли вместо passwd пользует ;-)
Но самое страшное, что ему это помогает.....