0-Click-Exploit-Kette für Pixel 10

 (projectzero.google)
1 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Die Pixel-10-Kette verwendet als ersten Schritt die Dolby-0-Click-Schwachstelle, die vor dem Patch in Android allgemein vorhanden war, und ergänzt einen neuen lokalen Privilegieneskalationspfad
  • Der BigWave-Treiber aus der Pixel-9-Kette ist auf dem Pixel 10 nicht vorhanden und konnte daher nicht portiert werden; stattdessen wurde /dev/vpu auf dem Tensor G5 zur Angriffsfläche
  • Der VPU-Treiber legte die MMIO-Registerschnittstelle direkt für den Userspace offen, und bereits in nur zwei Stunden Audit wurde ein kritischer mmap-Bug gefunden
  • Weil remap_pfn_range das Mapping nicht an der Registergröße, sondern nur an der VMA-Größe ausrichtete, wurden Lese- und Schreibzugriffe auf Kernel-.text und .data möglich
  • Die Schwachstelle wurde am 24. November 2025 gemeldet und nach 71 Tagen gepatcht; eine Härtung der Android-Treibersicherheit ist weiterhin nötig

Aufbau der Pixel-10-0-Click-Kette

  • Aufbauend auf der Exploit-Kette, mit der auf dem Google Pixel 9 im 0-Click-Kontext über zwei Exploits Android-Root erreicht wurde, wurde auch für das Pixel 10 eine ähnliche Kette aufgebaut
  • Die Dolby-0-Click-Schwachstelle war bis zum Patch im Januar 2026 in Android allgemein vorhanden und wurde auch in der Kette für das Pixel 10 als erster Schritt verwendet
  • Der BigWave-Treiber, der im Pixel 9 den Schritt der lokalen Privilegieneskalation bildete, ist im Pixel 10 nicht enthalten und konnte daher nicht unverändert portiert werden; stattdessen wurde der /dev/vpu-Treiber des Pixel 10 zur neuen Angriffsfläche

Update des Dolby-Exploits

  • Die Anpassung des bestehenden Exploits für CVE-2025-54957 an das Pixel 10 bestand größtenteils darin, Offsets auf Basis der Pixel-9-Bibliotheken durch die entsprechenden Offsets in den Bibliotheken des Pixel 10 zu ersetzen
  • Das Pixel 10 verwendet RET PAC statt -fstack-protector, sodass __stack_chk_fail nicht überschrieben werden konnte
  • Nach mehreren Versuchen wurde stattdessen der Initialisierungscode dap_cpdp_init überschrieben, der bei der Decoder-Initialisierung einmal aufgerufen und danach nicht erneut aufgerufen wird
  • Der aktualisierte Dolby-UDC-Exploit ist hier veröffentlicht und funktioniert nur auf ungepatchten Geräten mit Patchlevel Dezember 2025 oder älter

BigWave entfernt, VPU hinzugefügt

  • Auf dem Pixel 10 fehlt der BigWave-Treiber, daher ließ sich der Schritt der lokalen Privilegieneskalation aus der bestehenden Pixel-9-Kette nicht portieren
  • Stattdessen fiel der im mediacodec-SELinux-Kontext erreichbare /dev/vpu-Treiber auf, der zur Interaktion mit dem Chips&Media Wave677DV-Silizium für hardwarebeschleunigte Videodekodierung im Tensor-G5-Chip dient
  • Aus den Kommentaren in den öffentlich zugänglichen C-Dateien geht hervor, dass dieser Treiber von derselben Gruppe entwickelt und gepflegt wird wie der BigWave-Treiber
  • Bei einem zweistündigen Audit des VPU-Treibers zusammen mit Jann Horn wurde eine höchst ungewöhnliche Schwachstelle entdeckt
  • Anders als der Upstream-Linux-Treiber für den früheren Chips&Media-Chip WAVE521C ist der WAVE677DV-Treiber im Pixel nicht in V4L2 („Video for Linux API“) integriert
  • Der Pixel-Treiber legt die Hardware-Schnittstelle des Chips direkt für den Userspace offen und erlaubt dem Userspace, die MMIO-Registerschnittstelle des Chips zu mappen
  • Die Hauptaufgaben des Treibers bestehen darin, Device-Memory-Mappings einzurichten, das Power-Management zu übernehmen und den Userspace beim Warten auf Chip-Interrupts zu unterstützen

Zentrale Kernel-Schwachstelle

  • Der betreffende Bug war eine Schwachstelle mit sehr einfacher Ausnutzbarkeit
  • Der problematische mmap-Handler ist der Code, der den MMIO-Registerbereich der VPU-Hardware in den virtuellen Adressraum des Userlands mappt
  • Der Aufruf von remap_pfn_range wurde nicht auf die Größe des Registerbereichs begrenzt, sondern nur anhand der VMA-Größe ausgeführt
  • Ein Angreifer kann im mmap-Systemaufruf eine größere Größe als den Registerbereich angeben und so ab der physischen Adresse des VPU-Registerbereichs beliebig viel physischen Speicher in das Userland mappen
  • Da sich das gesamte Kernel-Image an höheren physischen Adressen als der VPU-Registerbereich befindet, ermöglicht dieser Bug den Zugriff auf die Kernel-Bereiche .text und .data sowie deren Modifikation
  • Auf Pixel-Geräten befindet sich der Kernel immer an derselben physischen Adresse, sodass der Offset zwischen dem VPU-Speicherbereich und dem Kernel stets bekannt ist
  • Gibt man eine ausreichend große VMA-Länge an, lässt sich die genaue Position des Kernels relativ zu der von mmap zurückgegebenen Adresse bestimmen, ohne den gemappten physischen Speicher nach dem Kernel scannen zu müssen
  • Um mit dieser Schwachstelle beliebige Lese- und Schreibzugriffe auf den Kernel zu erreichen, waren fünf Zeilen Code ausreichend, und das Schreiben des gesamten Exploits dauerte weniger als einen Tag
  • Durch Überschreiben einer beliebigen Kernel-Funktion lässt sich Kernel-Codeausführung erlangen oder ein gewünschtes Primitive aufbauen

Patch-Verfahren

  • Die Schwachstelle wurde am 24. November 2025 gemeldet, und das Android VRP bewertete das Problem als High Severity
  • Der BigWave-Bug, der für die Privilegieneskalation auf dem Pixel 9 genutzt wurde, hatte dieselben Sicherheitsauswirkungen, war aber anfangs nur als Moderate eingestuft worden; die aktuelle Bewertung kann daher als verbesserte Behandlung gelten
  • Die Schwachstelle wurde 71 Tage nach der ersten Meldung im Pixel-Sicherheitsbulletin für Februar gepatcht
  • Erstmals wurde damit ein Android-Treiber-Bug innerhalb von 90 Tagen nach der ersten Meldung an den Vendor gepatcht
  • Der Ablauf zeigt, dass sich Androids Reaktion beim Klassifizieren und Patchen ähnlicher Bug-Typen deutlich verbessert hat

Bedeutung für die Sicherheit

  • Die Reaktion auf die VPU-Schwachstelle zeigt, dass sich Androids Klassifizierungs-Pipeline verbessert hat und dass die erste Korrektur deutlich schneller erfolgte als beim früheren BigWave-Problem
  • Androids Bemühungen, schwerwiegende Schwachstellen effizient zu patchen, helfen dabei, viele Android-Geräte zu schützen
  • Gleichzeitig braucht Android bei Treibern weiterhin gründlicheren und sicherheitsbewussteren Code
  • Nach der Meldung des BigWave-Bugs hätte man erwarten können, dass die beteiligten Entwickler offensichtliche Sicherheitsprobleme in anderen Treibern prüfen; stattdessen wurde fünf Monate später im VPU-Treiber eine schwerwiegende Schwachstelle entdeckt, die schon bei einem oberflächlichen Audit sofort auffiel
  • Für die Sicherheit des Android-Ökosystems bleibt eine Stärkung der Treibersicherheit weiterhin eine wichtige Priorität
  • Vendoren sollten ihre Softwareentwicklungspraktiken im Vorfeld verbessern, damit Schwachstellen gar nicht erst bei Endnutzern ankommen; insbesondere sicherheitskritische Produkte sollten bereits zum Veröffentlichungszeitpunkt in einem vernünftigerweise schwachstellenarmen Zustand sein
  • Software-Teams sollten bei Sicherheit, Code-Audits und dem Patchen von Schwachstellen einen proaktiven Ansatz verfolgen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
Hacker-News-Kommentare

  • Als ich dem Link zum Pixel-9-Bug/Exploit gefolgt bin, stand dort, dass wegen der AI-Funktionen Medien dekodiert werden müssen, bevor der Nutzer die Nachricht öffnet, wodurch sich die 0-Click-Angriffsfläche vergrößert.
    Ich hätte gedacht, diese Lektion hätten wir bereits gelernt. Nämlich: Lies keine SMS und verarbeite nichts daraus, wenn ich nicht darum gebeten habe.

    • Ich weiß nicht genau, was die Lektion ist, die wir hätten lernen sollen.
      Nutzer wählen Telefone mit umfangreichen Messaging-Funktionen. Beim iPhone war iMessage ein großes Verkaufsargument, und später hat Android mit RCS aufgeholt.
    • Das allein reicht nicht aus. Wenn man an einen E-Mail-Client denkt, der Bilder erst parst, nachdem der Nutzer mit der Nachricht interagiert hat, ist in dem Moment, in dem man draufklickt und merkt, dass etwas verdächtig ist, bereits eine komplexe und fehleranfällige Maschinerie angelaufen.
      Das Absurde, das ich persönlich erlebt habe: Ich habe in einem BigTech-Webmail eine sehr verdächtige Nachricht mit ziemlich sicher bösartigem Anhang als Spam markiert, weil es kein Phishing war und es keine andere Option gab, und dann hat es „freundlicherweise“ ohne Erlaubnis auf meinem lokalen Browser den Abmeldelink geöffnet. Es ist schwer vorstellbar, wie viel Inkompetenz und organisatorische Dysfunktion nötig sind, um in einem sicherheits- und datenschutzsensiblen Kontext so eine Funktion zu schreiben, zu reviewen, freizugeben und auszurollen.
    • Google besitzt Android, aber Google interessiert sich nicht für Nutzer. Ihre Kunden sind Werbekunden.
      Auch 0-Days sind nicht besonders wichtig. Praktisch gibt es als Alternative nur das iPhone, und Huawei kommt je nach Region höchstens eingeschränkt infrage, also gibt es wenig Grund, sich darum zu kümmern. Wir brauchen dringend ein neues Smartphone-OS und eine neue Hardware-Schicht.
    • Ich habe kürzlich einen Vortrag über „AI Security“ gehört, und die Kernaussage war fast: „Wir werden Ein- und Ausgaben von AI unkritisch schlucken, das ist ein Sicherheitsproblem, aber man kann nichts dagegen tun, also macht halt Nachbearbeitung.“
      Da fiel auch der Satz: „Wenn ein Threat Actor interne Dokumente aktualisiert, kann er dadurch die AI beeinflussen.“ Aber wenn ein Threat Actor Dokumente aktualisiert, ist das System bereits kompromittiert. Es geht hier nicht um das Niveau von „Wikipedia-Vandalismus“.
    • Einen Nutzer dazu zu bringen, eine Nachricht zu öffnen, ist keine besonders hohe Hürde.
      Aus Nutzersicht ist es schwer hinnehmbar, bei jeder Nachricht aufpassen zu müssen, ob man sie öffnen darf. Wir haben schon versucht, die Verantwortung bei E-Mail-Anhängen auf die Nutzer abzuwälzen, und das Ergebnis war, fairerweise gesagt, katastrophal. Bösartige Anhänge sind wahrscheinlich einer der wichtigsten Wege zur Malware-Verbreitung.

  • Die Formulierung „Dies ist das erste Mal, dass ein Android-Treiberfehler innerhalb von 90 Tagen ab dem Zeitpunkt gepatcht wurde, zu dem der Vendor erstmals von der Schwachstelle erfuhr, daher ist dies besonders schnell“ verbessert zwar meinen Eindruck von Google, aber zugleich macht mir der Rest des Android-Ökosystems etwas Angst.
    Ich frage mich, wie Apples Reaktionszeit aussieht.

    • Android-Vendoren haben seit Langem einen schlechten Ruf bei Updates. Ein Grund dafür sei, dass Handyhersteller das Standard-Android-UI forken, um sich voneinander zu unterscheiden und markenspezifische Funktionen sowie halluzinatorische UI-Visionen anzubieten.
      Aber wenn dann ein Android-Update für das Grundsystem erscheint, wird der Migrationsaufwand enorm.
    • Ich habe Apple einmal einen Sicherheitsfehler gemeldet. Das ist ein paar Jahre her, aber soweit ich mich erinnere, dauerte es bis zum Patch ungefähr 6 Monate.
      Wir sind ein paarmal hin und her gegangen, um einen stabileren Proof of Concept zu bauen, und nachdem ich einen zu 100 % reproduzierbaren Proof of Concept eingereicht hatte, waren es vermutlich noch etwa 2 Monate.
    • Wenn man bedenkt, dass derzeit 42 % der Android-Geräte ungepatcht sind [1], ist die Entscheidung interessant, die Forschungsergebnisse zu veröffentlichen und damit alle verwundbar zu machen.
      [1] https://gs.statcounter.com/android-version-market-share
      [2] https://www.cybersecurity-insiders.com/survey-reveals-over-1...
    • Bei Android-Geräten bekannter Marken kann man mit OS-Sicherheitsupdates rechnen, weil der direkte Vendor sie bauen und ausrollen kann.
      Bei Treiber- und Firmware-Sicherheitsupdates ist das aber keineswegs sicher. Solche Updates müssen oft von einem vorgelagerten Zulieferer kommen, und der kann bereit sein, das Problem zu beheben – oder eben nicht. Kleinere Marken verkaufen oft günstige Android-Geräte und liefern überhaupt keine Updates.

  • Etwas damit verwandt: Ich frage mich, ob der Anteil öffentlich gemachter Exploits in letzter Zeit tatsächlich gestiegen ist oder ob das nur häufiger in den Nachrichten auftaucht, weil AI als Angriffs- und Verteidigungstool im Security-Bereich gerade so viel Aufmerksamkeit bekommt.
    Es wirkt, als käme alle zwei Tage etwas Neues zu Linux, Windows, Mobilgeräten oder irgendeinem weit verbreiteten Tool heraus.

    • Wenn man Teil 1 zwischen den Zeilen liest, wurde der problematische Code wegen einer AI-Funktion eingeführt, und den Exploit hat ein Mensch gefunden.
      https://projectzero.google/2026/01/pixel-0-click-part-1.html
      Also erzeugt AI mehr Bugs, und Menschen müssen sie wieder herausfischen.
    • Ich habe das letztes Wochenende selbst analysiert: 2024 wurden ungefähr 100 CVEs pro Tag veröffentlicht. Im April wurde ein Wert von rund 200 pro Tag erreicht.
      Wenn man vor 2023 zurückgeht, lag die Verdopplungszeit bei veröffentlichten CVEs bei etwa 4 bis 4,5 Jahren, seitdem aber eher bei rund 2 Jahren. Es ist also eindeutig stark angestiegen.
    • Leuten zufolge, die Open-Source-Sicherheitsbugs verwalten, ist die Zahl der Meldungen deutlich gestiegen. Zunächst waren die meisten fast schon gefälschte niedrigwertige Meldungen, inzwischen gibt es aber auch deutlich mehr tatsächlich valide Reports.
    • Reine Vermutung, ich bin kein Sicherheitsforscher, aber AI scheint sowohl die Menge an schlecht gebauter, ausnutzbarer Angriffsfläche zu erhöhen als auch die Arbeitsgeschwindigkeit von Sicherheitsforschern zu steigern.
      Anders gesagt: Richtig eingesetzt ist es großartig, falsch eingesetzt wirklich übel.
    • Ich habe in den letzten Wochen mehreren Vendoren weit verbreiteter Tools einige ziemlich ernste Probleme gemeldet, und es war schwieriger als sonst, dafür Anerkennung zu bekommen.
      Ich habe gehört, dass die Response-Teams durch die Flut an Meldungen überlastet sind.

  • Ich würde gern wissen, ob mein Eindruck stimmt. Ich habe den folgenden exakten Prompt in gpt 5.5 xhigh eingegeben.

    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; }

    Auch ohne Websuche hat es das Problem präzise erkannt. Ich würde das gern umfassender testen, etwa indem ich nicht nur eine einzelne Funktion, sondern ganze Codebase-Blöcke in den Prompt gebe. Das sieht nach potenzieller Fähigkeit zum Aufspüren von Security-Exploits aus. Dann frage ich mich aber, wie so etwas überhaupt veröffentlicht werden konnte. Ich weiß, dass das nur ein Spielzeugbeispiel ist, aber ich würde gern mehr darüber lernen.

    • Das ist kein fairer Test. Auch wenn der Prompt nicht ausdrücklich sagt, dass ein Bug gefunden werden soll, lenkt er das Modell ziemlich stark in diese Richtung.
      Das ist im Grunde derselbe Einwand, der in einem Thread aufkam, in dem behauptet wurde, das aktuelle Modell sei so gut wie mythos.
    • Anekdotisch: Ich habe fragnesia.c und später den Patch zum Beheben des Problems hineingeworfen. Ich habe keine völlig neue Schwachstelle gefunden, aber ich glaube, ich habe zwei neue Wege gefunden, denselben zugrunde liegenden Bug auszunutzen.
      Dafür, dass das von einem Idioten wie mir mit nur einem Claude-Abo ausprobiert wurde, ist das ziemlich beeindruckend.
    • Daraus allein lässt sich nicht ableiten, ob das in der Praxis zur Schwachstellensuche taugt. Denn wir wissen nicht, wie viele False Positives herauskommen würden, wenn man es auf einen kompletten Codebestand loslässt.
      Anders gesagt könnte es https://en.wikipedia.org/wiki/Base_rate_fallacy sein.
    • Ich frage mich, woher man weiß, dass keine Websuche stattgefunden hat.
    • Ich habe den Code in claude Opus 4.7 ohne Internetzugang eingefügt und nur darum gebeten zu erklären, was die Funktion tut, und dabei wurde auch der Bug benannt. Ich habe nicht gesagt, dass ein Bug gefunden werden soll.

      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:
        Wenn wir in ein Zeitalter kommen, in dem Bots die PRs aller Open-Source-Projekte sofort nach Veröffentlichung scannen können, dann werden 70-Tage-Releasezyklen schnell nicht mehr ausreichen, um eine breite Ausnutzung von Exploits zu verhindern.

  • Ein großartiger Bugreport. Ich bin überhaupt kein Kernel-Experte und habe mich damit vor über zehn Jahren nur ein wenig beschäftigt, konnte aber trotzdem folgen und verstehen, was passiert ist.
    Dass das ein wirklich schwerwiegender Bug war und dass die Suche danach offenbar gar nicht so viel Arbeit war, macht mir Angst davor, welche anderen Risiken noch verborgen sein könnten. Und weil in letzter Zeit viele Sicherheitsprobleme mit AI gefunden werden, bringt mich dieser Bericht zu zwei Gedanken: Fachwissen ist weiterhin extrem wertvoll, und je spezieller die Nische, desto wertvoller. Außerdem gibt es noch viele Nischen, die AI bislang nicht dominiert.

  • Ich frage mich, was aus iPhone-Jailbreaks geworden ist. Ich habe schon ziemlich lange nichts mehr dazu gesehen – was passiert da? Ich frage mich, ob ich etwas verpasst habe oder ob es tatsächlich nichts mehr gibt.
    Beeindruckend ist es auf jeden Fall, was Apple da macht, aber ich würde gern wissen, ob es nach der aktuellen Entwicklung nur eine Frage der Zeit ist oder ob sich tatsächlich grundlegend etwas verändert hat.

    • Apples Sicherheitslage ist dank Lockdown Mode, Memory Tagging und Secure Allocator deutlich besser als die von Android.
      Einiges dazu gibt es hier: https://security.apple.com/blog/memory-integrity-enforcement...
    • Heutzutage sind Exploits, die einen Neustart überleben, fast unmöglich. Und Exploits, die einen Jailbreak ermöglichen, brauchen inzwischen eine komplette Exploit-Kette, sind entsprechend wertvoll und werden gepatcht, sobald sie öffentlich werden.
      Deshalb ist so etwas wie die frühere iPhone-Jailbreak-Szene heute nicht mehr möglich.
    • Mich hat immer genervt, dass „Jailbreak“ nicht demselben Maß an Prüfung unterliegt wie Software-Schwachstellen auf anderen Plattformen.

  • Gibt es irgendwelche Belege dafür, welchen Einfluss AI auf das Geschäft von Firmen wie NSO hatte? Ich frage mich, ob sie dadurch überflüssig werden oder eher massiv aufgewertet werden.

    • Ich kenne keine Details, aber ich vermute, dass AI das Spielfeld stark verändert hat und viel „Kapital“ in Form von 0-Days verschwunden ist.
      Wenn das stimmt, wären das gute Nachrichten für alle außer NSO und ähnlichen Firmen.

  • Ich hatte schon einmal ein ähnliches Problem. Die Lösung wirkt vernünftig, aber bei der behaupteten Leistungsverbesserung bin ich skeptisch.

  • V4L2-Verbesserungen zur Unterstützung von Hardware-Video-Decoding warteten lange auf die Aufnahme, und inzwischen scheinen sie im Mainline-Kernel gelandet zu sein.
    Offenbar wollten die Leute nicht so lange warten.

  • Ich finde es überraschend, dass sogar Project Zero Bugs bei Android über die offiziellen Kanäle melden und sich dann mit der Android-VRP-Schweregradklassifizierung herumschlagen muss.
    Ich dachte immer, sie könnten einfach ins Android-Büro gehen und jemandem persönlich erklären, warum der Bug wichtig ist.

    • Wenn sich der „normale“ Weg zu schmerzhaft angefühlt hat, hätte Project Zero vermutlich als Nächstes versucht, genau diesen Prozess zu verbessern.
    • Das setzt voraus, dass Android auf Project Zero hört.