Uma exploração… em CSS?!

Ok, respire fundo.

Vamos nos divertir entendendo essa vulnerabilidade assim que você tiver certeza de que seu navegador não foi afetado, usando a tabela abaixo.

Então, você atualizou seu navegador e fez uma oração. Quando você conseguir encadear frases inteiras novamente, sua primeira pergunta será: O CSS realmente teve a duvidosa honra de ser a causa do a primeira exploração de dia zero em navegadores baseados em Chromium para 2026?

Quero dizer, o O canal de atualização do Chrome diz eles corrigiram uma vulnerabilidade de alta gravidade descrita como “(u)ser after free in CSS”… na sexta-feira, 13^o nada menos! Se você não pode confiar em um lançamento com uma descrição e data como essa, em que pode confiar? O Google credita ao pesquisador de segurança Shaheen Fazim o relato da exploração ao Google. O LinkedIn do cara diz que ele é um caçador de insetos profissionale eu diria que ele merece o maior recompensa de bugs possível por encontrar algo que uma agência governamental está dizendo “em CSS no Google Chrome antes de 145.0.7632.75 permitia que um invasor remoto executasse código arbitrário dentro de uma sandbox por meio de uma página HTML criada”.

Isso é realmente uma exploração de CSS?

Algo não bate. Até este pesquisador de segurança jura usar CSS em vez de JavaScriptpara que seus leitores preocupados com a segurança não precisem ativar o JavaScript ao lerem o blog dela. Ela confia na segurança do CSS, embora entenda o suficiente para criar um emulador CSS x86 puro (nota lateral: uau). Até agora, a maioria de nós tem como certo que os possíveis problemas de segurança no CSS são relativamente inofensivos. Certamente não vivemos de repente em um mundo onde o CSS pode sequestrar o sistema operacional de alguém, certo?

Bem, na minha opinião, as manchetes que descrevem o bug como uma exploração de CSS no Chrome são um pouco indutoras de cliques, porque fazem com que pareça uma exploração de CSS pura, como se CSS e HTML maliciosos fossem suficientes para executá-lo. Para ser honesto, quando li esses artigos pela primeira vez pela manhã, antes de sair correndo para pegar o trem para o trabalho, a forma como os artigos foram redigidos me fez imaginar CSS malicioso como:

.malicious-class {
  vulnerable-property: 'rm -rf *';
}

Na versão fictícia e de pesadelo do bug que minha imaginação mal informada conjurou, algum CSS desse tipo poderia ser “criado” para injetar aquele comando shell em algum lugar onde ele seria executado na máquina da vítima. Mesmo relendo os relatórios com mais atenção, eles parecem intencionalmente enganadores, e não fui só eu. A primeira pergunta que meu amigo preocupado com a segurança me fez foi: “Mas… o CSS não é supervalidável?” E então fui mais fundo e descobri o CSS no prova de conceito pois a exploração não é maliciosa, e é por isso que a validação CSS não teria ajudado!

Não ajuda o mal-entendido quando o Artigo do SitePoint sobre CVE-2026-2441 mente bizarramente para seus leitores sobre o que é essa exploração, em vez disso, descreve um bug diferente de gravidade média que permite enviar o valor renderizado de um campo de entrada para um servidor malicioso, carregando imagens em CSS. Não é isso que esta vulnerabilidade é.

Não é realmente uma exploração de CSS no sentido de que JavaScript é a parte que explora o bug. Admito que a linha de código que cria a condição necessária para que um script malicioso execute este ataque estava em Piscar do Google Chrome Componente do mecanismo CSS, mas o CSS envolvido não é a parte maliciosa.

Então, como funcionou a exploração?

O envolvimento do CSS na exploração reside na maneira como o mecanismo de renderização do Chrome transforma certos CSS em um Modelo de objeto CSS. Considere o CSS abaixo:

@font-feature-values VulnTestFont {
  @styleset {
    entry_a: 1;
    entry_b: 2;
    entry_c: 3;
    entry_d: 4;
    entry_e: 5;
    entry_f: 6;
    entry_g: 7;
    entry_h: 8;
  }
}

Quando este CSS é analisado, um CSSFontFeaturesValueMap é adicionado à coleção de CSSRule objetos no document.styleSheets(0).cssRules. Houve um bug na forma como o Chrome gerenciava a memória do HashMap estrutura de dados subjacente à representação JavaScript do CSSFontFeaturesValueMapque inadvertidamente permitiu que um script malicioso acessasse a memória que não deveria. Isso por si só não é suficiente para causar danos além de travar o navegador, mas pode formar a base para um Use a exploração After Free (UAF).

A descrição do patch do Chrome menciona que “o Google está ciente de que existe uma exploração para CVE-2026-2441”, embora, por razões óbvias, eles sejam tímidos quanto aos detalhes de uma exploração completa de ponta a ponta. Preocupantemente, @font-feature-values não é novo – está disponível desde o início de 2023 – mas a descoberta de uma exploração UAF de ponta a ponta pode ser recente. Faria sentido se o código que criou a possibilidade dessa exploração fosse antigo, mas alguém só conseguiu uma exploração funcional recentemente. Se você olhar para isso explicação detalhada de uma vulnerabilidade Use After Free 2020 no Chrome dentro do API WebÁudiovocê tem a sensação de que acessar a memória liberada é apenas uma peça do quebra-cabeça para fazer um exploit UAF funcionar. Sistemas operacionais modernos criar obstáculos pelos quais os invasores terão que passaro que pode tornar esse tipo de ataque bastante difícil.

Exemplos reais desse tipo de vulnerabilidade tornam-se complexos, especialmente em uma vulnerabilidade do Chrome, onde você só pode acionar instruções de baixo nível indiretamente. Mas se você conhece C e quer entender os princípios básicos com um exemplo simplificado, você pode experimente este desafio de codificação. Outra maneira de ajudar a entender as ideias é esta postagem média sobre o Chrome recente CSSFontFeaturesValueMap explorarque inclui uma analogia fofa em que o ponteiro ao objeto é como uma coleira que você ainda segura mesmo depois de libertar seu cachorro – mas, em vez disso, um invasor prende a coleira a um gato (conhecido como confusão de tipo), então, quando você ordena que seu “cachorro” latir, o invasor ensinou seu gato a pensar que o comando “latir” significa fazer algo malicioso.

O mundo está seguro novamente, mas por quanto tempo?

A correção de uma linha que mencionei que o Chrome fez foi alterar o código do Blink para funcionar com um cópia profunda do HashMap que está subjacente ao CSSFontFeaturesValueMap em vez de um ponteiro para ele, portanto não há possibilidade de fazer referência à memória liberada. Por outro lado, parece que o Firefox reescreveu seu renderizador CSS em Rust e, portanto, tende a lidar com o gerenciamento de memória automaticamente. Cromo começou a apoiar o uso de Rust desde 2023. Uma das motivações mencionadas foi “mais seguro (C++ menos complexo em geral, sem bugs de segurança de memória em uma sandbox)” e para “melhorar a segurança (aumentando o número de linhas de código sem bugs de segurança de memória, diminuindo a densidade de bugs do código) do cromo.” Como parece que a classe de exploração UAF se repetiu no Chromium ao longo dos anos, e essas vulnerabilidades tendem a ser de alta gravidade quando descobertas, pode ser necessária uma abordagem mais holística para a defesa contra tais vulnerabilidades, então não preciso assustar você com outro artigo como este.