A princípio, parecia que o bug de segurança do OpenSSL 3.x seria realmente terrível. Embora se temia que fosse um erro crítico que poderia levar à execução remota de código (RCE), após um exame mais detalhado, acabou não sendo tão horrível assim.
Isso não quer dizer que não seja ruim. Ambos CVE-2022-3786 (“X.509 Endereço de Email Tamanho Variável Buffer Overflow”) e CVE-2022-3602 (“X.509 Email Address 4-byte Buffer Overflow”) têm uma classificação CVE de 8,8, que é considerada “alta”. Isso significa que eles ainda podem causar problemas reais.
Se for, você está usando o OpenSSL 3.0.0 a 3.0.6. Os usuários do OpenSSL 1.1.1 e 1.0.2 não precisam se preocupar. No entanto, só porque seu sistema operacional principal usa OpenSSL 1.x, não pense que você pode ignorar esses problemas. Seus aplicativos ou contêineres podem usar uma versão vulnerável. Resumindo, antes de tirar os sapatos e tirar uma soneca, verifique seu código.
Especificamente, você precisa se preocupar com 3786 sobre uma saturação de buffer que pode ser acionada na verificação do certificado X.509. Aqui, um invasor pode criar um endereço de e-mail malicioso para estourar quatro bytes controlados pelo invasor na pilha. Isso pode causar uma falha no sistema ou RCEs.
Com o 3602, sua preocupação é que um estouro de buffer baseado em pilha foi encontrado na maneira como o OpenSSL processa certificados X.509 com um campo de endereço de e-mail especialmente criado. Novamente, isso pode causar uma falha ou um RCE.
A maneira mais comum em que um deles pode ser acionado é quando um servidor solicita autenticação de cliente após a conexão de um cliente mal-intencionado ou quando um cliente se conecta a um servidor mal-intencionado. Até o momento, não houve ataques bem-sucedidos.
Brian Fox, cofundador e CTO da Sonatypeuma empresa de segurança da cadeia de suprimentos de software, observa: “Embora os bugs de estouro de memória possam levar a cenários de pior caso, os detalhes dessa vulnerabilidade específica parecem indicar que o nível de dificuldade de uma exploração é muito alto. A vulnerabilidade requer um certificado malformado que é confiável ou assinado por uma autoridade de nomenclatura. Isso significa que as autoridades devem ser capazes de impedir rapidamente a criação de certificados projetados para atingir essa vulnerabilidade, limitando ainda mais o escopo.”
Por que isso não foi tão importante quanto temíamos? As vulnerabilidades não são mais consideradas críticas porque muitos sistemas operacionais modernos não são tão vulneráveis às suas falhas de segurança específicas.
Isso ocorre porque uma pilha de memória explorada substitui apenas um buffer adjacente não utilizado em algumas distribuições Linux, como Red Hat Enterprise Linux (RHEL). Além disso, muitas plataformas modernas implementam proteções de estouro de pilha. Seu sistema ainda pode travar, mas não é provável que um invasor consiga realizar um RCE.
Mas, como o OpenSSL adverte, como “OpenSSL é distribuído como código-fonte, 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”.
Além disso, embora o patch OpenSSL seja upstream, isso não significa que sua distribuição tenha o patch pronto para ser usado. Então, você não pode simplesmente atualizar seu Debian Linux software familiar com…
$ sudo apt-get update
$ sudo apt-get upgrade
…e tenha certeza de que estará seguro. Verifique com seu distribuidor Linux se o patch OpenSSL 3.0.7 está pronto para seu sistema. Ou você sempre pode baixar e compilar o patch para o seu sistema.
Por fim, o OpenSSL sempre recomenda usar a versão mais recente (1.1.1s) e lembra que o OpenSSL 1.1.1 é suportado apenas até 11 de setembro de 2023. Os usuários de versões mais antigas do OpenSSL (como 1.0.2) são incentivados a atualizar para o OpenSSL 3.0. Lembre-se, houve nunca uma versão OpenSSL 2. Se alguém tentar fazer você “atualizar” para o OpenSSL 2, eles estão atacando você.
Antes de corrigir e deixar esse problema para trás, Guarda-corrente e Loja de assinaturas O fundador Dan Lorenc gostaria que você lembrasse que, mesmo que tenha se tornado uma vulnerabilidade crítica do OpenSSL, “foi apenas a segunda em boa parte de uma década. Isso reforça que o código-fonte aberto é pelo menos tão seguro quanto código proprietário, de código-fonte fechado. … Em vez de debater os méritos do código-fonte aberto, devemos nos concentrar na construção de software seguro que tenha as ferramentas necessárias para tornar a correção mais rápida e perfeita, enraizando em medidas seguras por padrão.”
Histórias relacionadas:
source – www.zdnet.com
