A OpenSSL corrigiu em junho e sem qualquer CVE

Onze bytes e um fio de execução à espera

Alguém da equipa vermelha da Okta enviou 11 bytes a um servidor e viu-o pôr de lado 131 kilobytes. O truque está no modo como se abre uma conversa TLS. Os primeiros quatro bytes de uma mensagem de aperto de mão declaram o comprimento que a mensagem terá, e as versões mais antigas da OpenSSL acreditavam nessa declaração, reservando o espaço antes de o resto chegar ou de correr qualquer validação. O resto da mensagem nunca chegou. A memória ficou reservada e um fio de execução ficou à espera de dados que já não viriam.

Repetido, o efeito deixa de ser subtil. Num servidor de um gigabyte a equipa deixou 547 megabytes congelados em fragmentos inúteis. Numa máquina de dezasseis gigabytes bloquearam um quarto da memória total. Em sistemas que usam o alocador glibc a memória não regressa de forma limpa mesmo depois de o atacante se desligar, porque os fragmentos libertados não podem ser reaproveitados. Não foram precisas credenciais, não se estabeleceu qualquer sessão e nada na troca se parecia com um ataque.

A parte que deve preocupar mais um gestor do que um engenheiro

A OpenSSL corrigiu. As versões 4.0.1, 3.6.3, 3.5.7, 3.4.6 e 3.0.21 saíram todas a 9 de junho de 2026 com o comportamento corrigido, reservando memória apenas à medida que os dados chegam de facto. Três pedidos de integração de alterações, numerados 30792, 30793 e 30794, levaram a modificação. Depois nada se disse sobre o assunto durante mais de cinco semanas. A divulgação pública chegou à lista de correio oss-security a 18 de julho, 39 dias depois de a correção já circular.

A equipa de segurança tomou uma decisão consciente. A OpenSSL mantém um sistema de gravidade de quatro níveis, de Crítico a Baixo, e entendeu que este caso não cabia em nenhum deles. O pedido de integração afirma com clareza que a equipa optou por tratar a comunicação como uma correção de "erro ou reforço". Não existe, por isso, identificador CVE, nem aviso de segurança, nem entrada nos registos de alterações das versões afetadas. Cada uma dessas ausências é uma decisão, e cada uma retirou um sinal que o processo de alguém fora construído para detetar.

O processo disciplinado perdeu para o indisciplinado

Pense em duas empresas. A primeira aplica correções à OpenSSL numa cadência mensal fixa, independentemente do que a versão contenha. É a abordagem de que uma função de segurança madura costuma afastar-se, porque gasta janelas de manutenção em versões sem importância. Essa empresa está protegida desde junho e não faz ideia de que alguma vez esteve em risco.

A segunda estabelece prioridades por gravidade. Lê os avisos, pontua os CVE, antecipa o Crítico e o Elevado e adia o resto com uma justificação documentada. É a abordagem que passa numa auditoria, satisfaz uma seguradora e aguenta uma pergunta do conselho. Essa empresa olhou para a versão de junho da OpenSSL, não encontrou conteúdo de segurança e decidiu, com toda a correção, não gastar nela uma janela de manutenção. Continua exposta, e o seu processo funcionou exatamente como fora desenhado.

A conclusão incómoda é que aplicar correções segundo a gravidade equivale a entregar as decisões de risco a quem atribui essa gravidade. Não é uma censura à OpenSSL, projeto assente em boa medida em voluntários e que toma decisões defensáveis sobre uma escala de quatro níveis que não deve a ninguém. É uma constatação sobre onde reside de facto o critério. Se o seu processo só faz subir de nível aquilo que chega já rotulado como perigoso, então o seu modelo de ameaça é, na verdade, a política de rotulagem dos seus fornecedores.

Duas coisas continuam verdadeiras hoje

O percurso DTLS ficou como estava. Corrigi-lo em condições foi considerado demasiado intrusivo por agora, pelo que esse código continua a dimensionar o seu armazenamento temporário pelo comprimento que a outra parte declara. Se termina DTLS nalgum ponto, e fazem-no muitos concentradores de VPN, servidores de multimédia WebRTC e portas de ligação industriais de IoT, essa exposição não fica resolvida por nada do que aqui se descreve. Também não é um segredo escondido. Está dito abertamente na divulgação, o que por si só é um aviso.

A segunda coisa tem que ver com o tempo. Normalmente a divulgação e a correção chegam juntas e defensores e atacantes partem da mesma linha. Aqui o código corrigido esteve em registos públicos durante 39 dias antes de alguém explicar o que corrigia. Ler uma comparação de registos não é uma competência exótica. Durante mais de um mês, quem lê código levou vantagem sobre quem lê boletins, e o segundo grupo não sabia que tinha começado uma corrida.

A pergunta a juntar à próxima revisão

Não refaça o seu programa de vulnerabilidades por causa de uma falha de esgotamento de memória. Junte, isso sim, uma pergunta recorrente à reunião que já realiza: o que decidimos não corrigir neste trimestre por ter chegado sem classificação de gravidade? Não o que adiámos como Baixo. Aquilo que nunca entrou na fila porque nada o rotulou. Essa lista existe em qualquer organização e quase ninguém a consulta.

Depois compare as suas versões da OpenSSL com as de 9 de junho, o que demora minutos, e registe se está coberto por política ou por sorte. A diferença entre estas duas respostas é o cerne da questão. Um controlo que o protege por acaso não é um controlo, e da próxima vez que o acaso não acontecer há de descobri-lo pela via cara.

Leia a seguir: A correção foi pública 81 dias antes do aviso  |  Um pedido podia sequestrar o seu site WordPress