Cadeia de exploit 0-click para o Pixel 10

• A cadeia do Pixel 10 usa como primeira etapa a vulnerabilidade Dolby 0-click que existia no Android em geral antes do patch, e adiciona um novo caminho de escalonamento local de privilégios
• O driver BigWave da cadeia do Pixel 9 não existe no Pixel 10, então não pôde ser portado; em seu lugar, o /dev/vpu do Tensor G5 virou a superfície de ataque
• O driver da VPU expunha diretamente à userspace uma interface de registradores MMIO, e uma auditoria de apenas 2 horas encontrou um bug crítico em mmap
• remap_pfn_range fazia o mapeamento com base apenas no tamanho da VMA, e não no tamanho dos registradores, permitindo leitura e escrita no .text e .data do kernel
• A vulnerabilidade foi reportada em 24 de novembro de 2025 e corrigida 71 dias depois, mostrando que o endurecimento de segurança dos drivers do Android ainda é necessário

---

Estrutura da cadeia 0-click do Pixel 10

• Com base na cadeia de exploits que alcançou root no Android a partir de um contexto 0-click no Google Pixel 9 com dois exploits, foi montada uma cadeia semelhante também no Pixel 10
• A vulnerabilidade Dolby 0-click existia em todo o Android até o patch de janeiro de 2026 e também foi usada como primeira etapa na cadeia voltada ao Pixel 10
• O driver BigWave, que era a etapa de escalonamento local de privilégios no Pixel 9, não está incluído no Pixel 10, então não pôde ser portado como estava; o driver /dev/vpu do Pixel 10 passou a ser a nova superfície de ataque

Atualização do exploit Dolby

• Adaptar o exploit existente para o CVE-2025-54957 ao Pixel 10 consistiu, em grande parte, em atualizar offsets baseados nas bibliotecas do Pixel 9 para os offsets correspondentes nas bibliotecas do Pixel 10
• O Pixel 10 usa RET PAC em vez de -fstack-protector, então não era possível sobrescrever __stack_chk_fail
• Após várias tentativas, foi usado o método de sobrescrever o código de inicialização dap_cpdp_init, chamado uma vez durante a inicialização do decoder e não chamado novamente
• O exploit Dolby UDC atualizado foi publicado aqui e funciona apenas em dispositivos sem patch com SPL de dezembro de 2025 ou anterior

Remoção do BigWave e adição da VPU

• O Pixel 10 não tem o driver BigWave, então não foi possível portar a etapa de escalonamento local de privilégios da cadeia existente do Pixel 9
• O driver /dev/vpu, acessível no contexto SELinux do mediacodec, apareceu como nova opção e é usado para interagir com o silício Chips&Media Wave677DV de aceleração de decodificação de vídeo no chip Tensor G5
• Pelos comentários no arquivo C público, esse driver parece ser desenvolvido e mantido pelo mesmo grupo de desenvolvedores que criou o driver BigWave
• Em uma auditoria de 2 horas no driver da VPU junto com Jann Horn, foi encontrada uma vulnerabilidade bastante incomum
• Diferentemente do driver Linux upstream para o chip anterior da Chips&Media, o WAVE521C, o driver WAVE677DV do Pixel não é integrado ao V4L2 (“Video for Linux API”)
• O driver do Pixel expõe diretamente à userspace a interface de hardware do chip, permitindo que a userspace mapeie a interface de registradores MMIO do chip
• O papel principal do driver é configurar mapeamentos de memória do dispositivo, gerenciar energia e permitir que a userspace espere por interrupções do chip

Vulnerabilidade central no kernel

• O bug em questão era uma vulnerabilidade com exploit extremamente simples
• O handler de mmap problemático é o código que mapeia a região de registradores MMIO do hardware da VPU para o espaço de endereçamento virtual do userland
• A chamada a remap_pfn_range não era limitada pelo tamanho da região de registradores, mas apenas pelo tamanho da VMA
• Um atacante podia especificar no mmap um tamanho maior do que a região de registradores e, assim, mapear para o userland tanta memória física quanto quisesse a partir do endereço físico da região de registradores da VPU
• Como a imagem inteira do kernel fica em um endereço físico acima da região de registradores da VPU, esse bug permite acessar e modificar as regiões .text e .data do kernel
• No Pixel, o kernel fica sempre no mesmo endereço físico, então o offset entre a região de memória da VPU e o kernel é sempre um valor conhecido
• Ao especificar um tamanho de VMA suficientemente grande, é possível saber com precisão a posição do kernel com base no endereço retornado por mmap, sem precisar varrer a memória física mapeada em busca do kernel
• Foram necessárias 5 linhas de código para obter leitura e escrita arbitrárias no kernel com essa vulnerabilidade, e a escrita do exploit completo levou menos de um dia
• É possível obter execução de código no kernel sobrescrevendo qualquer função do kernel ou montar o primitivo desejado

Processo de correção

• A vulnerabilidade foi reportada em 24 de novembro de 2025, e o Android VRP avaliou o problema com severidade High
• O bug do BigWave usado na elevação de privilégios do Pixel 9 tinha o mesmo impacto de segurança, mas foi inicialmente classificado como Moderate, então esta avaliação pode ser vista como um tratamento melhorado
• A vulnerabilidade foi corrigida no boletim de segurança do Pixel de fevereiro, 71 dias após o primeiro reporte
• Esta é considerada a primeira vez que um bug de driver do Android foi corrigido em até 90 dias após ser inicialmente reportado ao vendor
• O processo mostrou que a resposta do Android para classificar e corrigir bugs de tipo semelhante melhorou de forma significativa

Implicações de segurança

• A resposta à vulnerabilidade da VPU mostra que o pipeline de classificação do Android melhorou, com uma correção inicial acontecendo em um prazo muito menor do que no problema anterior do BigWave
• O esforço do Android para corrigir com eficiência vulnerabilidades graves ajuda a proteger muitos dispositivos Android
• Ao mesmo tempo, os drivers do Android continuam precisando de código mais rigoroso e desenvolvido com consciência de segurança
• Após o reporte do bug do BigWave, esperava-se que os desenvolvedores envolvidos verificassem problemas de segurança óbvios em outros drivers, mas 5 meses depois foi encontrada no driver da VPU uma vulnerabilidade grave que apareceu imediatamente mesmo em uma auditoria superficial
• Para a segurança do ecossistema Android, o reforço da segurança dos drivers continua sendo uma prioridade importante
• Vendors devem melhorar previamente as práticas de desenvolvimento de software para que vulnerabilidades não cheguem ao usuário final e, especialmente em produtos críticos para segurança, o software já deve ser lançado em um estado razoavelmente livre de vulnerabilidades
• As equipes de software devem adotar uma abordagem proativa para segurança, auditoria de código e correção de vulnerabilidades

[GN⁺]

Comentários do Hacker News

• Seguindo o link do bug/exploit do Pixel 9, havia a explicação de que, por causa dos recursos de IA, a mídia precisa ser decodificada antes de o usuário abrir a mensagem, o que aumenta a superfície de ataque de 0 clique
  Parece uma lição que já deveríamos ter aprendido. A ideia é: não leia SMS nem processe nada que eu não pedi

  • Não sei exatamente qual é a lição que deveríamos ter aprendido
    Os usuários escolhem celulares com recursos avançados de mensagens. No iPhone isso era o iMessage e, depois, no Android, o RCS foi alcançando esse nível; isso era um grande argumento de venda
  • Só isso não basta. Pense em um cliente de e-mail que não analisa imagens até o usuário interagir com a mensagem: no momento em que você clica e percebe que é suspeito, um mecanismo complexo e cheio de bugs já foi executado
    Pessoalmente, o mais absurdo que já vi foi marcar como spam uma mensagem muito suspeita, com um anexo quase certamente malicioso, em um webmail de BigTech. Como não era phishing, não havia outra opção, então ele “gentilmente” abriu no meu navegador local o link de descadastro sem pedir permissão. É difícil imaginar o nível de incompetência e disfunção organizacional necessário para escrever, revisar, aprovar e implantar esse tipo de recurso em um contexto sensível a segurança e privacidade
  • A Google controla o Android, mas a Google não se importa com os usuários. Os clientes deles são os anunciantes
    Nem mesmo um 0-day importa tanto. Como na prática a única alternativa é mais ou menos o iPhone, e a Huawei só é viável dependendo da região, eles têm pouco motivo para se preocupar. Precisamos urgentemente de um novo SO para celular e de uma nova camada de hardware
  • Ouvi recentemente uma apresentação sobre “AI Security”, e a ideia central era algo próximo de “vamos engolir sem senso crítico as entradas que vão e vêm da IA, isso é um problema de segurança, mas não há nada a fazer, então façam pós-processamento”
    Também incluía a frase “um agente de ameaça pode influenciar a IA se atualizar documentos internos”, mas se um agente de ameaça está atualizando documentos, então o ambiente já foi comprometido. Não estamos falando aqui de algo no nível de “vandalismo na Wikipedia”
  • Fazer o usuário abrir a mensagem não é uma barreira muito alta
    Do ponto de vista do usuário, é difícil aceitar que ele precise tomar cuidado com quais mensagens abre. Já tentamos empurrar essa responsabilidade para o usuário com anexos de e-mail, e é justo dizer que o resultado foi desastroso. Anexos maliciosos provavelmente ainda são a principal via de distribuição de malware

• A frase “esta foi a primeira vez que um bug de driver do Android foi corrigido em até 90 dias desde o momento em que o fornecedor tomou conhecimento da vulnerabilidade, então foi especialmente rápido” melhora minha impressão da Google, mas ao mesmo tempo torna o restante do ecossistema Android meio assustador
  Fico curioso sobre como seria o tempo de resposta da Apple

  • Há muito tempo os fornecedores de Android têm má fama por causa das atualizações. Dizem que um dos motivos é que as fabricantes de celular fazem um fork da UI padrão do Android para se diferenciar, oferecendo recursos próprios de marca e suas visões alucinadas de interface
    Mas isso torna o trabalho de migração gigantesco quando sai uma atualização do Android puro
  • Já reportei um bug de segurança para a Apple. Faz alguns anos, mas lembro que levou algo como 6 meses até sair o patch
    Houve algumas idas e vindas para construir uma prova de conceito mais estável e, depois que enviei uma prova de conceito 100% reproduzível, acho que foram mais uns 2 meses
  • Considerando que atualmente 42% dos dispositivos Android estão sem patch [1], a decisão de divulgar a pesquisa e tornar todos vulneráveis é interessante
    [1] https://gs.statcounter.com/android-version-market-share
    [2] https://www.cybersecurity-insiders.com/survey-reveals-over-1...
  • Se for um dispositivo Android de marca conhecida, dá para esperar atualizações de segurança do sistema operacional, porque o fornecedor de primeira linha pode compilar e distribuir isso diretamente
    Mas é difícil garantir atualizações de segurança de drivers e firmware. Muitas vezes essas atualizações precisam vir de fornecedores de nível superior, que podem ou não ter vontade de corrigir o problema. Marcas pequenas frequentemente vendem aparelhos Android baratos e simplesmente não fazem atualização nenhuma

• Meio relacionado: será que a proporção de exploits divulgados publicamente realmente aumentou, ou eles aparecem mais nas notícias porque a IA virou destaque tanto em ferramentas ofensivas quanto defensivas de segurança?
  Parece que a cada dois dias surge algo novo em Linux, Windows, mobile, ferramentas comuns usadas por todo mundo etc.

  • Lendo a parte 1 nas entrelinhas, o código em questão foi introduzido por causa de um recurso de IA, e o exploit foi encontrado por uma pessoa
    https://projectzero.google/2026/01/pixel-0-click-part-1.html
    Então o uso de IA aumenta o número de bugs, e os humanos precisam separá-los
  • Analisei isso por conta própria no último fim de semana, e em 2024 havia cerca de 100 CVEs divulgados por dia. Em abril, chegou a cerca de 200 por dia
    Se voltarmos para antes de 2023, o tempo para dobrar o número de CVEs divulgados era de cerca de 4 a 4,5 anos, mas desde então está em algo como 2 anos. Definitivamente acelerou bastante
  • Segundo pessoas que gerenciam bugs de segurança em open source, o volume de relatórios aumentou muito. No começo, a maioria era quase lixo, com relatórios de baixa qualidade, mas agora também há muito mais relatórios realmente válidos
  • É puro palpite, e eu não sou pesquisador de segurança, mas parece que a IA atua como acelerador ao mesmo tempo em que aumenta a superfície de ataque explorável de baixa qualidade e acelera o trabalho dos pesquisadores de segurança
    Ou seja, quando usada bem, é ótima; quando usada mal, é realmente ruim
  • Nas últimas semanas reportei alguns problemas bem sérios para fornecedores de ferramentas amplamente usadas, e foi mais difícil do que o normal conseguir reconhecimento
    Ouvi dizer que as equipes de resposta estão sobrecarregadas por uma avalanche de relatórios

• Queria que alguém confirmasse se meu raciocínio está certo. Coloquei o prompt exato abaixo no gpt 5.5 xhigh

  does this look right to you? don't do any searches or check memory, just think through first principles
  
  static int vpu_mmap(struct file fp, struct vm_area_struct vm) { unsigned long pfn; struct vpu_core core = container_of(fp->f_inode->i_cdev, struct vpu_core, cdev); vm_flags_set(vm, VM_IO | VM_DONTEXPAND | VM_DONTDUMP); / This is a CSRs mapping, use pgprot_device */ vm->vm_page_prot = pgprot_device(vm->vm_page_prot); pfn = core->paddr >> PAGE_SHIFT; return remap_pfn_range(vm, vm->vm_start, pfn, vm->vm_end-vm->vm_start, vm->vm_page_prot) ? -EAGAIN : 0; }  
  

  Mesmo sem busca na web, ele apontou corretamente o problema. Quero tentar algo mais abrangente, como colocar no prompt não só uma função específica, mas pedaços inteiros do codebase. Parece haver potencial para capturar exploits de segurança. Se for isso, então fico me perguntando como isso foi lançado desse jeito. Sei que é um exemplo de brinquedo, mas quero aprender mais

  • Esse não é um teste justo. Mesmo sem dizer explicitamente para encontrar um bug, o prompt direciona bastante o modelo
    É basicamente a mesma objeção que apareceu no tópico em que diziam que o modelo atual era tão bom quanto o mythos
  • Anedoticamente, coloquei fragnesia.c e depois o patch para corrigir o problema, e ele não descobriu uma vulnerabilidade totalmente nova, mas pareceu encontrar duas novas formas de explorar o mesmo bug subjacente
    Isso é bem impressionante, considerando que foi algo que eu, um idiota com só uma assinatura do Claude, consegui fazer
  • Só isso não basta para dizer se é um método realmente utilizável para encontrar vulnerabilidades. Não sabemos quantos falsos positivos apareceriam ao rodar isso sobre o código inteiro
    Em outras palavras, pode ser um caso de https://en.wikipedia.org/wiki/Base_rate_fallacy
  • Fico me perguntando como você sabe que ele não fez busca na web
  • Colei o código no claude Opus 4.7 sem acesso à internet e pedi só para explicar o que a função fazia, e ele apontou o bug enquanto explicava. Eu não pedi para procurar bug

    Observations & Potential Issues
    A few things worth flagging:

    1. No bounds checking on the mapping size. Userspace controls vm_end - vm_start and vm->vm_pgoff. Here vm_pgoff is ignored entirely and the size is trusted blindly. If the VPU's register block is, say, 64KB but userspace requests a 1MB mapping, the driver will happily map 1MB of physical address space starting at core->paddr — potentially exposing whatever hardware happens to live at adjacent physical addresses. A defensive check would be:
       Se estamos entrando em uma era em que bots podem escanear os PRs de todos os projetos open source assim que saem, um ciclo de release de 70 dias rapidamente deixará de ser suficiente para impedir o uso generalizado de exploits

• Excelente relatório de bug. Eu definitivamente não sou especialista em kernel e só li um pouco sobre isso há mais de 10 anos, mas ainda assim consegui acompanhar e entender o que estava acontecendo
  O fato de esse bug ser realmente grave e de não parecer ter dado tanto trabalho para encontrar me assusta, porque faz pensar em que outros riscos podem estar escondidos. E, com tantas questões de segurança recentes sendo encontradas com IA, esse relatório me fez pensar em duas coisas. Especialização continua sendo extremamente valiosa, e quanto mais nichada, mais valiosa. E ainda existem muitos nichos que a IA não dominou

• Não sei para onde foi o jailbreak de iPhone. Faz bastante tempo que não vejo nada, então o que está acontecendo? Fico me perguntando se perdi alguma coisa ou se realmente não existe mais nada viável
  O que quer que a Apple esteja fazendo, é impressionante, mas queria saber se, no ritmo atual, é só uma questão de tempo ou se houve alguma mudança real

  • A postura de segurança da Apple é consideravelmente melhor que a do Android graças ao Lockdown Mode, memory tagging e aos alocadores seguros
    Dá para ler sobre isso aqui: https://security.apple.com/blog/memory-integrity-enforcement...
  • Hoje em dia, exploits que sobrevivem a um reboot são quase impossíveis. E os exploits necessários para viabilizar um jailbreak agora exigem toda uma cadeia de exploits, têm valor considerável e são corrigidos assim que se tornam públicos
    Então algo como a antiga cena de jailbreak de iPhone basicamente não é mais possível
  • Sempre me irritou que “jailbreak” não recebesse o mesmo nível de escrutínio que vulnerabilidades de software em outras plataformas

• Existe alguma evidência de que a IA impactou o negócio de empresas como a NSO? Fico curioso se isso as torna inúteis ou se, ao contrário, as turbinou absurdamente

  • Não sei os detalhes, mas parece que a IA está mudando bastante o jogo e pode ter eliminado muito do “capital” representado pelos 0-days
    Se for esse o caso, é uma boa notícia para todo mundo, exceto para a NSO e empresas parecidas

• Já passei por um problema parecido. A solução parece razoável, mas sou cético quanto ao ganho de desempenho alegado

• As melhorias de V4L2 para suportar decodificação de vídeo por hardware ficaram esperando merge por muito tempo, e agora parecem ter entrado no kernel mainline
  Talvez as pessoas não quisessem esperar tanto tempo assim

• É surpreendente que até o Project Zero precise reportar bugs do Android pelo canal formal e lidar com a classificação de severidade do Android VRP
  Eu sempre imaginei que eles pudessem simplesmente ir até o escritório do Android e convencer alguém pessoalmente da importância do bug

  • Se o modo “normal” parecia doloroso demais, então provavelmente o próximo passo do Project Zero foi tentar consertar esse próprio processo
  • Isso depende da premissa de que o Android daria ouvidos ao Project Zero