Dia zero do Chrome: “Esta exploração está à solta”, então verifique sua versão agora

Dia zero do Chrome: “Esta exploração está à solta”, então verifique sua versão agora

Nó Fonte: 2704382

A atualização mais recente do Google Chrome foi lançada e, desta vez, a empresa não mediu suas palavras sobre um dos dois patches de segurança que inclui:

O Google está ciente de que uma exploração para CVE-2023-3079 existe na natureza.

Não há palavreado de dois graus de separação, como vimos frequentemente no Google antes, para dizer que a empresa “está ciente dos relatórios” de uma exploração.

Desta vez, é “estamos cientes de tudo por nós mesmos”, o que se traduz de forma ainda mais direta em “sabemos que bandidos estão abusando disso enquanto falamos”, já que o relatório do bug veio diretamente do Grupo de Pesquisa de Ameaças do Google.

Como de costume, isso implica que o Google estava investigando um ataque ativo (seja contra o próprio Google ou contra alguma organização externa, não sabemos) no qual o Chrome foi atacado por uma falha de segurança anteriormente desconhecida.

O bug é descrito simplesmente como: Digite Confusão na V8. (Compreensivelmente, o Google não está dizendo mais do que isso neste estágio.)

Como explicamos antes, um confusão de tipos O bug acontece quando você fornece a um programa um bloco de dados que ele deve analisar, validar, processar e agir de uma maneira…

…mas depois você consegue enganar o programa para interpretar os dados de uma maneira diferente, não autorizada, não validada e potencialmente perigosa.

Perigos de confusão de tipos explicados

Imagine que você está escrevendo um programa em C. (Não importa se você conhece C ou não, você pode acompanhar de qualquer maneira).

Em C, você costuma declarar variáveis ​​individualmente, não apenas reservando memória onde elas podem ser armazenadas, mas também sinalizando ao programa como essas variáveis ​​devem ser usadas.

Por exemplo:

 longo longo int JulianDayNumber; char assinado* NomeCliente;

A primeira declaração de variável reserva 64 bits para armazenar um valor inteiro antigo simples que representa o número do dia astronômico. (Caso você esteja se perguntando, esta tarde é JDN 23157 – os dias julianos começam ao meio-dia, não à meia-noite, porque os astrônomos costumam trabalhar à noite, sendo a meia-noite o meio do dia de trabalho.)

A segunda reserva 64 bits para armazenar um endereço de memória onde pode ser encontrada a string de texto do nome de um cliente.

Como você pode imaginar, é melhor não misturar esses dois valores, porque um número que faz sentido e é seguro usar como número do dia, como 23157, quase certamente não seria seguro para usar como endereço de memória.

Como você pode ver neste despejo de memória de um programa do Windows em execução, o endereço de memória mais baixo alocado para uso começa em 0x00370000, que é 3,604,480 em decimal, muito maior do que qualquer número de dia sensato.

Os endereços de memória reais usados ​​pelo Windows variam aleatoriamente ao longo do tempo, para tornar o layout da memória mais difícil para os criminosos adivinharem; portanto, se você executar o mesmo programa, obterá valores, mas eles serão semelhantes:

E (embora esteja na parte inferior da imagem acima) os endereços de memória da seção de dados do usuário em tempo de execução quando este programa foi executado de 0x01130000 para 0x01134FFF, representando o improvável intervalo de datas de 22 de julho de 44631 a 16 de agosto de 44687.

De fato, se você tentar misturar essas duas variáveis, o compilador deve tentar avisá-lo, por exemplo, assim:

 JulianDayNumber = ClienteNome; NomeDoCliente = JulianDayNumber; aviso: a atribuição cria um inteiro a partir do ponteiro sem uma conversão aviso: a atribuição cria um ponteiro a partir de um inteiro sem uma conversão

Agora, se você já programou em C, saberá que, por conveniência, pode declarar variáveis ​​com várias interpretações diferentes usando o método union palavra-chave, assim:

 união { longo longo int JulianDayNumer; char assinado* NomeCliente; } dados;

Agora você pode referenciar exatamente a mesma variável na memória de duas maneiras diferentes.

Se você escrever data.JulianDayNumber, você interpreta magicamente os dados armazenados como um número inteiro, mas escrevendo data.CustomerName informa ao compilador que você está referenciando um endereço de memória, mesmo que esteja acessando os mesmos dados armazenados.

O que você está fazendo, mais ou menos, é admitir para o compilador que algumas vezes você estará tratando os dados que você tem como uma data, e outras vezes como um endereço de memória, e que você está assumindo a responsabilidade de lembrar qual interpretação se aplica em que momento no código.

Você pode decidir ter uma segunda variável, conhecida como tag (normalmente um número inteiro) para acompanhar o seu union para acompanhar com que tipo de dados você está trabalhando agora, por exemplo:

 struct { tag int; união { longo longo int JulianDayNumer; assinado char* NomeCliente; } dados; } valor;

Você pode decidir que quando value.tag está definido para 0, os dados ainda não foram inicializados para uso, 1 significa que você está armazenando uma data, 2 significa que é um endereço de memória e qualquer outra coisa indica um erro.

Bem, é melhor você não deixar ninguém mexer com isso value.tag configuração, ou seu programa pode acabar se comportando mal drasticamente.

Um exemplo mais preocupante pode ser algo assim:

 struct { tag int; // 1 = hash, 2 = ponteiros de função union { unsigned char hash[16]; // armazena um hash aleatório struct { void* openfunc; // ou dois void* closefunc cuidadosamente validados; // ponteiros de código para executar mais tarde } validar; } } valor;

Agora, estamos sobrecarregando o mesmo bloco de memória para que às vezes possamos usá-lo para armazenar um hash de 16 bytes e, às vezes, para armazenar dois ponteiros de 8 bytes para funções que nosso programa chamará posteriormente.

Claramente, quando value.tag == 1, ficaríamos felizes em permitir que nosso software armazenasse qualquer string de 16 bytes na memória alocada para a união, porque os hashes são pseudoaleatórios, portanto, qualquer coleção de bytes é igualmente provável.

Mas quando value.tag == 2, nosso código precisaria ser extremamente cuidadoso para não permitir que o usuário forneça endereços de função desconhecidos, não validados e não confiáveis ​​para execução posterior.

Agora imagine que você poderia enviar um valor para este código enquanto a tag estava definida como 1, para que não fosse verificada e validada…

…mas depois, pouco antes de o programa realmente usar o valor armazenado, você conseguiu enganar o código para mudar a tag para 2.

O código então aceitaria seus endereços de função não validados como “conhecidos e já verificados como seguros” (mesmo que não fossem) e despacharia com confiança a execução do programa para um local não autorizado na memória que você escolheu sorrateiramente com antecedência.

E é isso que acontece em um bug de confusão de tipo, embora usando um exemplo artificial e simplificado,

A memória que seria segura para consumir se fosse manipulada de uma maneira é entregue de forma maliciosa ao programa para ser processada de uma maneira alternativa e insegura.

O que fazer?

Verifique se você tem a versão mais recente do Chrome ou do Chromium.

Você quer Chrome 114.0.5735.106 ou posterior no Mac e Linux, e 114.0.5735.110 ou posterior no Windows.

O Microsoft Edge, baseado no Chromium, também é afetado por esse bug.

A Microsoft tem até agora [2023-06-06T16:25:00Z] notado que

A Microsoft está ciente das explorações recentes existentes na natureza. Estamos trabalhando ativamente no lançamento de um patch de segurança.

O Edge está atualmente na versão 114.0.1823.37, então qualquer coisa numerada depois disso deve incluir os patches CVE-2023-3079 da Microsoft.

Para verificar sua versão e forçar uma atualização se houver alguma que você ainda não recebeu:

  • Google Chrome Menu de três pontos (⋮) > Ajuda > Sobre o Chrome.
  • Microsoft borda. Configurações e mais (…) > Ajuda e feedback > Sobre o Microsoft Edge.

Seja bem-vindo.


Carimbo de hora:

Mais de Segurança nua