Android livre votre IP réelle malgré le VPN, et Google ne corrigera pas

Android propose un interrupteur intitulé « Bloquer les connexions sans VPN ». Activé avec le VPN permanent, il vaut promesse du système : rien ne quitte l'appareil en dehors du tunnel. Deux découvertes indépendantes publiées cette année montrent que n'importe quelle application ordinaire passe à côté de cet interrupteur et livre votre adresse IP réelle au serveur de son choix. Google a clos les deux signalements sans rien corriger.

Ce que l'interrupteur est censé garantir

Quand un VPN démarre sur Android, le système réécrit ses règles de routage pour que les applications couvertes n'atteignent le réseau que par lui. Chaque socket porte une marque indiquant au noyau à quel réseau il appartient, et si une application tente de lier un socket directement à l'interface Wi-Fi physique, la vérification échoue et l'appel renvoie une erreur de permission. C'est la mécanique derrière le réglage, et elle fonctionne.

Elle fonctionne pour les applications. Les sockets appartenant aux composants système se situent sous un seuil nommé FIRST_APPLICATION_UID et sont étiquetés comme système, ce qui leur donne accès à n'importe quel réseau quoi que fasse un VPN côté utilisateur. Le système doit pouvoir parler au réseau en toutes circonstances, donc cette exception se défend en soi. Elle devient un problème dès qu'une application ordinaire peut convaincre un processus système d'envoyer un paquet à sa place.

Fuite numéro un : l'au revoir poli

Android 16 a introduit une fonction de fermeture propre des connexions QUIC. Si le socket d'une application meurt brutalement, le serveur d'en face reste avec une connexion à moitié ouverte jusqu'au délai d'expiration ; le système permet donc désormais d'enregistrer à l'avance un paquet d'adieu qu'il délivrera pour l'application. Le chercheur à l'origine de la découverte, qui publie sous le nom lowlevel, a baptisé le résultat le petit canon UDP.

1. L'application appelle une méthode du service réseau et lui remet un socket UDP ainsi qu'un bloc d'octets arbitraire. Aucun contrôle de permission sur cet appel, ni dans la méthode, ni dans la description de l'interface, ni dans la politique de sécurité.
2. Le système note l'appelant, le réseau, ainsi que les adresses et ports source et destination du socket.
3. L'application se termine. Le noyau signale le socket comme détruit.
4. Le processus système ouvre un nouveau socket sur le réseau Wi-Fi physique, le connecte à la destination mémorisée et envoie les octets mémorisés. Le VPN ne voit jamais ce paquet, et la destination voit l'adresse réelle de l'appareil.

Le chercheur a signalé la faille via le programme de primes d'Android. Le dossier a été clos en Won't Fix (Infeasible), au motif que cela sort du modèle de menace. Mullvad, qui n'a pas pour habitude d'écrire sur les bugs des autres, a publié un avertissement en mai et resoumis le problème via le traqueur public ; le dossier a ensuite été marqué inaccessible sans explication. GrapheneOS a livré un correctif qui désactive l'optimisation.

Fuite numéro deux : le keepalive envoyé par la puce Wi-Fi

La seconde découverte, publiée le 29 juillet par Armin Šupuk et décortiquée par Mullvad le 10 septembre, emprunte une autre porte de la même pièce. Android expose une interface publique pour maintenir une correspondance NAT : une application demande au système d'émettre périodiquement un petit paquet UDP afin qu'une connexion passant par le routeur domestique ne saute pas. Par souci d'efficacité, la tâche descend jusqu'à la puce Wi-Fi ou cellulaire, qui émet elle-même les paquets.

Le framework accepte la demande sans vérifier que l'appelant possède réellement la ressource visée, et sans se demander s'il est soumis au verrouillage VPN. Le keepalive naît ensuite dans le matériel réseau, sous la couche où vivent les règles du tunnel. Des paquets de format fixe sur le port UDP 4500 arrivent à l'adresse choisie par l'application, porteurs de l'IP réelle.

L'article retrace un modèle de confiance qui s'est défait avec le temps. L'appel a commencé comme une interface privilégiée prenant un descripteur de fichier brut, a gagné un point d'entrée public, puis une validation de ressource, avant de la reperdre lors d'un retour en arrière. Ce qui subsiste laisse passer la demande sans exiger la moindre preuve de propriété.

La note du signaleur lui-même sur le traqueur de GrapheneOS est plus étroite que le titre de l'article : sur les appareils Pixel, cela marche en Wi-Fi et pas vraiment en IPv6. En revanche, c'est tenace. La fuite continue quand l'application passe en arrière-plan, écran verrouillé, en mode Doze, en économie d'énergie et sous le gel des processus, et elle survit à un arrêt forcé de l'application.

Ce qui s'échappe réellement

Pas vos messages. Les deux fuites sont des canaux étroits : l'application choisit la destination du paquet et, dans le cas QUIC, le contenu de quelques octets. Ce que l'autre bout apprend, c'est qu'un appareil précis avec une adresse IP publique précise existe et se trouve en ligne à cet instant. Pour une application qui sait déjà qui vous êtes, c'est le chaînon manquant entre un compte et une localisation, exactement ce que le VPN devait empêcher.

Pourquoi cela se répète

Les deux fuites viennent de la même décision de conception : des fonctions de confort qui laissent un processus système agir pour le compte d'une application, écrites sans se demander si cette application a le droit, à cet instant, d'atteindre le réseau directement. Le contrôle de verrouillage filtre des identités d'applications, donc tout ce qui s'exécute sous une identité système lui échappe.

Et la liste ne s'arrête pas à deux. Dans la discussion chez GrapheneOS, un mainteneur a signalé que le projet avait trouvé et corrigé lui-même au moins dix autres fuites, et que celles qui surviennent sans qu'une application cherche délibérément à s'échapper passent avant ces deux-là. Le même mainteneur a été direct sur les incitations : Google ne paie pas pour les fuites de VPN, et les signaler sert à documenter, pas à espérer un correctif.

Ce que vous pouvez faire

Ce que cela change pour choisir un VPN

Mieux vaut être précis sur les responsabilités, car la publicité autour de cette affaire ne le sera pas. Aucun service VPN ne peut corriger ces fuites et aucun ne les a créées : les paquets n'atteignent jamais la couche applicative où travaille un client VPN. Ce sur quoi un fournisseur peut être jugé ici, c'est s'il a prévenu ses utilisateurs. Si vous choisissez une application pour votre téléphone, notre comparatif des VPN pour Android porte sur ce que l'application contrôle vraiment, c'est-à-dire tout ce qui se trouve au-dessus de cette couche.