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.