A Grande Enxurrada de CVEs do Kernel de 2024

Vá direto para um resumo gerado por IA desta postagem do blog

“Estamos apenas fazendo o que o cve.org quer que façamos” foi repetido várias vezes por Greg K-H em uma apresentação recente. No início deste ano, o novo status da equipe do Kernel como CNA (Autoridade de Numeração CVE) surpreendeu muitos no setor de segurança. Não só a postura anterior era totalmente contrária ao sistema CVE — “Queimem tudo!” era uma solução proposta —, mas eles também usavam uma abordagem diferente para rastrear vulnerabilidades (IDs de commit) e, para começar, nem as divulgavam publicamente como falhas de segurança.

A mudança na CNA causou um efeito cascata em todo o setor, por motivos que estão se tornando cada vez mais evidentes: não só há mais CVEs, como o grande número deles torna muito mais difícil rastrear, analisar e identificar os mais importantes.

Mas tudo isso já foi discutido anteriormente por nós (e por muitos outros no setor). Existe até um relatório que divulgamos há alguns meses, caso você tenha interesse.

O que é interessante é o ponto de vista da própria equipe do Kernel sobre essa questão e, neste artigo, vamos analisar detalhadamente a apresentação mais recente e identificar o problema que foi ignorado durante essa apresentação.

Todo o texto citado a seguir foi extraído da apresentação “Os CVEs estão ativos, mas não entrem em pânico!” de Greg K-H, mantendo o máximo possível do contexto.

O elefante na sala

Vamos começar com alguns números. Eles são apresentados explicitamente na apresentação. Atualmente (em outubro de 2024), o Kernel CNA está emitindo, em média, 55 novos CVEs por semana. Esse número é ligeiramente inferior aos 60 por semana registrados nos primeiros meses de atividade do CNA. No entanto, nos anos anteriores, havia, de acordo com a apresentação, cerca de 20 CVEs por trimestre.

A política inicial proposta pelo Kernel CNA foi interpretada como uma abordagem do tipo “todo bug recebe um CVE”. Isso agora foi ampliado, de modo que apenas cerca de 20% dos bugs realmente recebem um — o que nos dá 55 por semana. “Isso é muito.” Acompanhando a lista de discussão do Kernel do Linux, isso parece correto.

O processo funciona da seguinte forma: para cada commit estável, há (pelo menos) três pessoas que o analisam e decidem se ele merece um CVE ou não. Isso é discutido publicamente quando não há consenso. Se for alcançado tal consenso, um CVE é atribuído.

Quando um CVE é atribuído a um bug específico, ele ainda pode ser revogado posteriormente, caso sejam apresentados argumentos convincentes. Isso representa de 1% a 2% dos CVEs atribuídos.

O Kernel CNA “não é o número 1”

…exceto que é mesmo. Devido aos números (muito elevados) envolvidos e, obviamente, para responder às críticas, a apresentação inclui uma lista de outros projetos e o número de CVEs semanais que eles geram. O WordPress, com 112 por semana, está no topo — com a ressalva de que não se trata realmente do WordPress, já que inclui todos os plugins e temas; portanto, na verdade, não são 112 por semana. O MITRE aparece com 95 por semana, mas também não se trata de um único projeto. O Windows (11-12), o Chrome (6), o macOS (6) e o iOS (2-3) também estão na lista. A diferença entre código aberto e código fechado significa que a precisão desses números não pode ser verificada de forma independente, mas o fato de o kernel acumular mais CVEs do que qualquer outro projeto individual existente e mais do que todos os sistemas operacionais concorrentes juntos pode dizer mais sobre possíveis problemas com o processo do que com o próprio kernel.

Então, por que isso aconteceu?

O motivo declarado para se começar a emitir CVEs foi duplo: em primeiro lugar, o site cve.org passou a permitir que projetos de código aberto tivessem seu próprio CNA e, em segundo lugar, existem leis e regulamentações em vigor que exigem a divulgação de vulnerabilidades em diferentes jurisdições (com mais a seguir).

“Somos obrigados a fazer isso” [referindo-se à emissão de CVEs], então não é como se o gênio da lenda pudesse ser colocado de volta na garrafa.

O que constitui uma vulnerabilidade?

Uma das principais diferenças entre o Kernel CNA e os CNAs de outros projetos é, como mencionado, o grande número de CVEs emitidos. Isso se resume à interpretação da definição de CVE pelo site cve.org. De acordo com a interpretação da equipe do Kernel, os seguintes bugs exigem a criação de um novo CVE (citação da apresentação):

”Qualquer falha ou reinicialização provocada pelo usuário
Uso de memória após liberação / vazamento / estouro
Verificações incorretas de limites
Negação de serviço
Erros lógicos
“Muitas outras coisas”

Os itens a seguir NÃO são considerados vulnerabilidades e não receberão CVEs:

”Corrupção/perda de dados
Problemas de desempenho
Correções de bugs que não são acionadas externamente
“Não há CVEs de hardware”

Especificamente, o primeiro ponto da segunda lista, a corrupção de dados, merece uma explicação mais detalhada durante a apresentação e, francamente, não considerar possíveis bugs que causam perda de dados como problemas de segurança ignora os possíveis ataques de negação de serviço associados a isso (como foi corretamente apontado por um membro da plateia durante a sessão de perguntas e respostas). O motivo? “Estamos seguindo as diretrizes do cve.org. O problema é deles, não nosso.” Não é uma postura muito útil.

“Boa sorte pra descobrir isso”.

O grande problema das distribuições corporativas

Representantes de diferentes fornecedores de distribuição participaram da apresentação e, durante a sessão de perguntas e respostas, deixaram bem clara sua opinião sobre o assunto — para dizer o mínimo, eles não ficaram nada satisfeitos com isso.

O raciocínio aqui é que, se você está utilizando o kernel e integrando-o ao seu ambiente, então você (deveria) ter um bom entendimento do que está usando; assim, seria menos trabalhoso identificar os CVEs que são realmente relevantes para o seu ambiente específico — você não precisa se preocupar com código que nunca é usado ou carregado —, de modo que uma parte considerável das 55 vulnerabilidades por semana não tem real importância em cada caso específico.

No entanto, os fornecedores de distribuições estão em uma posição mais próxima da equipe do kernel do que dos usuários finais. Uma distribuição pode ser utilizada de infinitas maneiras e em diversas situações e, assim como a equipe do kernel, o fornecedor não pode pretender saber quais partes do kernel serão relevantes ou não. Consequentemente, eles precisam corrigir todas as vulnerabilidades que surgem. Isso se reflete nas empresas que desenvolvem produtos com base nas versões lançadas pelos fornecedores de distribuições.

Portanto, cada uma dessas 55 CVEs por semana precisa ser analisada, classificada, corrigida, testada e disponibilizada aos clientes corporativos. Se você está se perguntando por que os boletins de segurança dos fornecedores agora incluem centenas de CVEs, é porque elas são agrupadas a cada poucas semanas.

Ainda assim, seria simplesmente uma questão de transpor as correções do upstream para o downstream e pronto, certo? Bem, a coisa não é bem assim.

Os CVEs atribuídos pelo Kernel CNA referenciam apenas o commit da correção propriamente dita. Se houver toda uma cadeia de outros patches necessários para que a correção seja aplicada ou funcione corretamente, isso fica a cargo do leitor.

Além disso, eles “não são testados de forma independente, mas apenas como um todo”. Isso se torna inútil assim que uma distribuição aplica qualquer personalização, pois todos os testes precisam então ser repetidos.

“As distribuições Enterprise têm um problema, que é de sua própria culpa, e não tenho nenhuma simpatia por elas” [referindo-se às correções retroportadas para versões mais antigas do kernel que são fornecidas e têm suporte pelos fornecedores das distribuições]. De fato.

“Isso não é problema meu.”

O usuário final/organização

“[É preciso atualizar para a versão mais recente do kernel] e reiniciar o sistema, ou fazer uma triagem de todas as correções, aplicar as relevantes e reiniciar. É possível usar a aplicação de patches em tempo real.” Ao mesmo tempo, ele reconhece que muitos não podem fazer isso, pois sua infraestrutura não suporta o número de reinicializações. Portanto, avalie 55 CVEs por semana, todas as semanas, ou adote a versão mais recente. Essa é uma escolha pirrica na prática, que se torna extremamente onerosa em um ambiente corporativo.

A terceira e, considerando todos os aspectos, única alternativa viável é aplicar correções em tempo real nos seus sistemas.

A Situação Atual

“Estamos fazendo exatamente o que o cve.org nos pediu para fazer” parece ser a postura padrão na defesa do processo atual. Aceitar isso sem questionar, e que “não estamos causando uma negação de serviço” [no processo do CVE], também não é a intenção. Mas a situação real enfrentada por muitas empresas, fornecedores de distribuição e empresas de segurança cibernética, além dos problemas de conformidade e segurança decorrentes de ter sistemas sinalizados por 55 novas vulnerabilidades a cada semana, não ajuda muito a aceitar o estado atual das coisas como algo diferente de uma conformidade maliciosa (intencional ou acidental).

O trabalho extraordinário realizado pela equipe do Kernel, e particularmente pela pequena equipe do Kernel CNA, merecia um tratamento melhor, mas, infelizmente, está causando muita angústia e sofrimento a milhares de profissionais de segurança, cujo ecossistema inteiro está agora inundado por novas vulnerabilidades — muitas vezes sem classificação —, o que apenas aumentou a carga de trabalho em um ambiente já de si estressante.

“Isso está causando alguma agitação e alguns percalços no ecossistema. Sei que vou ser citado por causa disso.” Não me diga.

Observação: Agradeço a Greg K-H pela transparência em relação ao processo e por nos permitir dar uma olhada nos bastidores.

Resumo