Divulgação de vulnerabilidades: o que vem primeiro, a falha de segurança no PHP ou o CVE?

Para pesquisadores de segurança, há uma série de obstáculos a superar antes que uma possível vulnerabilidade seja amplamente reconhecida. O primeiro é convencer os responsáveis pelo projeto de que há um problema, mesmo apresentando um exemplo funcional.

Às vezes, a linha entre identificar um caminho vulnerável e classificá-lo como bug ou vulnerabilidade de segurança é tênue e imprecisa. O contrário também pode acontecer: uma vulnerabilidade notificada pode ser reclassificada como bug, mesmo tendo sido usada como vetor de ataque.

Um bom exemplo é a divulgação da vulnerabilidade que DeveloperSteve acompanhou na linguagem PHP, relacionada a um tipo de vulnerabilidade Use After Free identificado na função `concat()`. O problema foi demonstrado em um evento de capture the flag. A equipe notificou o problema de segurança, mas, vários posts depois, o relato foi reclassificado como bug, apesar de a vulnerabilidade ter sido explorada.

Recentemente, passei pelo processo de CVE relacionado ao incidente da biblioteca dompdf, o que só aumentou a duração do incidente, que já se estendia por 7 meses. Isso reforçou ainda mais minha admiração pelo trabalho envolvido em lidar com as nuances da publicação de um CVE.

É importante lembrar que muitos projetos de código aberto como este são mantidos e recebem contribuições de pessoas apaixonadas pelo que fazem. Muitas delas também trabalham em tempo integral e enfrentam as mesmas pressões do dia a dia que todos nós, enquanto gerenciam projetos de grande escala como este.

Vamos conferir a linha do tempo do incidente.

Entenda a linha do tempo da notificação do incidente da dompdf

Na divulgação pública feita pela Positive Security em março de 2022, a equipe também publicou a linha do tempo que levou à divulgação.

O relato inicial aos responsáveis pelo projeto foi feito em outubro de 2021, por meio do processo da página de notificação de problemas de segurança do projeto. Depois de meses sem resposta, a equipe da Positive Security tentou chamar atenção para o caso registrando um bug no repositório.

Isso acabou levando ao lançamento de uma versão corrigida depois da divulgação pública da vulnerabilidade. Nesse incidente, DeveloperSteve também conseguiu explorar o caminho vulnerável para criar as condições necessárias à abertura de um shell reverso. 

Isso é demonstrado no aplicativo Snyk-Labs PHP-Goof da própria Snyk, que contém a vulnerabilidade original, à qual DeveloperSteve acrescentou vulnerabilidades de segurança relacionadas ao PHP.

Com base em todas as pesquisas anteriores e nos exemplos de código de prova de conceito do shell reverso, DeveloperSteve conseguiu obter um CVE para o incidente 7 meses após o relato inicial. 

Entenda o processo de CVE 

Depois de passar recentemente pelo processo de CVE, entendemos melhor e valorizamos ainda mais o trabalho dos pesquisadores de segurança na notificação de vulnerabilidades. 

DeveloperSteve enviou uma solicitação de CVE à Mitre, incluindo toda a pesquisa original. O pedido aguarda uma análise mais aprofundada. Essa vulnerabilidade também foi adicionada como exemplo no aplicativo de demonstração PHP-Goof.

Em um exemplo recente, um pesquisador notificou em janeiro uma vulnerabilidade do tipo Use After Free. Ela foi listada nas páginas de vulnerabilidades da Snyk e identificada como CVE-2021-21708.

Como solicitar um CVE

A princípio, o processo parecia bem simples: preencher um formulário online e esperar que alguém validasse as descobertas. Ao acessar a página de notificação/solicitação do CVE.org, DeveloperSteve descobriu que há algumas etapas antes de enviar a solicitação. 

A primeira etapa é identificar a organização parceira do CVE autorizada a reservar e publicar CVEs relacionados à vulnerabilidade notificada. Essas organizações são chamadas de Autoridades de Numeração CVE, ou CNAs. 

Uma organização reconhecida como CNA pode fazer a triagem de vulnerabilidades de segurança e, em seguida, reservar e publicar identificadores CVE para vulnerabilidades notificadas.

Por exemplo, em 2021, a Snyk assumiu a responsabilidade pelo programa de divulgação de vulnerabilidades do ecossistema Node.js. Por isso, a Snyk é uma CNA e publica regularmente relatórios de segurança de CVEs para diversos ecossistemas, como o npm.

Observação: a Snyk tem um formulário simples para notificação de vulnerabilidades de segurança.

Conclusões sobre a notificação de CVEs

Às vezes, a linha entre um caminho vulnerável notificado ser classificado como bug ou como vulnerabilidade é imprecisa. Além disso, há casos em que um bug notificado cria um caminho vulnerável e representa, de fato, uma ameaça à segurança. 

Além da descoberta inicial de uma falha ou problema de segurança pela comunidade, por um pesquisador de segurança ou por um contribuidor, há uma fase de investigação, na qual o problema notificado é analisado com mais profundidade. Muitas vezes, um agente malicioso usa bugs como vetor de ataque para inserir comportamentos indesejados em um aplicativo e/ou na infraestrutura. 

Na Snyk, a equipe de segurança se dedica a identificar vulnerabilidades de segurança desde os primeiros relatos de bugs, antes mesmo de serem registrados oficialmente como CVEs. Esse compromisso ajuda a manter nossos usuários protegidos e informados o quanto antes.