Os patches do OpenSSL foram lançados - bug CRITICAL rebaixado para HIGH, mas patch de qualquer maneira!

Vamos começar com as coisas importantes: as correções de bugs do OpenSSL amplamente aguardadas anunciadas na semana passada estão fora.

OpenSSL 1.1.1 vai para versão 1.1.1s, e corrige um bug relacionado à segurança listado, mas esse bug não tem uma classificação de segurança ou um número CVE oficial.

Recomendamos fortemente que você atualize, mas a atualização CRÍTICA que você terá visto na mídia de segurança cibernética não se aplica a esta versão.

OpenSSL 3.0 vai para versão 3.0.7, e corrige não um, mas dois bugs de segurança numerados como CVE que são oficialmente designados com severidade ALTA.

Recomendamos fortemente que você atualize, com o máximo de urgência possível, mas a correção CRÍTICA sobre a qual todos estão falando agora foi rebaixada para ALTA gravidade.

Isso reflete a opinião da equipe OpenSSL:

Pré-anúncios de CVE-2022-3602 descreveu esta questão como CRÍTICA. Análises posteriores com base em alguns dos fatores atenuantes descritos [nas notas de lançamento] levaram este valor a ser rebaixado para ALTO. Os usuários ainda são incentivados a atualizar para uma nova versão o mais rápido possível.

Ironicamente, um segundo e semelhante bug, apelidado CVE-2022-3786, foi descoberto enquanto a correção para CVE-2022-3602 estava sendo preparada.

O bug original permite apenas que um invasor corrompa quatro bytes na pilha, o que limita a exploração do buraco, enquanto o segundo bug permite uma quantidade ilimitada de estouro de pilha, mas aparentemente apenas do caractere “ponto” (ASCII 46 ou 0x2E ) repetidas vezes.

Ambas as vulnerabilidades são expostas durante a verificação do certificado TLS, onde um cliente ou servidor armadilhado “se identifica” com o servidor ou cliente na outra extremidade com um certificado TLS deliberadamente malformado.

Embora esses tipos de estouro de pilha (um de tamanho limitado e outro de valores de dados limitados) pareçam difíceis de explorar para execução de código (especialmente em software de 64 bits, onde quatro bytes são apenas metade de um endereço de memória) …

… eles são quase certos de serem facilmente exploráveis ​​para ataques DoS (denial of service), onde o remetente de um certificado não autorizado pode travar o destinatário desse certificado à vontade.

Felizmente, a maioria das trocas TLS envolve clientes verificando certificados de servidor, e não o contrário.

A maioria dos servidores da Web, por exemplo, não exige que os visitantes se identifiquem com um certificado antes de permitir que leiam o site, portanto, a “direção de falha” de qualquer exploração de trabalho provavelmente será servidores desonestos travando visitantes desafortunados, o que geralmente é considerado muito menos grave do que os servidores travando toda vez que um único visitante desonesto acessa.

No entanto, qualquer técnica pela qual um servidor de e-mail ou web hackeado possa travar gratuitamente um navegador ou aplicativo de e-mail visitante deve ser considerado perigoso, principalmente porque qualquer tentativa do software cliente de tentar novamente a conexão resultará no travamento do aplicativo repetidamente. novamente.

Você, portanto, definitivamente quer corrija contra isso assim que puder.

O que fazer?

Como mencionado acima, você precisa OpenSSL 1.1.1s or OpenSSL 3.0.7 para substituir qualquer versão que você tenha no momento.

OpenSSL 1.1.1s recebe um patch de segurança descrito como correção “uma regressão [um bug antigo que reapareceu] introduzido no OpenSSL 1.1.1r não atualizando os dados do certificado a serem assinados antes de assinar o certificado”, esse bug não tem uma gravidade ou um CVE atribuído a ele…

…mas não deixe que isso o impeça de atualizar o mais rápido possível.

OpenSSL 3.0.7 obtém as duas correções de alta gravidade numeradas em CVE listadas acima e, embora não pareçam tão assustadoras agora quanto no festival de notícias que antecedeu este lançamento, você deve assumir que:

• Muitos invasores descobrirão rapidamente como explorar essas brechas para fins de DoS. Isso pode causar interrupção no fluxo de trabalho, na melhor das hipóteses, e problemas de segurança cibernética, na pior, especialmente se o bug puder ser abusado para desacelerar ou interromper processos automatizados importantes (como atualizações) em seu ecossistema de TI.
• Alguns invasores podem resolver esses bugs para execução remota de código. Isso daria aos criminosos uma boa chance de usar servidores web com armadilhas para subverter o software cliente usado para downloads seguros em seu próprio negócio.
• Se uma prova de conceito (PoC) for encontrada, atrairá grande interesse. Como você deve se lembrar do Log4Shell, assim que os PoCs foram publicados, milhares de autoproclamados “pesquisadores” pularam na onda da varredura-da-internet-e-ataque-como-você-vai sob o pretexto de “ajudar” as pessoas a encontrar problemas em suas redes.

Observe que o OpenSSL 1.0.2 ainda é suportado e atualizado, mas apenas de forma privada, para clientes que pagaram contratos com a equipe do OpenSSL, razão pela qual não temos nenhuma informação para divulgar aqui, além de confirmar que o CVE -bugs numerados no OpenSSL 3.0 não se aplicam à série OpenSSL 1.0.2.

Você pode leia mais, e obtenha o seu Atualizações do OpenSSL, A partir do Site OpenSSL.

Ah, e se os PoCs começarem a aparecer online, por favor, não seja esperto e comece a “experimentar” esses PoCs contra os computadores de outras pessoas com a impressão de que você está “ajudando” com qualquer tipo de “pesquisa”.

---