GrapheneOS corrige une fuite VPN d’Android que Google a refusé de corriger

• GrapheneOS a corrigé dans une nouvelle mise à jour une vulnérabilité de contournement du VPN qui pouvait exposer l’adresse IP réelle même lorsque « Always-On VPN » et « Block connections without VPN » étaient activés sur Android
• La faille provenait de la fonction de fermeture de connexion QUIC dans la pile réseau d’Android 16, et une application ordinaire pouvait enregistrer une charge utile UDP dans system_server avec uniquement des autorisations standard
• Lorsque le socket UDP de l’application était détruit, le system_server privilégié envoyait directement la charge utile enregistrée via l’interface réseau physique au lieu du tunnel VPN, contournant ainsi la protection de verrouillage du VPN
• Google a classé le problème comme « Won’t Fix (Infeasible) » et « NSBC », estimant qu’il ne répondait pas aux critères des avis de sécurité Android, et a maintenu sa position
• Dans la release 2026050400, GrapheneOS a désactivé registerQuicConnectionClosePayload optimization ; la mise à jour inclut aussi le correctif de sécurité Android de mai 2026, des améliorations de hardened_malloc, des mises à jour du noyau Linux et un correctif rétroporté pour libpng CVE-2026-33636

---

Fonctionnement de la vulnérabilité

• Selon l’analyse technique de Yusuf, l’API vulnérable permettait à une application ordinaire ne disposant que des autorisations accordées automatiquement INTERNET et ACCESS_NETWORK_STATE d’enregistrer une charge utile UDP arbitraire dans system_server
• Ensuite, lorsque le socket UDP de l’application était détruit, le processus system_server privilégié d’Android transmettait directement la charge utile enregistrée via l’interface réseau physique de l’appareil, et non par le tunnel VPN
• Comme system_server fonctionne avec des privilèges réseau élevés et est exempté des restrictions de routage du VPN, ce paquet contournait complètement la protection de verrouillage VPN d’Android
• Le chercheur en sécurité lowlevel/Yusuf a démontré la vulnérabilité sur un Pixel 8 sous Android 16 avec Proton VPN et le mode verrouillage Android activés simultanément
• L’application concernée divulguait l’adresse IP publique réelle de l’appareil vers un serveur distant, même avec la protection VPN entièrement activée

Cause et traitement par Google

• Google a introduit cette fonction afin de permettre aux applications de fermer proprement les sessions QUIC lorsque des sockets étaient détruits de manière inattendue
• L’implémentation acceptait toutefois des charges utiles arbitraires sans vérifier s’il s’agissait bien de trames QUIC CONNECTION_CLOSE légitimes
• Elle ne vérifiait pas non plus à l’origine si l’application était limitée à un trafic exclusivement via VPN
• Le chercheur a signalé le problème à l’équipe sécurité Android, mais Google l’a classé comme « Won’t Fix (Infeasible) » et « NSBC » (Not Security Bulletin Class)
• Google a estimé que le problème ne répondait pas aux critères d’inclusion dans les avis de sécurité Android
• Le chercheur a demandé un réexamen, arguant que n’importe quelle application pouvait divulguer des informations réseau identifiables avec de simples autorisations standard, mais Google a maintenu sa position et a autorisé la divulgation le 29 avril

Mise à jour et mesures d’atténuation de GrapheneOS

• GrapheneOS est un système d’exploitation basé sur Android, centré sur la confidentialité et la sécurité, principalement développé pour les appareils Google Pixel, et utilisé par des personnes recherchant un sandboxing applicatif plus strict, une meilleure atténuation des exploits et une moindre dépendance aux services Google
• Dans la release 2026050400, GrapheneOS a complètement désactivé cette optimisation afin d’empêcher la fuite VPN
• Yusuf a indiqué que GrapheneOS avait déployé le correctif en moins d’une semaine
• En plus du correctif de fuite VPN, la dernière release inclut l’ensemble du niveau de correctif de sécurité Android de mai 2026
• La mise à jour comprend aussi plusieurs améliorations de hardened_malloc, des mises à jour du noyau Linux sur les branches 6.1, 6.6 et 6.12 d’Android, ainsi qu’un correctif rétroporté de CVE-2026-33636 pour libpng
• Une nouvelle version du navigateur Vanadium et des restrictions étendues sur le Dynamic Code Loading sont également fournies
• Les utilisateurs d’Android standard peuvent atténuer temporairement le problème via ADB en désactivant le drapeau DeviceConfig close_quic_connection
• Cette solution de contournement nécessite un accès développeur
• Si Google supprime ce drapeau de fonctionnalité dans une future mise à jour, cette mesure d’atténuation pourrait ne pas rester disponible

[GN⁺]

Avis sur Hacker News

• Si system_server fonctionne avec des privilèges réseau élevés et est exclu des restrictions de routage du VPN, alors sur Android, un VPN n’est en fait pas vraiment un VPN
  Indépendamment de ce bug, je me demande si d’autres systèmes d’exploitation verrouillés fonctionnent de la même manière

  • iOS aussi, et d’après ce que je sais, pour contourner cela il faut une licence enterprise pour plus de 250 appareils
    Mullvad et d’autres ont abordé ce problème il y a longtemps
  • Des termes comme « private » ou « trust » n’ont pas le même sens dans l’informatique et dans les usages humains
    Ce qui m’inquiète, c’est que les gens voient des mots orthographiés de la même façon sans percevoir la différence de contexte, et étendent à tort la confiance humaine au modèle de confiance informatique
  • Il y a aussi eu des cas où macOS permettait à ses propres applications de contourner un VPN permanent
    Je ne sais pas s’il y avait une vulnérabilité ou une faille permettant d’envoyer directement du trafic vers une destination arbitraire
  • Je me demande à quel point il est difficile de corriger system_server et les autres voies de contournement

• Comme pour Manifest V3, empêcher l’espionnage ne va pas dans le sens des intérêts de Google
  Ce genre de limitation nuit à son modèle économique

• La raison technique pour laquelle ce problème est grave, c’est que la fuite se produit dans system_server, un processus privilégié
  Le mode de verrouillage natif d’Android promet explicitement qu’aucun trafic ne contournera le VPN. Si le système lui-même envoie des paquets via l’interface physique, cette promesse est rompue au niveau du noyau, pas de l’espace utilisateur, donc il est difficile de dire que ce n’est « pas du niveau d’un avis de sécurité »

• Si Google a autorisé la divulgation le 29 avril, il est surprenant que l’embargo ait quand même été respecté et que la diffusion du correctif ait été repoussée à mai
  Je ne sais pas pourquoi cela n’a pas été publié immédiatement

  • C’était probablement pour ne pas nuire à la relation avec Google en tant que fournisseur
    Qu’on aime ou non, GrapheneOS dépend d’Android contrôlé par Google

• Je comprends qu’il y ait de mauvaises raisons commerciales, mais je ne vois pas comment on peut garder sa dignité en classant une fuite VPN comme un problème non lié à la sécurité

  • Cela dépend de la manière dont on considère le rôle d’un VPN
    À l’origine, les VPN servaient à accéder à un réseau privé ou professionnel via un autre réseau, par exemple pour relier des bureaux entre eux ou se connecter au bureau depuis chez soi. Ce n’est que plus tard qu’ils sont devenus une sorte d’outil de sécurité
    Si on considère le code VPN comme quelque chose du type « il suffit que le téléphone puisse accéder à l’imprimante du bureau en 5G », alors cela peut n’être qu’un petit bug où une connexion QUIC ne se ferme pas correctement. En revanche, si on pense « ce tunnel WireGuard doit protéger mon identité quoi qu’il arrive » ou « il doit être une copie exacte de tout le trafic échangé sur Internet », alors c’est un gros problème
    Je ne pense pas qu’Android VPN, ni en pratique aucun VPN, ait jamais été conçu comme un mécanisme de confidentialité ou de sécurité. C’est encore moins vrai face à des applications capables d’exécuter du code sur l’appareil, sachant que l’appareil lui-même a divers échanges réseau, y compris dans la puce modem. Le fait que Google ait fermé le bug était une erreur, mais je peux comprendre pourquoi son programme de bug bounty ne le considère pas comme un bug de sécurité
  • Cette question suppose qu’il y ait une dignité à préserver
  • Du point de vue de Google, ce n’est pas un bug mais une fonctionnalité
    Google est une régie publicitaire et un prestataire de contrats offensifs, donc le fait que les utilisateurs de VPN laissent fuiter des paquets lui profite dans les deux cas
  • C’est précisément pour cela qu’ils sont payés
  • Je ne pense pas qu’on puisse travailler chez Google tout en considérant la divulgation non souhaitée de données personnelles comme un problème de sécurité

• C’est comparable au fait que Meta supprime le chiffrement de bout en bout
  On est proche de « non, nous voulons voir absolument tout ce que tu dis et fais »

• Je me demande quelle est la meilleure façon d’obtenir un téléphone GrapheneOS
  J’aimerais essayer GrapheneOS, mais j’hésite à acheter réellement un Pixel. Même d’occasion, les modèles de la série “a” dépassent souvent 300 dollars, à moins de remonter de plusieurs générations. Et il y a aussi la question de savoir si le déverrouillage du bootloader est possible. J’ai encore du mal à mettre 449 dollars dans un Pixel 10a neuf

  • Cela ne t’aidera peut-être pas tout de suite, mais GrapheneOS a récemment annoncé un partenariat avec Motorola, donc d’ici un an environ, certains appareils Motorola devraient commencer à être pris en charge
    Pour info, j’ai acheté un Pixel 10a autour de 300 dollars au lancement de Google Fi
  • Mieux vaut ne pas acheter un Pixel 10a
    Le Pixel 9a est quasiment le même appareil et il est encore vendu neuf
  • Je recommande la série Pixel 8 ou ultérieure
    Le plus sûr est d’acheter neuf dans un magasin classique ou sur le Google Store, pas chez un opérateur
    L’occasion est presque un pari à cause des problèmes de déverrouillage OEM, donc il faut vérifier la politique de retour et s’assurer avant l’achat que l’option de déverrouillage OEM est bien accessible
  • J’ai répondu dans un autre fil : https://news.ycombinator.com/item?id=48076522
    En gros, il faut acheter un Pixel 6 ou plus récent dont le déverrouillage du bootloader est garanti. Cela dit, le Pixel 6 n’aura bientôt plus qu’un support minimal, donc je recommande plutôt un Pixel 7 ou ultérieur. La plupart des appareils d’occasion ne permettent pas le déverrouillage du bootloader
    En pratique, mieux vaut acheter directement chez Google, ou prendre sur eBay un appareil avec GrapheneOS/CalyxOS/LineageOS déjà installé, ou encore un appareil dont le vendeur indique explicitement que le déverrouillage du bootloader est possible
    Personnellement, quand le vendeur ne l’avait pas déjà précisé, lui demander de vérifier le bootloader n’a jamais servi à grand-chose. Presque personne ne veut faire la procédure de vérification, et la réponse a de fortes chances d’être « non ». Le vendeur peut aussi mal comprendre la question et simplement répondre « téléphone débloqué », ou être lassé de ce genre de demandes
  • On peut aussi attendre un peu
    Un travail est en cours pour prendre en charge davantage de matériel, et pendant un temps la marque concernée faisait l’objet de spéculations

• J’ai acheté un Pixel 6 d’occasion à bas prix pour essayer GrapheneOS, mais je n’ai pas vraiment aimé
  L’expérience utilisateur de LineageOS m’a semblé bien meilleure. La structure des gestionnaires de paquets est bizarre, comme des poupées russes. L’« App Store » de base ne contient que quelques programmes essentiels, dont l’un est encore un autre gestionnaire de paquets, Accrescent, mais le nombre d’applications reste très limité, donc il faut encore un autre gestionnaire de paquets. Du côté de GrapheneOS, on semble préférer Obtainium à F-Droid, et cela me paraît aussi être une décision étrange
  Je préfère de loin un gestionnaire de paquets complètement open source, et il y a une vraie valeur à reconstruire les paquets depuis le code source de manière externe, si possible de façon reproductible, plutôt qu’à faire confiance à des paquets GitHub. Le modèle de sécurité de GrapheneOS me paraît bizarrement centralisé. Les avantages annoncés en matière de confidentialité et de sécurité sont difficiles à évaluer soi-même

  • Il suffit de télécharger F-Droid soi-même
    Je ne comprends pas pourquoi certains s’obsèdent sur le fait d’avoir absolument un store d’applications déterministe et préinstallé
    Gérer un app store représente presque autant de travail que maintenir un fork Android, et avec déjà plusieurs options comme F-Droid, le Play Store avec Aurora Store, Obtainium, etc., on peut difficilement reprocher aux développeurs de GrapheneOS de ne pas investir un effort énorme là-dedans
  • L’App Store est surtout un point de départ minimal pour décider d’où récupérer les applications
    Dans l’état initial, il n’y a que le lanceur et le strict minimum du système d’exploitation, ce qui suffit aux minimalistes
    Si on veut davantage, c’est à l’utilisateur de choisir où aller. Moi j’appelle ça donner du pouvoir à l’utilisateur, alors que toi tu sembles appeler ça de l’inconfort. Dans ce cas, ce système d’exploitation n’est peut-être tout simplement pas fait pour toi
  • Ce n’est pas parce qu’un logiciel est libre ou open source qu’il est intrinsèquement plus sûr ou plus respectueux de la vie privée
    « Open source » est à la base un terme de licence
    L’« App Store » de GrapheneOS sert à fournir les applications les plus essentielles pour un usage courant. Si Accrescent y est distribué, c’est parce qu’en tant que véritable magasin d’applications il respecte les exigences de sécurité d’Android, contrairement à F-Droid et Aurora Store
    Je ne pense pas qu’il y ait beaucoup de valeur dans le fait qu’un tiers recompile des applications comme le fait F-Droid pour vérifier l’absence de comportement malveillant. Ce type de contrôle est peu fiable et a déjà été contourné. C’est aussi l’une des raisons pour lesquelles WireGuard n’est plus sur F-Droid. Si tu ne fais pas assez confiance à une application pour l’obtenir directement auprès de son développeur, alors tu ne devrais probablement pas l’utiliser
    Les avantages de GrapheneOS en matière de confidentialité et de sécurité sont conçus pour être presque invisibles pour l’utilisateur moyen. On peut citer par exemple un allocateur mémoire renforcé et les extensions de marquage mémoire pour empêcher les bugs de corruption mémoire, ainsi que la possibilité d’installer Google Play en sandbox afin d’utiliser les services Google sans permettre à Google de contrôler l’ensemble de l’appareil
  • GrapheneOS hérite de l’interface utilisateur de l’Android Open Source Project, sur laquelle reposent aussi le système par défaut des Pixel et de nombreux forks Android de divers fabricants
    L’App Store de GrapheneOS existe pour remplir le rôle de store principal d’applications exigé par AOSP. Il sert aussi à mettre à jour les applications principales séparément des mises à jour du système d’exploitation, et dans certains cas à en faire le mirroring
    Accrescent est mis en miroir parce qu’il se concentre sur la confidentialité et la sécurité. Il est actuellement en alpha et les soumissions d’applications sont fermées, mais elles devraient bientôt ouvrir
    Google Play est mis en miroir pour la compatibilité avec les applications qui en ont besoin, ainsi que pour l’accès au Play Store
    Si la communauté GrapheneOS préfère Obtainium, c’est parce qu’il permet d’obtenir des applications signées par leurs développeurs depuis GitHub et d’autres sources du même type. F-Droid signe et construit presque toutes les applications de son dépôt principal avec une infrastructure de build vieillissante et une coordination insuffisante
    Le modèle de sécurité de GrapheneOS reprend celui d’AOSP et le renforce encore davantage
  • Je suis vraiment heureux de voir que CalyxOS redevient plus actif
    GrapheneOS a beaucoup d’implémentations techniques impressionnantes, mais Calyx semble gérer de nombreux aspects de manière plus simple et plus proche d’Android stock

• GrapheneOS dit avoir neutralisé l’optimisation registerQuicConnectionClosePayload pour « corriger la fuite VPN » et avoir de fait supprimé ce vecteur d’attaque sur les Pixel pris en charge
  Autrement dit, GrapheneOS a « corrigé » la fuite en désactivant l’optimisation
  Par le passé sur HN, QUIC a été encensé, et les commentaires demandant à qui QUIC profitait vraiment ont été mal notés. L’usage de QUIC peut aller dans l’intérêt d’autres acteurs, mais pour moi le compromis n’en vaut pas la peine, donc je bloque le trafic QUIC
  QUIC est parfois activé par défaut dans des logiciels distribués par Google, comme sur Android, et dans certains cas il n’existe même aucun moyen de le désactiver

  • Sur GrapheneOS, QUIC lui-même continue de fonctionner normalement
    Ce que GrapheneOS a supprimé, c’est uniquement la manière pour une application de demander au système d’exploitation de fermer automatiquement une connexion QUIC quand l’application se termine ou dans des cas similaires. Du point de vue du serveur, c’est une optimisation puisqu’elle évite de laisser la connexion ouverte, consommer des ressources, puis suivre la procédure de fermeture après expiration du délai d’inactivité, mais ce n’est pas une optimisation côté client
    GrapheneOS a aussi corrigé environ cinq autres fuites VPN, et d’autres correctifs sont en cours. L’implémentation actuelle du VPN dans Android est un VPN par profil, mais les profils n’utilisent pas encore leur propre espace de noms réseau, et le résolveur DNS ainsi que plusieurs services centraux doivent gérer correctement la prise en charge du VPN, ce qui rend les fuites plus probables
    À l’avenir, ils comptent améliorer l’architecture VPN pour la rendre très résistante aux fuites. La prise en charge de l’exécution d’applications ou de groupes d’applications dans des machines virtuelles est également prévue, ce qui pourrait offrir une protection plus forte
  • Il s’agit d’un chemin de fermeture élégante des connexions QUIC exposé via un appel inapproprié ou exploitable, pas d’une désactivation complète de QUIC par GrapheneOS
    QUIC en soi est excellent, et cela relève moins d’une fonctionnalité du protocole que d’une fonctionnalité de Google Android, système d’exploitation de surveillance
    D’ailleurs, même lors de vérifications sur le système avant la dernière version, cela ne fonctionnait pas correctement

• Android stock est un spyware et un adware
  Autrefois, on aurait qualifié ce genre de logiciel de malveillant et on l’aurait supprimé, mais aujourd’hui c’est devenu la norme

  • Tout le monde est d’accord, mais personne ne sait quelle est la solution
    Sachant que 99 % des utilisateurs s’en moquent, les seuls qu’on pourrait vraiment pousser sont les fabricants de téléphones. C’est frustrant d’avoir l’impression de n’avoir aucun poids sur qui que ce soit d’influent dans ce domaine