O Chrome corrige 24 falhas de segurança, ativa o sistema de segurança “Sanitizer”

O navegador Chrome mais recente do Google, versão 105, está fora, embora o número da versão completa seja irritantemente diferente dependendo se você estiver no Windows, Mac ou Linux.

Em sistemas do tipo Unix (Mac e Linux), você deseja 105.0.5195.52, mas no Windows, você está procurando 105.0.5195.54.

De acordo com o Google, esta nova versão inclui 24 correções de segurança, embora nenhuma delas seja relatada como “in-the-wild”, o que significa que não houve nenhum dia zero corrigido desta vez.

No entanto, há uma vulnerabilidade apelidada Crítico, e mais oito classificados Alta.

Das falhas que foram corrigidas, pouco mais da metade delas se deve ao mau gerenciamento de memória, com nove listadas como usar depois de livre bugs, e quatro como estouro de buffer de pilha.

Tipos de bugs de memória explicados

A usar depois de livre é exatamente o que diz: você devolve a memória para liberá-la para outra parte do programa, mas continua usando-a de qualquer maneira, potencialmente interferindo no funcionamento correto do seu aplicativo.

Imagine, por exemplo, que a parte do programa que pensa que agora tem acesso exclusivo ao bloco de memória incorreto recebe alguma entrada não confiável e verifica cuidadosamente se os novos dados são seguros para uso…

…mas então, no instante antes de começar a usar essa entrada validada, seu código bugado “use-after-free” interfere e injeta dados obsoletos e inseguros na mesma parte da memória.

De repente, o código livre de bugs em outras partes do programa se comporta como se fosse buggy, graças à falha em seu código que invalidou o que estava na memória.

Os invasores que podem descobrir uma maneira de manipular o tempo da intervenção inesperada do seu código podem não apenas travar o programa à vontade, mas também tomar o controle dele, causando o que é conhecido como execução remota de código.

E um estouro de buffer de pilha refere-se a um bug em que você grava mais dados na memória do que cabem no espaço originalmente alocado para você. (montão é o termo do jargão para a coleção de blocos de memória que estão sendo gerenciados atualmente pelo sistema.)

Se alguma outra parte do programa tiver um bloco de memória por acaso estar próximo ou próximo ao seu no heap, os dados supérfluos que você acabou de escrever não transbordarão inofensivamente para o espaço não utilizado.

Em vez disso, ele corromperá os dados que estão em uso ativo em outro lugar, com consequências semelhantes ao que acabamos de descrever para um bug use-after-free.

O sistema “Sinfetante”

Felizmente, além de corrigir erros que não deveriam estar lá, o Google anunciou a chegada de um novo recurso que adiciona proteção contra uma classe de falhas do navegador conhecidas como scripts entre sites (XSS).

Os bugs XSS são causados ​​pelo navegador inserir dados não confiáveis, digamos de um formulário da Web enviado por um usuário remoto, diretamente na página da Web atual, sem verificar (e remover) conteúdo arriscado primeiro.

Imagine, por exemplo, que você tenha uma página da web que se oferece para me mostrar como uma string de texto de minha escolha se parece com sua nova fonte descolada.

Se eu digitar o texto de exemplo Cwm fjord bank glyphs vext quiz (um mashup artificial, mas vagamente significativo de inglês e galês que contém todas as 26 letras do alfabeto em apenas 26 letras, caso você esteja se perguntando), então é seguro colocar esse texto exato na página da Web que você cria.

Em JavaScript, por exemplo, você poderia reescrever o corpo da página da web assim, inserindo o texto que eu forneci sem nenhuma modificação:

document.body.innerHTML = "Quiz de glifos do banco do fiorde Cwm vext"

Mas se eu trapaceei e pedi para você “exibir” a string de texto Cwm fjord<script>alert(42)</script> em vez disso, seria imprudente para você fazer isso ...

document.body.innerHTML = "fiorde Cwmalert(42)"

…porque você estaria me permitindo injetar código JavaScript não confiável de my escolhendo diretamente em os página da web, onde meu código pode ler seus cookies e acessar dados que de outra forma estariam fora dos limites.

Então, para fazer o que é conhecido como higienizando seus insumos mais fácil, o Chrome agora habilitou oficialmente o suporte para uma nova função do navegador chamada setHTML().

Isso pode ser usado para enviar novo conteúdo HTML por meio de um recurso chamado Sanitizer primeiro, para que, se você usar este código ...

document.body.setHTML("Fiorde Cwmalert(42)")

…então o Chrome verificará primeiro a nova string HTML proposta em busca de problemas de segurança e removerá automaticamente qualquer texto que possa representar um risco.

Você pode ver isso em ação através do Ferramentas de desenvolvimento executando o acima setHTML() código no cônsul prompt e, em seguida, recuperando o HTML real que foi injetado no document.body variável, como fizemos aqui:

Apesar de colocarmos explicitamente um <script> tag na entrada que passamos para o setHTML() função, o código de script foi removido automaticamente da saída que foi criada.

Se você realmente precisa adicionar texto potencialmente perigoso em um elemento HTML, você pode adicionar um segundo argumento ao setHTML() função que especifica vários tipos de conteúdo arriscado para bloquear ou permitir.

Por padrão, se este segundo argumento for omitido conforme acima, o Sanitizer operará em seu nível máximo de segurança e limpará automaticamente todo o conteúdo perigoso conhecido.

O que fazer?

• Se você for um usuário do Chrome. Verifique se você está atualizado clicando Três pontos > Ajuda > Sobre o Google Chrome, ou navegando até o URL especial chrome://settings/help.
• Se você é um programador web. Aprenda sobre o novo Sanitizer e setHTML() funcionalidade lendo conselho do Google e os votos de Documentos da Web MDN.

---

A propósito, se você estiver no Firefox, Sanitizer está disponível, mas ainda não está ativado por padrão. Você pode ativá-lo para saber mais sobre ele acessando about:config e alternando o dom.security.sanitizer.enabled opção para true.

---