LINUX.ORG.RU

Новая серьезная уязвимость веб-сервера Apache

 , ,


0

2

Обнаружена уязвимость в веб-сервере Apache, позволяющая провести атаку на приложение версии 2.2.х. Уязвимость находится в коде, отвечающем за обработку байтовых диапазонов, указанных в специальных HTTP-заголовках. Как известно, задание байтового диапазона позволяет загружать только определенную часть документа, например с 500-ого по 1000-ный байт. Данные заголовки широко используются, в частности, в менеджерах загрузки файлов для возобновления скачивания после паузы или разрыва соединения, а также позволяют снизить объем передаваемого трафика. Однако как показывает исследование, указание в заголовке нескольких неотсортированных диапазонов может привести к нарушению работы веб-сервера.

Уже опубликован perl-скрипт, демонстрирующий наличие проблемы и вызывающий падение веб-сервера Apache. Скрипт посылает серверу GET-запрос c заданием нескольких байтовых диапазонов, что при обработке приводит к серьезному увеличению потребления оперативной памяти.

Команда разработчиков пока не представила официального патча для исправления проблемы, однако на данный момент доступно решение, заключающееся в установке правила принимать только запросы с одним заданным байтовым диапазоном, что решит проблему для большинства веб-серверов. Для работы указанного способа необходимо загрузить в веб-сервер Apache модуль mod_rewrite.

Другим средством решения проблемы является использование модуля mod_headers с параметром RequestHeader unset Range, который удаляет из заголовка все содержащиеся в нем байтовые диапазоны. От этого способа больше вреда, чем пользы, поэтому администраторы перед применением любого решения для борьбы с уязвимостью должны проверить его эффективность и влияние на работу веб-сервера.

>>> Подробности

★★★★★

Проверено: maxcom ()

Проверил, увеличение потребление оперативки не обнаружено, просто CPU на 99% грузит. Apache 2.2.19 не падает.

qbbr ★★★★ ()
Ответ на: комментарий от qbbr

фактичкески, это легчайший по затратам вариант дос.

Нет, не зря я уже несколько лет как перешел на лайти. Оно, конечно, сложнее, но работает стабильно.

AVL2 ★★★★★ ()

не сработает если апач работает бекендом к nginx.

Komintern ★★★★★ ()

Таакссс, опять намечается падеж скота в этих ваших интернетах?

splinter ★★★★★ ()
Ответ на: комментарий от Komintern

То есть ни у кого неленивого не сработает, ибо все стараются его только как бэкенд юзать.

pekmop1024 ★★★★★ ()

/me вспоминает

Apache нужен!

KRoN73 ★★★★★ ()

в толксах обсудили

muon ★★★ ()

хорошо еще что не remote root

xtraeft ★★☆☆ ()

кстати в логах как это заметно, ну если тебя подобной штуковиной атаковали?

splinter ★★★★★ ()

Проблема не в апаче, а в RFC.

leave ★★★★★ ()

wget с нескольких сайтов перестал докачивать контент. После такой новости не удивительно.

CryptSpirit ()

проверил, работает :)))))) сервак отвечает но по ssh зайти не могу, видимо проц загружен

maxik73 ()
Ответ на: комментарий от Komintern

Естессно. nginx всегда отдает 50X ошибку.

AVL2 ★★★★★ ()

> Новая серьезная уязвимость веб-сервера Apache

RIP. Заняться что ли Nginx вплотную.

anonymous ()
Ответ на: комментарий от AVL2

>Оно, конечно, сложнее, но работает стабильно.

А утечки памяти там пофиксили?

X-Pilot ★★★★★ ()
Ответ на: комментарий от anonymous

А чем он лучше? Пользовательская база в 10 раз меньше, вот и меньше отакуют:)

petrosha ★★★★★ ()
Ответ на: комментарий от petrosha

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

Komintern ★★★★★ ()
Ответ на: комментарий от AVL2

В лайти была абсолютно та же самая дырка. Просто ее давно закрыли.
И нгникс тоже как-то на подобном прокалывался, но там пофиксили в мгновение ока.

iSage ★★★★ ()

Уже пробовал, не сработало. Да, нагрузка возросла, да задержка ответа выросла, но ничего не упало, да и вообще работа практически не была нарушена.

улыбка-mode: о данной уязвимости, мне сегодня, с явным удовольствием, поспешил сообщить фанатик nginx

AGUtilities ★★★ ()
Ответ на: комментарий от Komintern

а что, разве сквид нельзя использовать в качестве кешера? ябы скорее сквид предпочёл, чем nginx.

AGUtilities ★★★ ()
Ответ на: комментарий от AGUtilities

совсем разные задачи. nginx и lighttpd рассчитаны на высокую нагрузку, хотя для кеша лучше varnish.

apache не нужен - nginx и lighttpd рулят, а для php давно появился рабочий FSGI/fmp. Все остальное работает с собственными серверами.

XVilka ★★★★ ()
Ответ на: комментарий от XVilka

Угу. У нас на одном проекте в итоге схема выглядит так: nginx(статика)->varnish(горячий кеш)->nginx(статический кеш)->php-fpm

iSage ★★★★ ()
Ответ на: комментарий от XVilka

> apache не нужен

апач нужен, для хостинга так точно.
не заставишь пользователей переписывать свои .htaccess-ы под твои rewrite-правила в nginx, еще over9k всяких примочек, не особо нужных, но полезных - апач все же дает. да и как не крути, стандарт это.

Komintern ★★★★★ ()
Ответ на: комментарий от AGUtilities

мы о разных кешах говорим.
кеш со стороны клиента да, можно реализовать сквидом. но кеширование той же статики со стороны веб-сервера - лучше чем nginx не встречал ничего.

Komintern ★★★★★ ()
Ответ на: комментарий от Komintern

Ну, тот кто shared хостинг пользует - тот пусть не жалуется на проблемы в безопасности. Они по сто лет не обновляют софт.

XVilka ★★★★ ()
Ответ на: комментарий от AGUtilities

Ухаха. Часом не локахост админите?

anonymous ()
Ответ на: комментарий от Komintern

реврайты суть костыль, приложение должно само полностью решать что делать с uri

anonymous ()
Ответ на: комментарий от Komintern

Я вот проекты на питоне разрабатываю, могу с уверенностью сказать - для их хостинга апач вообще не нужен. Достаточно крутой интеграции nginx и uwsgi, а конфиги писать легко и приятно, работает все быстро и стабильно.

enchantner ()

что как бы намекает нам, что давно пора пользоваться связкой nginx|fastcgi вместо этого глюкала и обжоры.

tazhate ★★★★★ ()
Ответ на: комментарий от Komintern

не заставишь пользователей переписывать свои .htaccess-ы под твои rewrite-правила в nginx

у меня на этот случай стоит парсер на перлах

tazhate ★★★★★ ()
Ответ на: комментарий от qbbr

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

polovinamozga ()

/me почесал свой лайти

Апач уг и не нужен.

PolarFox ★★★★★ ()
Ответ на: комментарий от polovinamozga

Работоспособный. Просто не универсальный, ибо PoC.

iSage ★★★★ ()
Ответ на: комментарий от XVilka

> apache не нужен - nginx и lighttpd рулят, а для php давно появился рабочий FSGI/fmp. Все остальное работает с собственными серверами.

Для PHP уже давно появилось ежедневное чтение списка уязвимостей с постоянным вставанием волос дыбом. После этого обычно php на сервере отключают, как класс.

kid_lester ()
Ответ на: комментарий от iSage

>В лайти была абсолютно та же самая дырка. Просто ее давно закрыли.

ну так все гениальное просто. Просто давно закрыли. Поэтому лайти, все давно закрыто.

AVL2 ★★★★★ ()
Ответ на: комментарий от polovinamozga

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

Хоть намекни, где подвох искать?

kid_lester ()
Ответ на: комментарий от AVL2

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

iSage ★★★★ ()

Неужели кто то выставляет апач наружу? Nginx наше Фсио.

bonds ()

Надо же. У меня на localhost не один виртуальный домен заведен. Для разработки, конечно. И тестирования. Может на nqnix перелезть? С FastCGI? Благо в php 5.3 FastCGI хорош, раньше патч отдельный был для этого дела, а теперь всё из коробки.

lucentcode ★★★★★ ()

Не знаю, PoC, не PoC, но не один сервер серьёзно не нагрузило.

skyline ()
Ответ на: комментарий от bonds

>Nginx наше Фсио

вот когда под ущербный от рождения nginx вендоры будут писать поддержку kerberos, sso, ajp и пр. хлама, тогда и можно будет говорить нужен/не нужен. А пока ответственно заявляю: rambler не нужен.

borisych ★★★★★ ()

Забавно что багу можно прикрыть средствами самого апача :)

Rost ★★★★ ()
Ответ на: комментарий от Rost

>Забавно что багу можно прикрыть средствами самого апача :)

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

skyline ()
Ответ на: комментарий от skyline

Какого функционала? Бага прикрывается рерайтом, отрезающим излишки от Range.

iSage ★★★★ ()
Ответ на: комментарий от borisych

А на кой все это говно нужно выставлять жопой в интернет?

Reset ★★★★★ ()

Очень странно, что такая элементарная уязвимость, и так поздно замечена. Про байтовые диапазоны читаю впервые. Но вот каким образом они могут быть неотсортированы даже не представляю. По алфавиту что ли? Честно старался это понять, но видимо, не прочитав огромный мануал чистой технической инфы о том, как А - это одно, а Ж - это другое одно, будем удивляться и дальше.

anonymous ()
Ответ на: комментарий от Reset

вероятно для кого-то интернет не только помойка, состоящая из бложиков, порнужи и прочего мусора

borisych ★★★★★ ()

> Host does not seem vulnerable

Debian 6. Ы?

YAR ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.