Nova versão do Node.js corrige uma vulnerabilidade crítica de segurança HTTP
6 de fevereiro de 2020
0 minutos de leituraUma nova versão de segurança do Node.js foi lançada hoje, 6 de fevereiro de 2020, corrigindo um problema de severidade crítica e dois de severidade alta. Esta versão também inclui uma análise HTTP mais rigorosa. De acordo com as notas oficiais da versão incluídas no seguinte commit do Node.js:
Além disso, a análise HTTP está mais rigorosa para aumentar a segurança. Como isso pode causar problemas de interoperabilidade com algumas implementações HTTP não conformes, é possível desativar as verificações rigorosas com a flag de linha de comando
--insecure-http-parserou com a opção http insecureHTTPParser. Evite usar o analisador HTTP inseguro.
Em resumo
Todas as versões com suporte ativo do Node.js — 10.x, 12.x e 13.x — estão vulneráveis. Recomendamos enfaticamente que você atualize o quanto antes para as seguintes versões corrigidas: 10.19.0, 12.15.0 e 13.8.0
2020-02-06, versão 10.19.0, Dubnium (LTS)
2020-02-06, versão 12.15.0, Erbium (LTS)
2020-02-06, versão 13.8.0, atual
Fui afetado?
As versões 10.x, 12.x e 13.x do Node.js que usam HTTP e TLS, direta ou indiretamente — como projetos baseados no framework para aplicações web Express — são afetadas.
Você também está afetado se estiver usando versões do Node.js sem suporte, como 11.x, 9.x e <= 8.x.
As seguintes vulnerabilidades do Node.js foram identificadas, junto com seus respectivos CVEs:
CVE-2019-15606: espaços OWS no final dos valores dos cabeçalhos HTTP não são removidos.
CVE-2019-15605: contrabando de requisições HTTP usando um cabeçalho Transfer-Encoding malformado.
CVE-2019-15604: disparo remoto de uma asserção em um servidor TLS com uma string de certificado malformada.
Sobre a vulnerabilidade nos cabeçalhos HTTP do Node.js CVE-2019-15606
A vulnerabilidade está relacionada a valores de cabeçalhos HTTP que não têm os espaços OWS finais removidos, conforme descrito nos comentários deste commit no GitHub:
Os valores dos cabeçalhos HTTP podem ter espaços OWS no final, mas eles devem ser removidos. Esses espaços não fazem parte semântica do valor do cabeçalho e, se forem tratados como parte dele, podem causar uma falsa desigualdade entre os valores esperados e os reais.
Vale lembrar que é comum haver um SPC no início do valor do campo, e o analisador HTTP já trata isso removendo todos os espaços OWS iniciais. É somente o OWS final que precisa ser removido pelo usuário do analisador.
“Como essa vulnerabilidade foi corrigida?
Commits relevantes: 25b6897e8a http: remove OWS final dos valores dos cabeçalhos.
Relacionado: RFC 7230 Seção 3.2 e Seção 3.2.3
As referências ainda não públicas são a solicitação de pull original no GitHub e o relatório do HackerOne
Sobre a vulnerabilidade de contrabando de requisições HTTP do Node.js CVE-2019-15605
Foi descoberta uma vulnerabilidade no Node.js que permite ataques de contrabando de requisições HTTP usando um cabeçalho Transfer-Encoding malformado. O trecho de requisição HTTP a seguir mostra um exemplo de como isso poderia ocorrer e agora é usado para testar essa regressão:
Como essa vulnerabilidade foi corrigida?
Commits relevantes: eea3a7429b test: não é possível usar TE para contrabandear requisições e 8f41e837bb deps: atualiza llhttp para 2.0.4
As referências ainda não públicas são a solicitação de pull original no GitHub e o relatório do HackerOne
Sobre a vulnerabilidade do Node.js identificada como CVE-2019-15604
Foi identificada no Node.js uma vulnerabilidade relacionada ao TLS que poderia disparar remotamente uma asserção em um servidor TLS ao receber uma string de certificado malformada, conforme detalhado na mensagem do commit original:
X509V3_EXT_print pode retornar um valor diferente de 1 se a extensão X509 não for compatível com a impressão em um buffer. Em vez de falhar com uma asserção irrecuperável, substitua o valor correspondente no hashmap por um valor null do JavaScript.
Como essa vulnerabilidade foi corrigida?
Commits relevantes: 1156a9e5f8 crypto: corrige asserção causada por extensão não compatível.
Os detalhes do relatório de segurança estão no relatório do HackerOne
Nós, da Snyk, valorizamos a comunidade de segurança e acreditamos que a divulgação responsável de vulnerabilidades em pacotes de código aberto ajuda a garantir a segurança e a privacidade dos usuários. Se você acredita ter encontrado uma vulnerabilidade em um software de código aberto, entre em contato conosco pelo endereço https://snyk.io/vulnerability-disclosure. Nosso programa de divulgação responsável busca proteger tanto o desenvolvedor quanto o pesquisador que reportou a vulnerabilidade, permitindo que desenvolvedores aproveitem com segurança as descobertas dos pesquisadores.
