Segurança em contexto: quando uma CVE não é uma CVE?

Na Snyk, temos alguns princípios gerais que orientam nosso pensamento e nossas decisões sobre segurança.

Primeiro, é sempre importante entender de quem estamos nos protegendo, pois isso influencia a maneira como precisamos agir. Por exemplo, se nosso artefato é um servidor web, precisamos protegê-lo contra usuários não confiáveis. Já se é um software de criptografia, precisamos protegê-lo até mesmo contra usuários com acesso físico ao sistema. Em cada um desses casos, distinguimos claramente os limites de risco e onde precisamos concentrar nossa atenção.

Segundo, a configuração faz parte da sua base de código. Se um agente mal-intencionado tiver acesso à sua configuração, isso é, fundamentalmente, o mesmo que ter acesso à sua base de código.

Diante do tsunami de sistemas vulneráveis provocado pela recente vulnerabilidade do Log4j 2.x (Log4Shell), é compreensível que nós, como comunidade, busquemos com cada vez mais atenção outras possíveis vulnerabilidades. No entanto, talvez também devêssemos aproveitar este momento para fazer uma pausa e refletir antes de julgar às pressas cada possível problema de segurança encontrado em nosso código. Uma análise mais ponderada também pode mostrar que nem tudo o que causa problemas de segurança deve necessariamente ser tratado da mesma forma.

Por exemplo, podemos analisar por essa perspectiva a recente atribuição da CVE-2021-4104 ao Log4j 1.x. Para explorá-la, seria necessário ter acesso direto aos arquivos de configuração para manipular as definições. Agora, há discussões semelhantes surgindo em torno do projeto Logback, além de exemplos na comunidade Node.

É importante deixar claro que expor possíveis vulnerabilidades continua sendo algo positivo. Mas, em meio ao pânico da mídia, também cabe exercitar o pensamento crítico e reafirmar os critérios da comunidade sobre aquilo em que devemos nos concentrar. Criar outro tsunami de possíveis vulnerabilidades pode causar mais danos do que benefícios, sobrecarregando ainda mais equipes de segurança já pressionadas e atrapalhando os esforços contínuos do setor para proteger o software de código aberto.

Análise crítica de CVEs

As discussões apontadas nas conversas acima levantam questões muito interessantes.

Por exemplo, se uma vulnerabilidade exige acesso privilegiado a arquivos dentro de um sistema para ser explorada, será que ela é mesmo uma vulnerabilidade? Quase qualquer software moderno de certa complexidade pode ser configurado para operar de forma insegura. Uma analogia seria configurar o sshd para permitir o login com senhas vazias. Devemos considerar isso uma nova vulnerabilidade no sshd?

Um dos métodos usados pela nossa equipe de segurança é considerar a diferença entre comportamento esperado e inesperado. Se um software pode ser configurado para executar código remotamente e esse recurso está bem documentado, será que esse comportamento cria uma fraqueza explorável? Pode-se argumentar que esse é um comportamento esperado e que, propriamente falando, não se trata de uma vulnerabilidade de segurança.

Devemos projetar softwares sem modos configuráveis que sejam inseguros? Esse pode parecer um objetivo louvável, mas entra um pouco em conflito com a forma como projetamos software de código aberto nos últimos 30 anos ou mais. Em geral, os objetivos de design desse tipo de software têm sido oferecer o máximo de configurabilidade para atender a todos os casos de uso. Nos últimos anos, padrões de segurança sensatos passaram a ser um objetivo secundário, mas o princípio sempre foi dar ao usuário opções para configurar o software como preferir, com segurança ou não.

Hoje, também vivemos em um mundo em que é fácil para pessoas e empresas registrar CVEs, e elas têm valor por conferirem credibilidade e prestígio. Essa combinação singular pode levar a atribuições questionáveis. Por outro lado, facilitar ao máximo a comunicação de possíveis problemas de segurança só pode ser algo positivo — e, assim, nos deparamos com certo paradoxo.

Como setor, estamos cada vez melhores em identificar vulnerabilidades, ao mesmo tempo que criamos muito mais software. Por isso, é fácil perceber o risco de sobrecarga.

Identificar corretamente vulnerabilidades em softwares, avaliá-las e oferecer formas de mitigação consome muitos recursos e é um processo predominantemente manual, sobretudo nos casos complexos. Embora as abordagens de ML estejam se tornando mais úteis e a IA talvez se mostre ainda mais valiosa, em muitos casos (ironicamente) os computadores não ajudam muito no diagnóstico.

Nota do editor (19 de dezembro de 2021): Desde a publicação, o projeto Logback atribuiu a CVE-2021-42550 ao problema mencionado acima. Com base nos argumentos apresentados nesta publicação, a Snyk não vai adicionar um comunicado sobre esse problema neste momento. Vamos continuar conversando com a comunidade do Logback e esperamos que seja possível chegar a um consenso por meio de uma discussão aberta.

O que vem pela frente

Os pontos de discussão apresentados aqui não pretendem alterar nenhuma CVE específica, mas abrir uma conversa sobre o futuro da avaliação de vulnerabilidades e sobre o que consideramos inseguro agora e no futuro. Desenvolver software de código aberto poderoso e versátil, adequado a casos de uso gerais, inevitavelmente significa oferecer modos configuráveis com diferentes níveis de segurança. Se quisermos continuar fazendo isso, os usuários também têm a responsabilidade de conhecer os riscos de uso. Talvez a solução esteja tanto em melhorar a documentação e a educação quanto em classificar possíveis vulnerabilidades em cenários normais de uso.

Queremos muito saber o que a comunidade pensa. Fale com a gente nas redes sociais (@snyksec) e vamos conversar.