Chaîne d’exploit 0-click pour Pixel 10

• La chaîne pour Pixel 10 utilise comme première étape une faille Dolby 0-click présente dans l’ensemble d’Android avant son correctif, et y ajoute une nouvelle voie d’élévation locale de privilèges
• Le pilote BigWave de la chaîne Pixel 9 n’existe pas sur Pixel 10, ce qui empêchait son portage ; à la place, le /dev/vpu du Tensor G5 devient la surface d’attaque
• Le pilote VPU exposait directement à l’espace utilisateur une interface de registres MMIO, et un audit de seulement 2 heures a suffi pour découvrir un bug mmap critique
• remap_pfn_range effectuait le mappage en se basant uniquement sur la taille de la VMA et non sur celle de la zone de registres, rendant possibles la lecture et l’écriture dans .text et .data du noyau
• La faille a été signalée le 24 novembre 2025 puis corrigée 71 jours plus tard, ce qui montre qu’un renforcement de la sécurité des pilotes Android reste nécessaire

---

Composition de la chaîne 0-click pour Pixel 10

• En s’appuyant sur la chaîne d’exploit qui permettait, sur Google Pixel 9, d’atteindre le root Android depuis un contexte 0-click avec deux exploits, une chaîne similaire a été construite pour Pixel 10
• La faille Dolby 0-click existait dans l’ensemble d’Android jusqu’au correctif de janvier 2026, et elle sert aussi de première étape dans la chaîne visant Pixel 10
• Le pilote BigWave, qui constituait l’étape d’élévation locale de privilèges sur Pixel 9, n’étant pas présent sur Pixel 10, il n’a pas pu être porté tel quel ; le pilote /dev/vpu de Pixel 10 est donc devenu une nouvelle surface d’attaque

Mise à jour de l’exploit Dolby

• L’adaptation de l’exploit existant pour CVE-2025-54957 à Pixel 10 s’est essentiellement résumée à mettre à jour les offsets basés sur les bibliothèques du Pixel 9 vers les offsets correspondants dans les bibliothèques du Pixel 10
• Pixel 10 utilise RET PAC au lieu de -fstack-protector, ce qui empêchait d’écraser __stack_chk_fail
• Après plusieurs essais, la méthode retenue a consisté à écraser le code d’initialisation dap_cpdp_init, appelé une seule fois lors de l’initialisation du décodeur puis jamais de nouveau
• L’exploit Dolby UDC mis à jour est publié ici et ne fonctionne que sur les appareils non corrigés avec un SPL de décembre 2025 ou antérieur

Suppression de BigWave et ajout du VPU

• Pixel 10 n’embarque pas le pilote BigWave, ce qui empêchait de porter l’étape d’élévation locale de privilèges de la chaîne Pixel 9 existante
• Le pilote /dev/vpu, accessible depuis le contexte SELinux mediacodec, est apparu comme une nouvelle piste ; il sert à interagir avec le silicium Chips&Media Wave677DV dédié à l’accélération du décodage vidéo sur la puce Tensor G5
• D’après les commentaires présents dans les fichiers C publics, ce pilote semble être développé et maintenu par le même groupe que celui à l’origine du pilote BigWave
• Un audit de 2 heures du pilote VPU, mené avec Jann Horn, a permis de découvrir une faille tout à fait exceptionnelle
• Contrairement au pilote Linux upstream pour l’ancienne puce Chips&Media WAVE521C, le pilote Pixel pour WAVE677DV n’est pas intégré à V4L2 (« Video for Linux API »)
• Le pilote Pixel expose directement à l’espace utilisateur l’interface matérielle de la puce, ce qui permet à l’espace utilisateur de mapper l’interface de registres MMIO de la puce
• Le rôle principal du pilote est de configurer les mappages mémoire du périphérique, de gérer l’alimentation et d’aider l’espace utilisateur à attendre les interruptions de la puce

Faille noyau centrale

• Le bug en question était une vulnérabilité extrêmement simple à exploiter
• Le gestionnaire mmap concerné contient le code qui mappe la zone de registres MMIO du matériel VPU dans l’espace d’adressage virtuel userland
• L’appel à remap_pfn_range n’était pas limité à la taille de la zone de registres et se basait uniquement sur la taille de la VMA
• Un attaquant pouvait, dans l’appel système mmap, spécifier une taille supérieure à celle de la zone de registres, afin de mapper dans userland autant de mémoire physique que souhaité à partir de l’adresse physique de la zone de registres VPU
• Comme l’image entière du noyau se trouve à une adresse physique supérieure à celle de la zone de registres VPU, ce bug permet d’accéder aux zones .text et .data du noyau et de les modifier
• Sur Pixel, le noyau est toujours placé à la même adresse physique, de sorte que l’offset entre la zone mémoire VPU et le noyau est toujours connu
• En spécifiant une longueur de VMA suffisamment grande, il est possible de connaître avec précision la position du noyau à partir de l’adresse renvoyée par mmap, sans avoir à scanner le noyau dans la mémoire physique mappée
• Il n’a fallu que 5 lignes de code pour obtenir une lecture/écriture arbitraire du noyau avec cette faille, et l’écriture de l’exploit complet a pris moins d’une journée
• Il est possible d’écraser une fonction arbitraire du noyau pour obtenir l’exécution de code dans le noyau, ou de construire le primitive souhaité

Déploiement du correctif

• La faille a été signalée le 24 novembre 2025, et l’Android VRP a évalué ce problème comme étant de sévérité High
• Le bug BigWave utilisé pour l’élévation de privilèges sur Pixel 9 avait le même impact de sécurité, mais avait initialement été classé comme Moderate ; cette fois, l’évaluation peut donc être vue comme une amélioration du traitement
• La faille a été corrigée dans le bulletin de sécurité Pixel de février, 71 jours après le signalement initial
• Il s’agirait de la première fois qu’un bug de pilote Android est corrigé dans un délai de 90 jours après son premier signalement au fournisseur
• Ce traitement montre que la réponse d’Android pour classer et corriger des bugs de nature similaire s’est améliorée de manière significative

Implications en matière de sécurité

• La réponse à la faille VPU montre que le pipeline de classification d’Android s’est amélioré, avec un correctif initial apporté dans un délai bien plus court que pour le précédent problème BigWave
• Les efforts d’Android pour corriger efficacement les vulnérabilités graves contribuent à protéger de nombreux appareils Android
• En même temps, les pilotes Android ont toujours besoin d’un code plus rigoureux et davantage pensé avec la sécurité en tête
• Après le signalement du bug BigWave, on pouvait espérer que les développeurs concernés examinent les problèmes de sécurité manifestes dans d’autres pilotes ; pourtant, cinq mois plus tard, une vulnérabilité grave immédiatement visible à la faveur d’un simple audit superficiel a été découverte dans le pilote VPU
• Pour la sécurité de l’écosystème Android, le renforcement de la sécurité des pilotes reste une priorité importante
• Les fournisseurs doivent améliorer en amont leurs pratiques de développement logiciel afin d’empêcher que des vulnérabilités n’atteignent les utilisateurs finaux, et les produits critiques pour la sécurité doivent en particulier être livrés dans un état raisonnablement peu vulnérable dès leur sortie
• Les équipes logicielles doivent adopter une approche proactive de la sécurité, de l’audit de code et du correctif des vulnérabilités

[GN⁺]

Réactions sur Hacker News

• En suivant les liens vers les bugs/exploits du Pixel 9, je suis tombé sur l’idée que, à cause des fonctionnalités IA, le système doit décoder les médias avant même que l’utilisateur ouvre le message, ce qui élargit la surface d’attaque en 0-clic
  J’ai l’impression que c’est une leçon qu’on aurait déjà dû retenir. À savoir : ne lisez pas mes SMS et ne traitez rien sans que je l’aie demandé

  • Je ne vois pas exactement quelle est la leçon que nous étions censés avoir apprise
    Les utilisateurs choisissent des téléphones avec des fonctions de messagerie riches. Sur iPhone, iMessage a longtemps été un gros argument de vente, puis Android a fini par rattraper avec RCS
  • Ce n’est même pas suffisant. Si on pense à un client mail qui n’analyse pas les images tant que l’utilisateur n’a pas interagi avec le message, au moment où on clique et qu’on comprend que c’est suspect, une machine complexe et buguée a déjà été exécutée
    Personnellement, le plus absurde que j’aie vu, c’est quand j’ai marqué comme spam, dans un webmail de BigTech, un message très suspect contenant presque certainement une pièce jointe malveillante ; comme ce n’était pas du phishing, il n’y avait pas d’autre option, et le service a “gentiment” ouvert le lien de désinscription dans mon navigateur local sans me demander mon avis. Il est difficile d’imaginer le niveau d’incompétence et de dysfonctionnement organisationnel nécessaire pour écrire, relire, approuver et déployer une telle fonctionnalité dans un contexte aussi sensible pour la sécurité et la vie privée
  • Google possède Android, mais Google se moque des utilisateurs. Ses clients, ce sont les annonceurs
    Même les 0-day n’ont pas beaucoup d’importance. Comme il n’existe pratiquement pas d’alternative en dehors de l’iPhone, et que Huawei n’est envisageable que selon les régions, ils n’ont guère de raison de s’en soucier. Il nous faut de toute urgence un nouvel OS mobile et une nouvelle couche matérielle
  • J’ai récemment écouté une présentation sur la “AI Security”, et l’idée générale était proche de : “on va ingérer sans esprit critique tout ce qui entre et sort de l’IA ; oui, c’est un problème de sécurité, mais on n’y peut rien, donc faites un peu de post-traitement”
    Il y avait aussi : “un acteur malveillant peut influencer l’IA en modifiant des documents internes”, mais si un acteur malveillant modifie des documents, alors le système est déjà compromis. On ne parle pas ici de “vandalisme sur Wikipedia”
  • Faire ouvrir un message par l’utilisateur, ce n’est pas une barrière très élevée
    Du point de vue utilisateur, il est difficilement acceptable de devoir faire attention à chaque message qu’on ouvre. On a déjà essayé de rejeter la responsabilité sur l’utilisateur avec les pièces jointes d’e-mail, et on peut raisonnablement dire que le résultat a été catastrophique. Les pièces jointes malveillantes sont probablement l’un des vecteurs les plus importants de distribution de malware

• La phrase disant que “c’est la première fois qu’un bug de pilote Android a été corrigé dans les 90 jours après que le fournisseur a pris connaissance de la vulnérabilité” améliore mon opinion de Google, mais en même temps elle rend le reste de l’écosystème Android assez inquiétant
  Je me demande quels sont les délais de réponse d’Apple

  • Les fournisseurs Android ont mauvaise réputation pour les mises à jour depuis très longtemps. L’une des raisons souvent avancées est que les constructeurs forkent l’UI Android de base pour se différencier, en ajoutant des fonctionnalités propres à leur marque et des visions d’interface parfois hallucinées
    Mais du coup, quand une mise à jour d’Android stock sort, le travail de migration devient énorme
  • J’ai déjà signalé un bug de sécurité à Apple. Ça remonte à quelques années, mais dans mon souvenir il a fallu environ 6 mois pour obtenir un correctif
    On a fait quelques allers-retours pour construire une preuve de concept plus stable, puis après l’envoi d’une PoC reproductible à 100 %, il a probablement fallu encore 2 mois
  • Quand on voit que 42 % des appareils Android ne sont pas patchés actuellement [1], la décision de publier les recherches et de rendre tout le monde vulnérable est intéressante
    [1] https://gs.statcounter.com/android-version-market-share
    [2] https://www.cybersecurity-insiders.com/survey-reveals-over-1...
  • Sur un appareil Android d’une grande marque, on peut espérer des mises à jour de sécurité de l’OS, parce que le fournisseur principal peut les compiler et les pousser directement
    En revanche, pour les mises à jour de sécurité des pilotes et du firmware, c’est beaucoup moins garanti. Ces mises à jour doivent souvent venir de fournisseurs en amont, qui peuvent ou non avoir envie de corriger le problème. Les petites marques vendent souvent des appareils Android bon marché sans jamais les mettre à jour

• Un peu en lien avec ça : je me demande si la proportion d’exploits publics a réellement augmenté récemment, ou si c’est simplement qu’avec l’attention portée à l’IA comme outil de sécurité, côté attaque comme côté défense, on en voit davantage dans les actualités
  J’ai l’impression qu’un nouveau truc sort un jour sur deux pour Linux, Windows, le mobile, ou des outils courants que tout le monde utilise

  • Si on lit bien entre les lignes de la partie 1, le code en question a été introduit à cause de la fonctionnalité IA, et l’exploit a été trouvé par un humain
    https://projectzero.google/2026/01/pixel-0-click-part-1.html
    Donc l’IA augmente le nombre de bugs, et ce sont les humains qui doivent les débusquer
  • J’ai regardé ça moi-même le week-end dernier : en 2024, on était à environ 100 CVE publiées par jour. En avril, on est monté à environ 200 par jour
    Si on remonte avant 2023, le temps de doublement du nombre de CVE publiées était d’environ 4 à 4,5 ans ; depuis, on est plutôt autour de 2 ans. L’augmentation est clairement très nette
  • D’après des personnes qui gèrent des bugs de sécurité open source, le volume de signalements a fortement augmenté. Au début, c’était surtout des signalements de faible qualité proches du faux positif, mais désormais il y a aussi beaucoup plus de signalements réellement valides
  • Ce n’est qu’une supposition, et je ne suis pas chercheur en sécurité, mais j’ai l’impression que l’IA agit à la fois comme un accélérateur de surfaces d’attaque exploitables de faible qualité, et comme un multiplicateur de vitesse pour le travail des chercheurs en sécurité
    En clair : bien utilisée, c’est excellent ; mal utilisée, c’est vraiment mauvais
  • Ces dernières semaines, j’ai signalé plusieurs problèmes assez sérieux à des éditeurs d’outils largement utilisés, et il a été plus difficile que d’habitude d’obtenir une reconnaissance
    J’ai entendu dire que les équipes de réponse étaient en surcharge à cause d’un déluge de signalements

• J’aimerais que quelqu’un vérifie si je ne me trompe pas. J’ai soumis ce prompt exact à 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; }  
  

  Sans recherche web, il a pointé le problème avec précision. J’aimerais essayer de manière plus large, par exemple en donnant non pas une fonction précise mais des pans entiers de code. Il semble y avoir un potentiel réel pour détecter des exploits de sécurité. Du coup, je me demande surtout comment cela a pu être publié ainsi au départ. Je sais que c’est un exemple simplifié, mais j’aimerais en apprendre davantage

  • Ce n’est pas un test équitable. Même si le prompt ne dit pas explicitement de chercher un bug, il oriente quand même assez fortement le modèle dans cette direction
    C’est au fond la même objection que dans le fil où certains affirmaient que les modèles actuels étaient aussi bons que mythos
  • Anecdotiquement, j’ai testé avec fragnesia.c et le patch censé corriger ensuite le problème ; je n’ai pas trouvé de vulnérabilité totalement nouvelle, mais j’ai l’impression d’avoir identifié deux nouvelles façons d’exploiter le même bug racine
    C’est plutôt impressionnant quand on se dit que ça vient d’un idiot comme moi, avec seulement un abonnement Claude
  • À ce stade, on ne peut pas savoir si c’est réellement exploitable pour trouver des vulnérabilités en pratique, parce qu’on ne sait pas combien de faux positifs cela produirait sur du code complet
    Autrement dit, cela pourrait relever du https://en.wikipedia.org/wiki/Base_rate_fallacy
  • Je me demande comment vous savez qu’il n’a pas fait de recherche web
  • J’ai collé ce code dans claude Opus 4.7 sans accès Internet, en lui demandant simplement d’expliquer ce que fait la fonction, et il a aussi signalé le bug dans son explication. Je ne lui ai pas demandé de chercher un 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:
       Si nous entrons dans une époque où des bots peuvent scanner les PR de tous les projets open source dès leur publication, alors un cycle de publication de 70 jours deviendra très vite insuffisant pour empêcher l’usage généralisé d’exploits

• Excellent rapport de bug. Je ne suis absolument pas spécialiste du kernel, j’en ai juste lu un peu il y a plus de dix ans, et pourtant j’ai pu suivre et comprendre ce qui se passait
  Le fait que ce bug ait été réellement grave et qu’il n’ait pas semblé demander un travail énorme pour être trouvé me fait peur quant aux autres risques qui peuvent se cacher. Et comme beaucoup de problèmes de sécurité sont récemment trouvés avec l’aide de l’IA, ce rapport me fait penser à deux choses. L’expertise reste extrêmement précieuse, et plus elle est de niche, plus elle a de valeur. Et il reste encore beaucoup de niches où l’IA ne domine pas

• Je me demande ce qu’il est advenu du jailbreak sur iPhone. Je n’en ai plus vu depuis longtemps ; qu’est-ce qui se passe exactement ? Je me demande si j’ai raté quelque chose, ou si ce n’est tout simplement plus vraiment possible
  Quoi qu’Apple fasse, c’est impressionnant, mais je voudrais savoir si, dans la tendance actuelle, ce n’est qu’une question de temps ou s’il y a eu un vrai changement

  • La posture de sécurité d’Apple est nettement meilleure que celle d’Android grâce au Lockdown Mode, au memory tagging et à l’allocateur sécurisé
    On peut en lire une partie ici : https://security.apple.com/blog/memory-integrity-enforcement...
  • Aujourd’hui, les exploits qui survivent à un redémarrage sont presque impossibles. Et les exploits nécessaires pour permettre un jailbreak exigent désormais une chaîne d’exploits complète ; leur valeur est très élevée et ils sont patchés dès qu’ils deviennent publics
    C’est pourquoi la scène du jailbreak iPhone telle qu’on la connaissait est désormais impossible
  • Cela m’a toujours agacé que le “jailbreak” ne fasse pas l’objet du même niveau de vérification que les vulnérabilités logicielles sur d’autres plateformes

• Existe-t-il des éléments montrant quel impact l’IA a eu sur l’activité d’entreprises comme NSO ? Je me demande si cela les rend obsolètes, ou au contraire si cela les surbooste

  • Je n’en sais pas assez pour répondre précisément, mais j’ai l’impression que l’IA change profondément la donne et qu’une grande partie du “capital” que représentaient les 0-day a dû disparaître
    Si c’est le cas, ce serait une bonne nouvelle pour tout le monde, sauf NSO et les entreprises du même genre

• J’ai déjà rencontré un problème similaire. La solution paraît raisonnable, mais je reste sceptique sur le gain de performance annoncé

• Les améliorations de V4L2 destinées à prendre en charge le décodage vidéo matériel sont restées en attente d’intégration pendant longtemps, et elles semblent maintenant être dans le kernel mainline
  J’imagine que certains n’avaient pas envie d’attendre aussi longtemps

• Je suis surpris que même Project Zero doive signaler les bugs à Android via le canal officiel, puis subir la classification de sévérité du VRP Android
  J’ai toujours imaginé qu’ils pouvaient simplement passer au bureau Android et convaincre en face à face de l’importance du bug

  • Si la voie “normale” leur a semblé trop pénible, Project Zero a sans doute essayé ensuite de faire corriger cette voie elle-même
  • Cela suppose qu’Android écoute effectivement ce que dit Project Zero