BT

Grave vulnerabilidade de negação de serviço atinge maioria dos servidores web

por Jonathan Allen , traduzido por Eder Ignatowicz em 06 Jan 2012 |

Os pesquisadores de segurança Alexander Klink e Julian Wälde revelaram uma séria vulnerabilidade que atualmente afeta a maior parte dos servidores web. O ataque exige apenas uma requisição HTTP, que é projetada especialmente para gerar colisões de códigos hash dos dados POST de formulários.

No momento de descoberta do ataque, ele atingia servidores web em Python, Ruby, PHP, Java e ASP.NET; contudo os fornecedores destes servidores estão trabalhando juntamente com os pesquisadores para a criar atualizações e mitigar a vulnerabilidade. As atualizações 7.0.23 e 6.0.35 do Tomcat tratam esta vulnerabilidade, limitando o número de campos do formulário em um POST a 10 mil. O change log informa que o valor é configurável, porém não foram disponibilizados detalhes sobre esta configuração.

O patch para ASP.NET foi disponibilizado no dia 29 de dezembro e será automaticamente aplicado para os clientes do Windows Azure com uma política padrão de serviços. O patch limita em 1.000 o número de campos no formulário POST de cada request, valor bem abaixo do número necessário para o ataque. Este valor é configurável através da chave do appSettings "aspnet:MaxHttpCollectionKeys".

Atualmente essa configuração somente pode ser aplicada com efeito para todo o servidor, mas já foi solicitada a personalização desta configuração para valores específicos em cada página. Outra correção disponibilizada é referente a falhas na entrada de código JSON e na sua lógica de desserialização.

O PHP 5.4.0, um release candidate, também oferece uma diretiva max_input_vars para limitar o número de campos no formulário. Contudo os release notes não informam o valor padrão desta configuração.

Até o presente momento, todos os fornecedores têm tratado a falha em servidores web através da limitação no número de campos em cada requisição. Outra opção para lidar com o problema é através do uso de um fórmula para geração aleatória de código hash. O Ruby é uma das linguagens que vem adotando esta solução e o .NET também aplica esse método, mas somente para builds locais. Releases de produção atualmente usam uma fórmula padrão, mas dada a gravidade da falha, isto pode ser modificado na próxima atualização do CLR. Para Java, a solução não é tão simples, pois a JVM especifica a fórmula de cálculo de hash para strings, e muitos desenvolvedores podem depender da consistência dessa fórmula padrão nas diferentes versões do Java.

Uma atualização do Oracle Glassfish está supostamente pronta, mas ainda não disponível. Não existe ainda informações sobre a solução utilizada para tratamento da falha nesse servidor.

Mais informações referentes à vulnerabilidade podem ser encontradas nos sites Ars Technica e Chaos Communication Congress.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT