OpenSSL 3.0.7 corrige falhas de alta severidade em TLS

OpenSSL 3.0.7 foi publicado para corrigir duas vulnerabilidades de alta severidade em verificação de certificados X.509: CVE-2022-3602 e CVE-2022-3786. As falhas afetam OpenSSL 3.0.0 a 3.0.6 e não atingem as séries 1.1.1 e 1.0.2, segundo o advisory do projeto.¹

O episódio chama atenção porque OpenSSL está em uma camada fundamental da internet corporativa. Ele aparece em servidores web, clientes TLS, appliances, bibliotecas, containers, agentes, ferramentas de automação, proxies, SDKs e softwares embarcados. Quando uma falha atinge esse nível da pilha, a dificuldade não é apenas aplicar um patch; é descobrir onde a biblioteca está presente.

A severidade mudou, mas a urgência continua

CVE-2022-3602 foi pré-anunciada como crítica, mas saiu com severidade alta após análise adicional. O projeto explicou que proteções modernas contra stack overflow e detalhes de layout de memória em plataformas comuns reduzem a probabilidade de execução remota de código em situações típicas. Ainda assim, a falha pode causar crash e, em algumas combinações de plataforma e compilador, execução remota não pode ser descartada.²

CVE-2022-3786 também envolve overflow na verificação de certificados, mas com controle diferente sobre os bytes gravados. O projeto não a classificou como crítica desde o início e não espera execução remota de código. Ambas, porém, são sérias e justificam atualização rápida.

O detalhe técnico importante é o ponto de disparo. O problema aparece no processamento de name constraints de endereços de email em certificados X.509, após a verificação da assinatura da cadeia. Em clientes TLS, pode ser acionado ao conectar a um servidor malicioso. Em servidores TLS, o risco aparece quando há autenticação de cliente e um cliente malicioso apresenta certificado preparado.

Inventário vale tanto quanto o patch

Para equipes de segurança, a orientação direta é atualizar OpenSSL 3.0 para 3.0.7. Mas a execução exige disciplina de inventário. Nem todo uso de OpenSSL aparece como pacote do sistema; algumas aplicações carregam bibliotecas em imagens de container, empacotam binários próprios ou dependem de runtime distribuído por fornecedor.

O primeiro passo é separar sistemas que usam OpenSSL 3.0.x daqueles em OpenSSL 1.1.1 ou bibliotecas alternativas. O segundo é priorizar superfícies expostas: clientes que consomem endpoints não confiáveis, servidores com mTLS, gateways, balanceadores, proxies e ferramentas que validam certificados recebidos de terceiros.

Distribuições Linux podem entregar correções por pacote mantendo numeração própria. Por isso, checar apenas a string de versão pode levar a falso positivo ou falso negativo. Em ambientes corporativos, convém cruzar SBOM, gerenciador de pacotes, scanners de container e notas do fornecedor.

A cadeia TLS precisa de resposta coordenada

O projeto informou que não tinha evidência de exploração no momento do advisory, nem conhecimento de exploit funcional para execução de código. Isso reduz ruído, mas não elimina a janela de exposição. A publicação de detalhes técnicos normalmente acelera pesquisa ofensiva e defensiva.

Também é importante evitar ações desnecessárias. O advisory afirma que não é preciso substituir certificados TLS por causa dessas falhas. O foco deve estar em atualizar bibliotecas vulneráveis, reiniciar processos que carregam OpenSSL em memória e validar que os binários em produção realmente usam a versão corrigida.

OpenSSL 3.0.7 mostra como dependências profundas exigem governança contínua. Ter TLS funcionando não basta; é preciso saber qual biblioteca implementa TLS, quem a mantém, como ela entra no build e em quanto tempo a organização consegue trocar uma peça crítica sem quebrar serviços.