.
O OpenSSL emitiu hoje uma correção para uma vulnerabilidade crítica que se tornou de alta gravidade sobre a qual os mantenedores do projeto alertaram na semana passada.
Após dias de especulação, profissionais de segurança da informação e caçadores de bugs de poltrona receberam mais um truque do que um deleite em 1º de novembro: dois bugs de segurança marcados com CVE, ambos com gravidade “alta”, para corrigir. Uma falha foi anteriormente classificada como “crítica”, embora agora tenha sido rebaixada, pois exigirá um alto grau de habilidade técnica para explorar, se isso for possível contra um alvo realista.
E agora para ser muito claro: isso não é um slam na equipe OpenSSL. Tecnicamente, o bug inicialmente crítico foi sem dúvida um problema crítico, pois é uma vulnerabilidade de execução remota de código, embora seja um desafio, se não impossível de abuso.
No entanto, não é todo dia que somos avisados de uma falha crítica no OpenSSL – uma importante biblioteca de software normalmente usada por vários aplicativos e servidores para criptografar dados em redes e na Internet – e, portanto, fornecedores de infosec, blogs e influenciadores não puderam deixar de hype nos últimos dias, prometendo feeds ao vivo de dor e miséria quando os detalhes dos buracos forem revelados. E quando esses detalhes foram anunciados hoje, como planejado, tudo parecia um pouco exagerado. Dito isto, os patches devem ser aplicados quando possível.
Como tuitou o guru da infosec, Marcus Hutchins, não valia a pena:
Com base nos detalhes técnicos da vulnerabilidade OpenSSL, teoricamente poderia levar ao RCE, mas na prática seria extremamente improvável ou mesmo impossível. Em uma escala de 1 a 10 valeu a pena o pânico, eu daria menos que zero.
— Marcus Hutchins (@MalwareTechBlog) 1º de novembro de 2022
Ambos os bugs afetam apenas um pequeno subconjunto de implantações do OpenSSL: software usando as versões 3.0.0 (lançadas em setembro passado) a 3.0.6. Aplicativos, servidores e sistemas operacionais que usam essas versões devem atualizar para OpenSSL 3.0.7, que tapa os buracos.
A primeira vulnerabilidade, rastreada como CVE-2022-3602, pode ser explorada por um endereço de e-mail malicioso em um certificado de criptografia para transbordar quatro bytes controlados por invasores na pilha que trava o aplicativo ou servidor — ou potencialmente leva à execução remota de código (RCE ) — mas apenas após a validação do certificado. Isso exigiria que “uma CA assinasse o certificado malicioso ou que o aplicativo continuasse a verificação do certificado, apesar da falha em construir um caminho para um emissor confiável”, de acordo com o OpenSSL aviso de segurança.
Assim, um aplicativo ou servidor malicioso pode enviar um certificado especialmente criado, assinado por uma CA ou de outra forma aceito pelo destinatário, para um servidor ou cliente vulnerável e fazer com que esse alvo falhe ou possivelmente ganhe o controle dele. Ganhar controle envolveria configurar a pilha para usar os bytes sobrescritos para sequestrar o fluxo do programa. Muitas plataformas oferecem proteções de estouro de pilha que reduziriam esse risco de RCE, observou o comunicado do OpenSSL. O software deve ser construído com detecção de estouro de buffer de pilha em vigor. E ainda não há muito software usando o OpenSSL 3 e, portanto, a exploração aqui será limitada.
Enquanto o 25 de outubro pré-anúncio rotulada essa vulnerabilidade como crítica, a equipe do projeto de código aberto finalmente a rebaixou para alta com base no número de etapas que um invasor precisaria executar para obter o RCE.
‘Se as estrelas se alinharem’
“Na verdade, explorar isso será realmente muito difícil, mesmo para escritores de exploração muito competentes, e exigirá um grande número de cenários relativamente improváveis para todos se alinharem para que o escritor de exploração funcione”, notado assistente de segurança Matt ‘Pwn All The Things’ Tait, que compartilhou uma análise da falha aqui.
“Dito isso, se as estrelas se alinharem, o atacante assume a máquina”, acrescentou. “Então não ignore. Remende com certeza. Mas eu também não perderia o sono por causa disso.”
Uma das principais razões pelas quais o bug foi inicialmente rotulado como crítico foi que a equipe do OpenSSL não pode garantir que os sistemas das pessoas tenham as proteções necessárias para impedir o RCE neste caso e, portanto, errou por precaução. “Não temos como saber como cada combinação de plataforma e compilador organizou os buffers na pilha e, portanto, a execução remota de código ainda pode ser possível em algumas plataformas”, disse a equipe de segurança. disse.
De acordo com o projeto política de segurançaum bug pode ser considerado crítico se o RCE for “provável em situações comuns”.
No entanto, durante a semana de pré-notificação, depois de analisar os detalhes técnicos e receber informações de grupos que realizam testes sobre a falha, o RCE não parecia mais provável em situações comuns, disse a equipe de segurança. É por isso que a equipe rebaixou a vulnerabilidade para alta gravidade em 1º de novembro, acrescentaram.
Há uma segunda vulnerabilidade de alta gravidade, CVE-2022-3786, que o OpenSSL corrigiu na versão 3.0.7. Como o primeiro bug, este segue um caminho semelhante para explorar e pode acionar uma saturação de buffer levando a uma falha, mas novamente somente depois que um certificado for assinado ou aceito.
“Um invasor pode criar um endereço de e-mail malicioso em um certificado para estourar um número arbitrário de bytes contendo o ‘.’ caractere (decimal 46) na pilha”, de acordo com o comunicado de segurança. “Esse estouro de buffer pode resultar em uma falha (causando uma negação de serviço).”
Lição aprendida?
Embora nenhuma vulnerabilidade deva inspirar Pânico nível Heartbleeddisse Clair Tills, engenheiro de pesquisa sênior da Tenable, Strong The One há lições a serem aprendidas de “pré-anúncio e roer as unhas desenfreadas” até o lançamento do OpenSSL, que “revelou algumas falhas de alta gravidade que não são fáceis de explorar e afetam apenas um pequeno subconjunto de implementações do OpenSSL”.
“Esta é uma oportunidade para as organizações avaliarem seus processos de resposta e entenderem o que pode ser melhorado”, disse Tills. “Quão difícil foi para eles determinar qual versão do OpenSSL eles implantaram ou se algum software no qual eles confiam era vulnerável? Seus canais de comunicação estavam maduros o suficiente para fornecer informações corretas às pessoas que precisavam delas assim que estivessem disponíveis? ?”
Para responder a essas perguntas, atualize para a versão fixa do OpenSSL, se você estiver usando o OpenSSL 3 – e depois vá tomar uma bebida para comemorar que isso não foi tão ruim quanto todos temíamos. Ah, e claro, devemos mencionar: existem alternativas ao OpenSSL, como o BoringSSL do Google, que não é afetado por isso.
Para mais detalhes, veja as perguntas frequentes. Nenhuma exploração ou código de exploração de trabalho foi observado em estado selvagem. ®
.
