Подвержен ли Tomcat этой уязвимости? Здесь информационное сообщение.
По сути, эта уязвимость заставляет сервер Apache создавать массивный ответ на запрос одного файла, намного большего размера, чем сам файл. Хотя RFC (2616) указывает веб-службам принимать несколько диапазонов, ничего не говорит о том, что диапазоны не могут перекрываться. Плохая реализация со стороны Apache, но есть большая вероятность, что другие веб-серверы уязвимы.
Большинство сервлетов Tomcat не позволяют Range запросов, поскольку это настраиваемая реализация фильтра для выделения нужных фрагментов контента. Однако сервлет по умолчанию (который обрабатывает статический контент) - это совсем другая история.
Текущий код Tomcat (Вот) принимает несколько наборов диапазонов, проверяет каждый из них индивидуально, что он находится в пределах размера файла, и помещает его в список диапазонов для обслуживания. Однако диапазоны последовательно передаются из внутреннего кеша сервлета, и процесс должен быть немедленно остановлен, если клиент, запрашивающий данные, отключается; в большинстве случаев это должно сделать запрос перекрывающегося диапазона примерно эквивалентным влиянию на производительность обслуживания большого файла.
И, в подтверждение, быстрый тест ..
Мы отправим вам быстрый запрос на получение размера.
запрос:
HEAD / HTTP/1.1
Host: 192.168.100.200
Accept-Encoding: gzip
Connection: close
ответ:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"1887-1314245401000"
Last-Modified: Thu, 25 Aug 2011 04:10:01 GMT
Content-Type: text/html
Content-Length: 1887
Date: Thu, 25 Aug 2011 04:18:05 GMT
Connection: close
Вердикт: 1887 байт для милого маленького "Это работает!" страница. Это говорит нам о диапазоне, который мы можем использовать, при этом Tomcat не выбрасывает диапазон как выходящий за пределы.
Хорошо, давайте проверим, допускает ли это быстрое перекрытие, байты с 0 по 10, затем с 5 по 15:
запрос:
GET / HTTP/1.1
Host: 192.168.100.200
Range: bytes=0-10,5-15
Accept-Encoding: gzip
Connection: close
ответ:
HTTP/1.1 206 Partial Content
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"1887-1314245401000"
Last-Modified: Thu, 25 Aug 2011 04:10:01 GMT
Content-Type: multipart/byteranges; boundary=CATALINA_MIME_BOUNDARY
Content-Length: 224
Date: Thu, 25 Aug 2011 04:17:11 GMT
Connection: close
--CATALINA_MIME_BOUNDARY
Content-Type: text/html
Content-Range: bytes 0-10/1887
<?xml versi
--CATALINA_MIME_BOUNDARY
Content-Type: text/html
Content-Range: bytes 5-15/1887
version="1
--CATALINA_MIME_BOUNDARY--
Ага, конечно - <?xml versi и version="1. Так работает перекрытие.
И позволит ли он запросить больше данных, чем есть на самом деле в обслуживаемом файле:
запрос:
GET / HTTP/1.1
Host: 192.168.100.200
Range: bytes=0-1800,1-1886
Accept-Encoding: gzip
Connection: close
ответ:
HTTP/1.1 206 Partial Content
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"1887-1314245401000"
Last-Modified: Thu, 25 Aug 2011 04:10:01 GMT
Content-Type: multipart/byteranges; boundary=CATALINA_MIME_BOUNDARY
Content-Length: 3893
Date: Thu, 25 Aug 2011 04:19:51 GMT
Connection: close
--CATALINA_MIME_BOUNDARY
Content-Type: text/html
Content-Range: bytes 0-1800/1887
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Apache Tomcat</title>
</head>
...(lots more data)...
Ага - почти 4 КБ из файла размером менее 2 КБ.
Расширьте этот подход, включив в него огромное количество диапазонов, и это основная структура атаки. В случае Tomcat реальное влияние, по-видимому, заключается в том, что он позволяет злоумышленнику получить большой объем данных, обслуживаемых в ответ на запрос относительно небольшого ресурса, что может оказаться полезным при настройке полосы пропускания для отказа в обслуживании. Я бы также с подозрением отнесся к последствиям в других крайних случаях; с обратным прокси-сервером, пытающимся кэшировать 206 ответов, или когда запрошенный ресурс представляет собой файл, размер которого превышает размер кэша Tomcat.
Это не уязвимость. прочтите код сервлета по умолчанию. Он загружает ресурс один раз. Он также считывает все смещения диапазона. Затем он перебирает все смещения, обслуживающие базы контента на исходном ресурсе. Что ОТЛИЧАЕТСЯ от того, как это сделал apache httpd. Таким образом, это не вызовет исключение OOM.
Вы можете возразить, что можете отправить БОЛЬШУЮ СУММУ заголовков диапазона, чтобы составить исчерпывающий список, или диапазоны, которые нужно вернуть. Но это конкретный пример атаки DOS по отправке слишком большого количества заголовков. В этом случае tomcat и httpd могут ограничить слишком много заголовков запросов, а также их размер.
- обновление 4 октября 2011 г. -
Tomcat может быть открыт для атаки, когда соединение может оставаться открытым дольше обычного. Но этот тип атаки ничем не отличается от вашей стандартной атаки DOS. Это просто позволяет злоумышленнику быть «более эффективным», заставляя запрос обслуживать больше байтов, чем обычно.
Единственные дополнительные ресурсы, потребляемые такой атакой, - это пропускная способность и открытые сокетные соединения. Так что это ничем не отличается от стандартной атаки DOS. Единственная разница в том, что злоумышленник может быть немного эффективнее. Но вы не получили дополнительной защиты, заставив Tomcat выполнить дополнительные проверки диапазона.
tl; dr: Наверное, нет.
Учитывая, что Apache httpd и Tomcat - разные продукты, и я не могу найти упоминания об аналогичном объявлении об уязвимости в Tomcat, я бы предпочел «нет». В объявлении нет подробностей относительно того, в чем именно заключается ошибка, поэтому трудно сказать, вероятно ли, что это может быть обычная ошибка программирования или что-то действительно специфичное для Apache httpd.