Apache - Como limitar o comprimento do cabeçalho Content-Type para evitar o CVE-2014-0050?

Question

Na quinta-feira, um problema do DoS com o Tomcat foi anunciado em uma lista de discussão do Tomcat ("[SECURITY] CVE-2014-0050 Apache Commons FileUpload e Apache Tomcat DoS ").

Um invasor parece ser capaz de causar um loop infinito enviando um cabeçalho content-type ao carregar arquivos (se o recurso de upload do Servlet 3.0+ for usado no aplicativo da Web), até onde eu entendi a mensagem primeiro relance.

Se alguém opera seus servidores Tomcat atrás de servidores httpd Apache (usando AJP e mod_jk), o que pode ser feito para implementar a recomendação "Limite o tamanho do cabeçalho Content-Type para menos de 4091 bytes"

É claro que, assim que uma versão de correção de erros estiver disponível (através da página de download ou dos repositórios de pacotes específicos da distribuição Linux), deve-se atualizar. Sem dúvida. Mas no momento, a versão do Tomcat atualmente disponível 7.0.50 parece ainda ser afetada.

Mas o que se pode fazer como uma medida defensiva rápida, até que uma versão fixa esteja disponível?

(sem ter que ...

• desinstalar os pacotes atuais do Tomcat (instalados do repositório de pacotes),
• construa as versões manualmente a partir das origens (SVN),
• implante-os manualmente (sem apt-get ou aptitude ),
• depois, desinstale todas as coisas construídas manualmente novamente em favor de versões confortavelmente atualizáveis do repositório de pacotes

Existem maneiras semelhantes às soluções temporárias para este tópico: link ?

Naquela época, era possível usar mod_headers , mod_setenvif ou mod_rewrite para lidar com o problema. Existem truques semelhantes do Apache para manter as solicitações de upload multipart malformadas longe do servidor Tomcat downstream?

    

Answer 1

apache (incluindo uma versão modificada do Shane; lendo o rfc eu não apostaria o comprimento de Content-String é sempre < 129

RewriteEngine On
RewriteCond %{HTTP:Content-Type} "multipart\/form-data;(\s*)boundary=[a-zA-Z0-9_-]{3000}"
RewriteRule ^/(.*)$ /405.html [R=301,L]

# modified 
SetEnvIf Content-Type ^.{3000,}$ bad-content-type=1
RequestHeader unset Content-Type env=bad-content-type

nginx (não encontrou uma maneira de contornar if ())

server {
  ...
  if ($http_content_type ~* "multipart\/form-data;(\s*)boundary=[a-zA-Z0-9_-]{3000}" ) {
  return 403; 
  }
  ...

}

    

Answer 2

Sim, isso deve funcionar. O CVE anuncia 4091 bytes, mas o e-mail divulgação acidental parece que os desenvolvedores estão se inclinando para 70-128 bytes como limite. Vamos com 128, mas pode ser ajustado conforme necessário:

SetEnvIf Content-Type ^.{129,}$ bad-content-type=1
RequestHeader unset Content-Type env=bad-content-type

Apenas a desativação do cabeçalho (em vez de 403 a solicitação completa) provavelmente está sendo desnecessariamente suave com as aparentes solicitações de ataque, mas isso deve fazer o trabalho.