GrapheneOS behebt Android-VPN-Leck, das Google nicht patchen wollte

 (cyberinsider.com)
1 Punkte von GN⁺ 6 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • GrapheneOS hat in einem neuen Update eine VPN-Bypass-Schwachstelle behoben, durch die die echte IP-Adresse trotz aktiviertem „Always-On VPN“ und „Block connections without VPN“ unter Android offengelegt werden konnte
  • Die Schwachstelle entstand durch die Funktion zum Beenden von QUIC-Verbindungen im Android-16-Netzwerk-Stack; eine normale App konnte mit nur Standardberechtigungen einen UDP-Payload bei system_server registrieren
  • Wenn der UDP-Socket der App zerstört wurde, sendete der privilegierte system_server den gespeicherten Payload direkt über die physische Netzwerkschnittstelle statt durch den VPN-Tunnel und umging so den VPN-Sperrschutz
  • Google stufte das Problem als „Won’t Fix (Infeasible)“ und „NSBC“ ein und hielt an seiner Position fest, dass es die Kriterien für Android-Sicherheitswarnungen nicht erfüllt
  • GrapheneOS hat in Release 2026050400 die „registerQuicConnectionClosePayload optimization“ deaktiviert; enthalten sind außerdem die Android-Sicherheitspatches vom Mai 2026, Verbesserungen an hardened_malloc, Linux-Kernel-Updates und ein Backport-Fix für libpng CVE-2026-33636

Funktionsweise der Schwachstelle

  • Laut Yusufs technischer Analyse ermöglichte die anfällige API einer normalen App mit nur den automatisch gewährten Berechtigungen INTERNET und ACCESS_NETWORK_STATE, beliebige UDP-Payloads bei system_server zu registrieren
  • Wurde anschließend der UDP-Socket der App zerstört, übertrug der privilegierte Android-Prozess system_server den gespeicherten Payload direkt über die physische Netzwerkschnittstelle des Geräts statt durch den VPN-Tunnel
  • Da system_server mit erweiterten Netzwerkberechtigungen arbeitet und von VPN-Routing-Beschränkungen ausgenommen ist, umging dieses Paket den VPN-Sperrschutz von Android vollständig
  • Der Sicherheitsforscher lowlevel/Yusuf demonstrierte die Schwachstelle auf einem Pixel 8 mit Android 16, bei dem Proton VPN und der Android-Sperrmodus gleichzeitig aktiviert waren
  • Die App leakte dabei die echte öffentliche IP-Adresse des Geräts an einen Remote-Server, obwohl der VPN-Schutz vollständig aktiv war

Ursache und Googles Umgang damit

  • Google führte die Funktion ein, damit Anwendungen QUIC-Sitzungen sauber beenden können, wenn ein Socket unerwartet zerstört wird
  • Die Implementierung akzeptierte jedoch beliebige Payloads und prüfte nicht, ob es sich dabei um einen legitimen QUIC CONNECTION_CLOSE-Frame handelte
  • Außerdem prüfte die Implementierung ursprünglich nicht, ob die Anwendung auf reinen VPN-Verkehr beschränkt war
  • Der Forscher meldete das Problem an das Android-Sicherheitsteam, doch Google klassifizierte es als „Won’t Fix (Infeasible)“ und „NSBC“ (Not Security Bulletin Class)
  • Google kam zu dem Schluss, dass das Problem die Kriterien für die Aufnahme in Android-Sicherheitswarnungen nicht erfüllt
  • Der Forscher bat um eine Neubewertung mit dem Hinweis, dass jede App mit Standardberechtigungen identifizierbare Netzwerkdaten leaken könne, doch Google hielt an seiner Position fest und genehmigte die Offenlegung am 29. April

GrapheneOS-Update und Gegenmaßnahmen

  • GrapheneOS ist ein vor allem für Google-Pixel-Geräte entwickeltes, auf Android basierendes Betriebssystem mit Fokus auf Datenschutz und Sicherheit und richtet sich an Nutzer, die stärkeres Application Sandboxing, Exploit-Abwehr und weniger Abhängigkeit von Google-Diensten möchten
  • GrapheneOS hat in Release 2026050400 die betreffende Optimierung vollständig deaktiviert und verhindert damit das VPN-Leck
  • Yusuf erklärte, dass GrapheneOS den Fix in weniger als einer Woche ausgeliefert habe
  • Neben der Behebung des VPN-Lecks enthält die neueste Version auch das vollständige Android-Sicherheitspatch-Level vom Mai 2026
  • Das Update umfasst mehrere Verbesserungen an hardened_malloc, Linux-Kernel-Updates über die Android-Zweige 6.1, 6.6 und 6.12 hinweg sowie einen Backport-Fix für CVE-2026-33636 in libpng
  • Ebenfalls enthalten sind ein neuer Vanadium-Browser-Build und erweiterte Einschränkungen für Dynamic Code Loading
  • Normale Android-Nutzer können das Problem vorübergehend abmildern, indem sie per ADB das DeviceConfig-Flag close_quic_connection deaktivieren
  • Diese Umgehungslösung erfordert Entwicklerzugriff
  • Falls Google das Feature-Flag in einem künftigen Update entfernt, lässt sich diese Abmilderung möglicherweise nicht dauerhaft beibehalten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 6 시간 전
Hacker-News-Kommentare

  • Wenn system_server mit hohen Netzwerkrechten läuft und von den VPN-Routing-Beschränkungen ausgenommen ist, dann ist ein VPN unter Android faktisch kein VPN mehr, oder?
    Unabhängig von diesem Bug frage ich mich, ob andere abgeschottete Betriebssysteme auf die gleiche Weise funktionieren.

    • Bei iOS ist es genauso, und soweit ich weiß, braucht man zum Umgehen davon eine Enterprise-Lizenz für mehr als 250 Geräte.
      Auch Mullvad und andere haben dieses Problem schon vor langer Zeit behandelt.
    • Begriffe wie „private“ oder „trust“ haben in der Computerwelt und in menschlichen Konventionen unterschiedliche Bedeutungen.
      Es macht mir Sorgen, dass Leute Wörter mit gleicher Schreibweise sehen, den Kontextunterschied nicht erkennen und so menschliches Vertrauen fälschlich auf das Trust-Modell von Computern übertragen.
    • Auch bei macOS gab es Fälle, in denen eigene Apps das Always-on-VPN umgehen konnten.
      Ich weiß allerdings nicht, ob es dabei Schwachstellen oder Lücken gab, mit denen sich Traffic direkt an beliebige Ziele senden ließ.
    • Ich frage mich, wie schwierig es ist, system_server und andere Umgehungspfade zu beheben.

  • Ähnlich wie bei Manifest V3 liegt es nicht im Interesse von Google, das Ausspähen zu verhindern.
    Solche Einschränkungen schaden dem Geschäftsmodell.

  • Der technisch ernste Aspekt dieses Problems ist, dass das Leak aus dem privilegierten Prozess system_server stammt.
    Der eigene Lockdown-Modus von Android verspricht ausdrücklich, dass kein Traffic das VPN umgeht. Wenn das System selbst Pakete über physische Interfaces sendet, dann wird dieses Versprechen nicht im User Space, sondern auf Kernel-Ebene gebrochen, daher ist es schwer zu behaupten, das sei „kein Fall für ein Security Advisory“.

  • Wenn Google die Offenlegung am 29. April erlaubt hat, überrascht es mich, dass man das Embargo trotzdem eingehalten und die Verteilung des Fixes bis Mai verschoben hat.
    Ich weiß nicht, warum man es nicht sofort veröffentlicht hat.

    • Wahrscheinlich wollte man die Beziehung zu Google als Vendor nicht beschädigen.
      Ob man es mag oder nicht: GrapheneOS hängt von Android ab, das Google kontrolliert.

  • Ich verstehe, dass es schlechte geschäftliche Gründe dafür gibt, aber ich weiß nicht, wie man sein Gesicht wahren kann, wenn man VPN-Leaks nicht als Sicherheitsproblem einstuft.

    • Das hängt davon ab, welche Rolle man einem VPN zuschreibt.
      Ursprünglich waren VPNs dazu da, über andere Netzwerke auf ein privates Netz oder ein Firmennetz zuzugreifen, also etwa für Verbindungen zwischen Büros oder von zu Hause ins Büro. Erst später wurden sie zu einer Art Security-Tool.
      Wenn man den VPN-Code nur als „das Handy soll über 5G den Bürodrucker erreichen können“ betrachtet, dann könnte es ein kleiner Bug sein, bei dem QUIC-Verbindungen nicht sauber geschlossen werden. Wenn man es dagegen als „dieser WireGuard-Tunnel muss meine Identität unter allen Umständen schützen“ oder als „er muss eine exakte Kopie allen Internet-Traffics sein“ betrachtet, dann ist es ein großes Problem.
      Ich denke nicht, dass Android-VPNs oder eigentlich irgendein VPN je als Privacy- oder Security-Maßnahme entworfen wurden, besonders nicht gegen Apps, die Code auf dem Gerät ausführen können; außerdem führt das Gerät selbst viele Netzwerkinteraktionen aus, einschließlich im Modem-Chip.
      Dass Google den Bug geschlossen hat, war ein Fehler, aber ich kann nachvollziehen, warum man ihn im Bug-Bounty-Programm nicht als Security-Bug wertet.
    • Diese Frage kann man nur stellen, wenn man annimmt, dass überhaupt noch Gesicht zu wahren ist.
    • Aus Googles Sicht ist das kein Bug, sondern ein Feature.
      Google ist ein Werbeunternehmen und ein Auftragnehmer für offensive Operationen, daher nützt es aus beiden Gründen, wenn VPN-Nutzer Pakete leaken.
    • Dafür werden sie bezahlt.
    • Ich glaube nicht, dass man bei Google arbeiten kann, wenn man unerwünschte Offenlegung privater Daten als Sicherheitsproblem betrachtet.

  • Das ist ähnlich wie wenn Meta Ende-zu-Ende-Verschlüsselung entfernt.
    Es kommt eher einem „Nein, wir wollen alles sehen, was du sagst und tust“ gleich.

  • Ich frage mich, wie man am besten an ein GrapheneOS-Handy kommt.
    Ich wollte GrapheneOS ausprobieren, aber ein Pixel tatsächlich zu kaufen, fühlt sich zögerlich an. Selbst gebraucht kostet meist schon die „a“-Serie über 300 Dollar, wenn man nicht mehrere Generationen zurückgeht. Außerdem ist fraglich, ob sich der Bootloader entsperren lässt. 449 Dollar für ein neues Pixel 10a auszugeben, fällt mir im Moment noch schwer.

    • Das hilft jetzt vielleicht nicht, aber GrapheneOS hat kürzlich eine Partnerschaft mit Motorola angekündigt, also könnte in etwa einem Jahr die Unterstützung für einige Motorola-Geräte anlaufen.
      Zur Referenz: Ich habe ein Pixel 10a zum Start von Google Fi für ungefähr 300 Dollar gekauft.
    • Ein Pixel 10a sollte man besser nicht kaufen.
      Das Pixel 9a ist fast dasselbe Gerät und wird noch neu verkauft.
    • Ich würde die Pixel-8-Serie oder neuer empfehlen.
      Am sichersten ist es, neu in einem normalen Laden oder im Google Store zu kaufen, nicht in einem Carrier-Shop.
      Gebraucht ist es wegen Problemen mit OEM-Unlock fast ein Glücksspiel, also sollte man auf gute Rückgaberegeln achten und vor dem Kauf prüfen, ob OEM-Unlock zugänglich ist.
    • Ich habe in einem anderen Thread geantwortet: https://news.ycombinator.com/item?id=48076522
      Im Grunde sollte man ein Pixel ab Pixel 6 kaufen, bei dem Bootloader-Unlock sicher möglich ist. Da das Pixel 6 aber bald nur noch Mindest-Support bekommt, würde ich eher Pixel 7 oder neuer empfehlen. Bei den meisten Gebrauchtgeräten ist Bootloader-Unlock nicht möglich.
      Also am besten direkt bei Google kaufen, oder ein eBay-Gerät nehmen, auf dem bereits GrapheneOS/CalyxOS/LineageOS installiert ist, oder ein Gerät kaufen, bei dem der Verkäufer ausdrücklich sagt, dass Bootloader-Unlock möglich ist.
      Persönlich habe ich die Erfahrung gemacht, dass es wenig bringt, Verkäufer nach dem Bootloader-Status zu fragen, wenn sie es nicht schon selbst erwähnt haben. Fast niemand will das Prüfverfahren durchlaufen, die Antwort ist meist eher „geht nicht“, oder sie missverstehen die Frage und antworten nur „entsperrtes Handy“, oder sie sind solche Fragen schlicht leid.
    • Man kann auch einfach noch etwas warten.
      Es läuft Arbeit daran, mehr Handy-Hardware zu unterstützen, und welche Marke es sein würde, war eine Zeit lang Gegenstand von Spekulationen.

  • Ich habe mir günstig ein gebrauchtes Pixel 6 gekauft, um GrapheneOS auszuprobieren, aber es hat mir nicht besonders gefallen.
    Die User Experience von LineageOS fühlt sich deutlich besser an. Die Struktur des Paketmanagers ist seltsam verschachtelt wie russische Puppen. Der standardmäßige „App Store“ enthält nur ein paar Basisprogramme, darunter Accrescent als weiteren Paketmanager, aber dort gibt es immer noch viel zu wenige Apps, sodass man noch einen weiteren Paketmanager braucht. Auf der GrapheneOS-Seite scheint man Obtainium gegenüber F-Droid zu bevorzugen, was mir ebenfalls wie eine merkwürdige Entscheidung vorkommt.
    Ich bevorzuge einen vollständig Open-Source-Paketmanager deutlich, und es hat echten Wert, statt GitHub-Paketen zu vertrauen lieber extern aus den Quellen zu bauen und das möglichst reproduzierbar. Das Sicherheitsmodell von GrapheneOS wirkt auf mich merkwürdig zentralisiert. Die berichteten Privacy- und Security-Vorteile lassen sich schwer selbst beurteilen.

    • Man kann F-Droid einfach direkt herunterladen.
      Ich verstehe nicht, warum man so darauf fixiert ist, unbedingt einen festgelegten und vorinstallierten App Store haben zu müssen.
      Einen App Store zu betreiben ist fast so viel Arbeit wie einen Android-Fork zu pflegen, und da es ohnehin schon F-Droid, Play Store mit Aurora Store, Obtainium und andere Optionen gibt, kann man den GrapheneOS-Entwicklern schwer vorwerfen, dass sie dafür nicht enorme zusätzliche Arbeit investieren.
    • Der App Store ist eher ein minimaler Ausgangspunkt, um zu entscheiden, woher man Apps beziehen will.
      Im Auslieferungszustand hat man nur den Launcher und das minimale Betriebssystem, und für Minimalisten ist das alles, was sie brauchen.
      Wer mehr braucht, entscheidet selbst, wohin er geht. Ich würde das Befähigung des Nutzers nennen; du nennst es offenbar Unbequemlichkeit. Dann ist dieses Betriebssystem vielleicht einfach nicht das Richtige für dich.
    • Nur weil Software frei oder Open Source ist, ist sie nicht automatisch sicherer oder privater.
      „Open Source“ ist im Kern erst einmal nur ein Lizenzbegriff.
      Der „App Store“ von GrapheneOS dient dazu, die grundlegendsten Apps für den alltäglichen Einsatz bereitzustellen. Accrescent wird dort verteilt, weil es als echter App-Store die Security-Baseline von Android einhält, F-Droid und Aurora Store tun das nicht.
      Ich sehe keinen großen Wert darin, dass Dritte wie bei F-Droid Apps bauen, um bösartiges Verhalten zu prüfen. Solche Prüfungen sind nicht sehr verlässlich und wurden auch schon umgangen. Das ist einer der Gründe, warum WireGuard nicht mehr bei F-Droid ist. Wenn du einer App nicht genug vertraust, um sie direkt vom Entwickler zu beziehen, solltest du sie eigentlich gar nicht verwenden.
      Die Privacy- und Security-Vorteile von GrapheneOS sind absichtlich so gestaltet, dass sie für den Durchschnittsnutzer fast unsichtbar bleiben. Beispiele sind ein gehärteter Speicher-Allocator und Memory Tagging Extensions zum Verhindern von Memory-Corruption-Bugs, sowie die Möglichkeit, sandboxed Google Play zu installieren, damit man Google-Dienste nutzen kann, ohne Google die volle Kontrolle über das Gerät zu geben.
    • GrapheneOS erbt die Benutzeroberfläche des Android Open Source Project, auf dem auch das Standardbetriebssystem der Pixel-Geräte und viele Android-Forks anderer Hersteller basieren.
      Der App Store von GrapheneOS existiert, um die von AOSP geforderte Rolle als primärer App Store zu erfüllen. Außerdem dient er dazu, First-Party-Apps getrennt von Betriebssystem-Updates zu aktualisieren und in manchen Fällen Apps zu spiegeln.
      Accrescent wird gespiegelt, weil es Privacy und Security in den Mittelpunkt stellt. Es ist derzeit noch im Alpha-Stadium und App-Einreichungen sind geschlossen, sollen aber bald geöffnet werden.
      Google Play wird gespiegelt, um Kompatibilität mit Apps zu ermöglichen, die Google Play benötigen, und um Zugriff auf den Play Store zu bieten.
      Die GrapheneOS-Community bevorzugt Obtainium, weil man dort vom Entwickler signierte Apps von Orten wie GitHub beziehen kann. F-Droid signiert und baut fast alle Apps im Haupt-Repository mit veralteter Build-Infrastruktur und schwacher Governance.
      Das Sicherheitsmodell von GrapheneOS übernimmt das AOSP-Sicherheitsmodell und härtet es zusätzlich.
    • Ich freue mich wirklich, dass CalyxOS wieder aktiver wird.
      GrapheneOS hat viele beeindruckende technische Umsetzungen, aber bei Calyx scheint manches einfacher und näher an Stock Android gelöst zu sein.

  • GrapheneOS sagt, es habe zur „Behebung des VPN-Leaks“ die Optimierung registerQuicConnectionClosePayload deaktiviert und damit den Angriffsvektor auf unterstützten Pixel-Geräten praktisch neutralisiert.
    Mit anderen Worten: GrapheneOS hat das Leak „behoben“, indem es die Optimierung abgeschaltet hat.
    Früher auf HN wurde QUIC gelobt, und Kommentare, die fragten, wem QUIC eigentlich am meisten nützt, wurden heruntergevotet. Die Nutzung von QUIC mag im Interesse anderer liegen, aber für mich stimmt der Trade-off nicht, daher blockiere ich QUIC-Traffic.
    QUIC ist in Software, die Google verteilt, etwa auf Android, teils standardmäßig aktiviert, und in manchen Fällen lässt es sich nicht einmal abschalten.

    • Auch unter GrapheneOS funktioniert QUIC selbst weiterhin ganz normal.
      Entfernt wurde nur die Möglichkeit für Apps, das Betriebssystem zu bitten, QUIC-Verbindungen automatisch zu schließen, etwa wenn die App abstürzt. Aus Serversicht ist das eine Optimierung, weil Verbindungen sonst offen bleiben, Ressourcen binden und erst nach einem Idle-Timeout beendet werden; aus Clientsicht ist das keine Optimierung.
      GrapheneOS hat daneben noch etwa fünf weitere VPN-Leaks behoben und arbeitet an zusätzlichen Fixes. Die aktuelle VPN-Implementierung von Android ist ein VPN pro Profil, aber Profile verwenden noch keinen eigenen Netzwerk-Namespace, und deshalb müssen der DNS-Resolver und verschiedene zentrale Dienste die VPN-Unterstützung korrekt handhaben, was Leaks begünstigt.
      Künftig will man die VPN-Architektur verbessern, damit sie sehr widerstandsfähig gegen Leaks wird. Geplant ist auch Unterstützung dafür, Apps oder App-Gruppen in virtuellen Maschinen auszuführen, was stärkeren Schutz bieten könnte.
    • Hier wurde lediglich der Pfad zum sauberen Schließen von QUIC-Verbindungen über einen ungeeigneten oder missbrauchbaren Aufruf exponiert; GrapheneOS hat nicht QUIC insgesamt deaktiviert.
      QUIC selbst ist großartig, und das hier ist eher ein Feature des Überwachungsbetriebssystems Google Android als ein Feature des Protokolls.
      Außerdem funktionierte es bei meinen Tests selbst auf Betriebssystemversionen vor dem neuesten Release nicht korrekt.

  • Stock Android ist Spyware und Adware.
    Früher hätte man solche Software als bösartig bezeichnet und entfernt, heute ist sie einfach der Standard.

    • Alle stimmen dem zu, aber ich weiß nicht, was die Lösung sein soll.
      Da man weiß, dass es 99 % der Nutzer nicht interessiert, kann man realistisch nur bei den Handyherstellern Druck ausüben. Es fühlt sich hilflos an, weil ich keinen Einfluss auf irgendjemanden mit nennenswerter Macht in diesem Bereich habe.