O Tomcat é vulnerável à vulnerabilidade do Apache DoS no CVE-2011-3192?

5

O Tomcat é afetado por esta vulnerabilidade? Aqui está o comunicado consultivo .

    
por Tom G 25.08.2011 / 03:50

3 respostas

10

Essencialmente, essa vulnerabilidade faz com que o servidor Apache crie uma resposta massiva para uma solicitação de um único arquivo, muito maior do que o próprio arquivo. Enquanto o RFC ( 2616 ) diz aos serviços da web para aceitar vários intervalos, não há nada que diga que você não pode ter o os intervalos se sobrepõem. Implementação ruim por parte do Apache, mas há uma boa chance de que outros servidores da Web sejam vulneráveis.

A maioria dos servlets Tomcat não permite solicitações Range , pois é uma implementação personalizada de um filtro para transmitir os trechos corretos de conteúdo. No entanto, o servlet padrão (que lida com conteúdo estático) é outra história.

Código atual do Tomcat ( aqui ) aceita vários conjuntos de intervalos, valida cada um individualmente que está dentro dos limites do tamanho do arquivo e os coloca em uma lista de intervalos a serem atendidos. No entanto, os intervalos são transmitidos em seqüência a partir do cache interno do servlet, e o processo deve ser interrompido imediatamente se o cliente solicitar a desconexão dos dados; na maioria dos casos, isso deve tornar a solicitação de intervalo sobreposto equivalente ao impacto no desempenho de veicular um arquivo grande.

E, para confirmar, um teste rápido ...

Enviaremos um pedido rápido contra / para obter o tamanho ...

solicitação:

HEAD / HTTP/1.1
Host: 192.168.100.200
Accept-Encoding: gzip
Connection: close

resposta:

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

Veredicto é, 1887 bytes para o bonitinho "Funciona!" página. Isso nos diz o alcance que podemos usar sem o Tomcat jogando fora o alcance como fora dos limites.

Ok, então vamos verificar se permite uma sobreposição rápida, bytes 0 a 10 e depois 5 a 15:

solicitação:

GET / HTTP/1.1
Host: 192.168.100.200
Range: bytes=0-10,5-15
Accept-Encoding: gzip
Connection: close

resposta:

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--

Sim, com certeza - <?xml versi e version="1 . Então, obras sobrepostas.

E se isso permitirá uma solicitação de mais dados do que o que está sendo veiculado no momento:

solicitação:

GET / HTTP/1.1
Host: 192.168.100.200
Range: bytes=0-1800,1-1886
Accept-Encoding: gzip
Connection: close

resposta:

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)...

Yup - quase 4KB servido de um arquivo com menos de 2 KB.

Amplifique essa abordagem para incluir um número enorme de intervalos e essa é a estrutura básica do ataque. No caso do Tomcat, o impacto real parece ser que ele permite que um invasor receba uma grande quantidade de dados atendidos em resposta a uma solicitação de um recurso relativamente pequeno, o que pode ser útil no direcionamento da largura de banda para uma negação de serviço. Eu também suspeitaria dos impactos em outros casos extremos; com um proxy reverso tentando armazenar em cache 206 respostas, ou quando o recurso solicitado é um arquivo maior do que caberia no cache do Tomcat.

    
por 25.08.2011 / 06:31
2

Não é uma vulnerabilidade. leia o código padrão do servlet. Ele carrega o recurso uma vez. Ele também lê todos os deslocamentos de intervalo. Em seguida, itera todos os deslocamentos que atendem às bases de conteúdo do recurso original. Qual é DIFERENTE de como o httpd apache fez isso. Portanto, isso não acionará uma exceção do OOM.

Você poderia argumentar que poderia enviar uma GRANDE QUANTIDADE de cabeçalhos de intervalo para fazer uma lista exaustiva ou intervalos para retornar. Mas esse é um exemplo específico de um ataque do DOS ao enviar muitos cabeçalhos. Nesse caso, tomcat e httpd têm maneiras de limitar muitos cabeçalhos de solicitação, bem como seu tamanho.

- atualização em 4 de outubro de 2011 -
O Tomcat pode estar aberto a um ataque em que uma conexão pode ser mantida aberta por mais tempo do que o normal. Mas esse tipo de ataque não é diferente do seu ataque padrão do DOS. Ele apenas permite que o invasor seja "mais eficiente", fazendo com que uma solicitação atenda a mais bytes do que normalmente seria exibido.

Os únicos recursos extras consumidos por tal ataque são as conexões de largura de banda e de soquete aberto. Portanto, não é diferente de um ataque padrão do DOS. A única diferença é que o atacante pode ser um pouco mais eficiente. Mas você não ganhou nenhuma proteção extra fazendo com que o Tomcat tente realizar validações extras no intervalo.

    
por 15.09.2011 / 17:20
1

tl; dr: Provavelmente não.

Dado que o Apache httpd e o Tomcat são produtos diferentes, e não consigo encontrar menção de um anúncio de vulnerabilidade equivalente no Tomcat, inclino-me a "não". Não há detalhes no anúncio sobre qual é o erro exato, por isso é difícil dizer se é provável que este seja um bug de programação comum, ou algo realmente específico para o Apache httpd.

    
por 25.08.2011 / 03:58