OpenSSL vulnerável a corrupção de memória remota

OpenSSL vulnerável a corrupção de memória remota. O problema foi identificado no OpenSSL versão 3.0.4 e especialistas divergem sob ser apenas um bug ou uma vulnerabilidade!

A versão mais recente da biblioteca OpenSSL foi descoberta como suscetível a uma vulnerabilidade de corrupção de memória remota em sistemas selecionados.

O OpenSSL versão 3.0.4, lançado em 21 de junho de 2022, é suscetível à corrupção de memória remota que pode ser acionada trivialmente por um invasor. BoringSSL, LibreSSL e o branch OpenSSL 1.1.1 não são afetados. Além disso, apenas sistemas x64 com suporte a AVX512 são afetados. O bug foi corrigido no repositório, mas uma nova versão ainda está pendente.

O pesquisador de segurança Guido Vranken, que relatou o bug no final de maio, disse que “pode ​​ser acionado trivialmente por um invasor“. Embora a falha tenha sido corrigida , nenhum patch foi disponibilizado ainda.

OpenSSL é uma biblioteca de criptografia popular que oferece uma implementação de código aberto do protocolo Transport Layer Security ( TLS ). Advanced Vector Extensions ( AVX ) são extensões para a arquitetura do conjunto de instruções x86 para microprocessadores da Intel e AMD.

Segundo Vankren, é um “tanto peculiar que quase ninguém esteja falando sobre isso. Se a exploração do RCE for possível, isso o torna pior que o Heartbleed em uma avaliação de gravidade isolada, embora o raio de explosão potencial seja limitado pelo fato de que muitas pessoas ainda estão usando a árvore 1.1.1 em vez de 3, libssl bifurcou em LibreSSL e BoringSSL, a vulnerabilidade existe há apenas uma semana (o HB existe há anos) e é necessária uma CPU com capacidade para AVX512.

Em 31 de maio de 2022,  pesquisador diz que encontrou o bug e relatei um problema com a exponenciação modular Montgomery em tempo constante no OpenSSL e no BoringSSL (mas não no LibreSSL). Para alguns valores de B, E, Mfor B ^ E % M == 0, algumas funções retornariam Mem vez de 0; o resultado não foi totalmente reduzido.

Verificou-se que existem quatro caminhos de código distintos afetados por isso:

David Benjamin, do Google , analisou o problema extensivamente e descobriu que o bug não constitui um risco de segurança (pelo menos não internamente; chamadores externos podem acabar em estados incorretos, dependendo do que estão tentando calcular). Curiosamente, ele também encontrou um bug aparente no artigo de Shay Gueron no qual o código RSAZ é baseado.

Não acho que isso seja uma vulnerabilidade de segurança”, disse Tomás Mráz, da OpenSSL Foundation, em um tópico do GitHub. “É apenas um bug grave que torna a versão 3.0.4 inutilizável em máquinas com capacidade para AVX-512.” 

Por outro lado, Alex Gaynor apontou: “Não tenho certeza se entendi como isso não é uma vulnerabilidade de segurança. É um estouro de buffer de heap que pode ser acionado por coisas como assinaturas RSA, que podem acontecer facilmente em contextos remotos (por exemplo, um handshake TLS ).

Xi Ruoyao, estudante de pós-graduação da Universidade de Xidian, entrou na conversa, afirmando que, embora “acho que não devemos marcar um bug como ‘vulnerabilidade de segurança’, a menos que tenhamos alguma evidência mostrando que ele pode (ou pelo menos é possível) ser explorado“, é necessário lançar a versão 3.0.5 o mais rápido possível dada a gravidade do problema.

Enquanto se discute a possiblidade do erro ser classificado como uma vulnerabilidade de segurança, o bug foi corrigido e encontra-se no repositório do Github.

Fonte: The Hacker News & Guido Vankren

Veja também:

About mindsecblog 2715 Articles
Blog patrocinado por MindSec Segurança e Tecnologia da Informação Ltda.

Be the first to comment

Deixe sua opinião!