Uma exploração… em CSS?! | Truques 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 é: O CSS realmente teve a duvidosa honra de ser a causa de a primeira exploração de dia zero em navegadores baseados em Chromium para 2026 ?

Quero dizer, 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, dia 13 ^th 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 bugs profissional , e eu diria que ele merece a maior recompensa de bugs possível por encontrar algo que uma agência governamental está dizendo “em CSS no Google O Chrome anterior a 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 certo. Até esta pesquisadora de segurança jura usar CSS em vez de JavaScript , para que seus leitores preocupados com a segurança não precisem ativar o JavaScript quando leem seu blog. 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 em 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 meu imaginação mal informada conjurou, algum CSS poderia ser “criado” para injetar esse 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 do meu amigo preocupado com a segurança foi: “Mas… o CSS não é supervalidável?” E então fui mais fundo e descobri que o CSS na prova de conceito para a exploração não é a parte maliciosa, e é por isso que a validação de 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 descrevendo 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 no componente do mecanismo CSS Blink do Google Chrome, 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 .malicious-class { vulnerable-property: 'rm -rf *'; } é adicionado à coleção de @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; } } objetos no CSSFontFeaturesValueMap. Houve um bug na maneira como o Chrome gerenciava a memória para a estrutura de dados CSSRule subjacente à representação JavaScript do .malicious-class { vulnerable-property: 'rm -rf *'; }, que 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 uma exploração Use 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 sobre os detalhes de uma exploração completa de ponta a ponta. Preocupantemente, HashMap não é novo – está disponível desde o início de 2023 – mas a descoberta de um a 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 esta explicação detalhada de uma vulnerabilidade 2020 Use After Free no Chrome dentro da WebAudio API , você terá a sensação de que acessar a memória liberada é apenas uma peça do quebra-cabeça para fazer uma exploração UAF funcionar. Os sistemas operacionais modernos criam obstáculos pelos quais os invasores precisam passar , o 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 deseja entender os princípios básicos com um exemplo simplificado, você pode tentar este desafio de codificação . Outra forma de ajudar a entender as ideias é esta postagem média sobre o recente Chrome .malicious-class { vulnerable-property: 'rm -rf *'; } exploit , que inclui uma analogia fofa em que o ponteiro para o 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 type confusão ), então, quando você ordena que seu “cachorro” latir, o atacante 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 Blink para funcionar com uma cópia profunda do CSSRule que está por trás do .malicious-class { vulnerable-property: 'rm -rf *'; } 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. Chromium começou a suportar 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 “ 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 Chrome .” 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.