Android pourrait bientôt limiter ADB sur l’appareil

 (kitsumed.github.io)
2 points par GN⁺ 3 시간 전 | 2 commentaires | Partager sur WhatsApp
  • Il ne s’agit pas d’une annonce officielle de Google, mais d’une demande de fonctionnalité IssueTracker en cours, où un mainteneur principal d’ADB évoque, pour éviter les abus, la possibilité de limiter les connexions locales et de ne lier ADB qu’à wlan0
  • Si seul wlan0 est autorisé, ADB sur l’appareil, qui utilise l’adresse de loopback 127.0.0.1, ainsi que l’ADB via VPN ou Ethernet et plusieurs environnements de développement pourraient ne plus fonctionner
  • La discussion est partie de CVE-2026-0073, qui contournait complètement l’authentification Wireless ADB ; la demande initiale visait à pouvoir choisir l’interface d’écoute d’ADBD afin de ne pas l’exposer à tous les réseaux
  • Une application malveillante classique ne peut pas démarrer directement ADBD ni terminer seule l’appairage Wireless ADB ou l’approbation TCP/IP, ce qui rend difficile l’obtention de privilèges ADB sans action manuelle de l’utilisateur
  • Bloquer définitivement les connexions en loopback affecterait Shizuku et les outils basés sur libadb-android ; il faudrait donc un réglage au choix de l’utilisateur permettant de désactiver le blocage par défaut même après redémarrage

Une discussion préliminaire, pas une annonce officielle

  • Cette affaire ne repose pas sur une politique arrêtée ni une annonce officielle de Google, mais sur une demande de fonctionnalité IssueTracker en cours et sur un commentaire d’un mainteneur principal d’ADB
  • Le mainteneur évoque, à partir de cas où des applications ont utilisé le socket local d’ADBD pour élever leurs privilèges, la possibilité de lier ADBD uniquement à l’interface Wi‑Fi wlan0
  • Dans la discussion publique, il faut éviter les simples protestations, les insultes ou la répétition des mêmes cas d’usage
    • Si vous avez un cas d’usage spécifique, vous pouvez laisser un avis concret en incluant votre workflow, des liens pertinents et des compromis techniques
    • Si le même cas a déjà été signalé, il est recommandé d’utiliser +1 et les notifications plutôt que de répéter un commentaire
    • Un afflux de commentaires de mauvaise qualité peut entraîner le verrouillage du ticket, ou réduire les retours utiles et les mises à jour publiques

Trois modes de connexion ADB

  • ADB est un protocole qui fournit aux développeurs et utilisateurs avancés un accès en ligne de commande avec des privilèges élevés pour tester et administrer des appareils Android
  • Les principaux modes de connexion se répartissent en trois catégories
    • USB : le mode d’origine, qui consiste à connecter directement l’appareil à un ordinateur distinct avec un câble USB
    • ADB TCP/IP : utilise généralement le port 5555, transmet le trafic en clair et s’authentifie via une fenêtre d’approbation YES/NO. Une connexion ADB existante est nécessaire pour l’activer
    • Wireless Debugging : introduit avec Android 11, il appaire l’ordinateur via un code ou un QR code, puis établit une connexion authentifiée et chiffrée. Il ne nécessite pas de connexion ADB existante pour être activé

L’écosystème créé par ADB sur l’appareil

  • Dans l’usage classique, ADB connecte l’ADBD de l’appareil Android au client ADB d’un ordinateur de développement distinct, mais certains développeurs travaillent directement depuis l’appareil Android sans ordinateur
  • ADB sur l’appareil (On-Device ADB) n’est pas un terme officiel ; il désigne l’exécution d’un client ADB dans un émulateur de terminal comme Termux, qui se connecte à l’ADBD du même appareil
    • Il utilise ADB TCP/IP ou Wireless Debugging
    • Comme le client et le serveur sont sur le même appareil, la connexion passe par l’adresse de loopback 127.0.0.1
  • Cette approche sert de base à des projets open source destinés aux développeurs et utilisateurs avancés, comme libadb-android et Shizuku
  • ShizuCallRecorder est une application basée sur Shizuku, créée pour réduire les difficultés du quotidien liées au handicap
    • Un utilisateur s’en est servi pour conserver le message vocal d’un membre décédé de sa famille
    • L’enregistrement des appels sur Android a été très demandé par les utilisateurs ; une fonctionnalité officielle avait été envisagée dans Android 11 puis annulée, et il existe aujourd’hui des applications de contournement fermées ou potentiellement intrusives pour la vie privée
    • Certains OEM imposent une annonce vocale d’enregistrement des appels même dans des régions où la loi ne l’exige pas

Demande de choix d’interface et restriction à wlan0

  • L’objectif initial de la nouvelle demande de fonctionnalité est de permettre aux développeurs de choisir l’interface réseau sur laquelle ADBD écoute
  • Elle s’inscrit dans le contexte de CVE-2026-0073, qui permettait de contourner entièrement la procédure d’authentification Wireless ADB
  • Aujourd’hui, ADBD est accessible depuis tous les réseaux auxquels le téléphone est connecté ; une fonction de sélection d’interface pourrait donc réduire la surface d’exposition
  • Mais si seul wlan0 est autorisé, les configurations suivantes pourraient casser
    • ADB sur l’appareil utilisant le loopback
    • ADB via VPN
    • ADB via Ethernet
    • D’autres environnements de développement spécifiques
  • Des développeurs Android ont eux aussi déjà utilisé ADB sur l’appareil lorsqu’ils n’avaient pas accès à un ordinateur

Les contraintes qu’une application malveillante doit franchir

  • ADB sur l’appareil peut servir à une élévation de privilèges, mais une application malveillante ordinaire ne peut pas établir la connexion par elle-même

  • Utilisateurs Android ordinaires

    • Si ADB est désactivé, ADBD n’est pas lancé
    • Une application malveillante ne dispose pas non plus de la permission WRITE_SECURE_SETTINGS, qui doit être accordée manuellement via ADB, ce qui rend difficile une attaque via ADB

  • Développeurs utilisant Wireless ADB sur Android 11 ou plus récent

    • L’utilisateur doit activer lui-même le débogage USB et Wireless ADB pour qu’ADBD écoute sur une interface réseau
    • Pour qu’une application se connecte, l’utilisateur doit récupérer un code d’appairage à usage unique dans l’écran des paramètres et le fournir ; l’application seule ne peut donc pas se connecter

  • Développeurs utilisant ADB TCP/IP

    • L’utilisateur doit activer le débogage USB, activer TCP/IP via USB ADB, puis débrancher le câble
    • Si une application initie la connexion, une fenêtre d’approbation apparaît à l’écran ; si l’utilisateur choisit No, elle est refusée
    • Dans un état d’authentification normal, une application ne peut pas se connecter à l’insu de l’utilisateur pour attaquer l’appareil

Risque de vulnérabilité et portée du blocage

  • Dans des conditions normales, une application malveillante ne peut pas démarrer directement ADBD ; une possibilité de connexion n’apparaît que lorsqu’un développeur utilise ADB sur l’appareil
  • S’il existe une vulnérabilité contournant l’authentification, comme CVE-2026-0073, elle peut être exploitée dans les environnements Wireless ADB et TCP/IP
    • Même dans ce cas, l’utilisateur doit d’abord activer manuellement le débogage USB
    • Avec le mode TCP/IP, l’utilisateur doit aussi activer lui-même ADB TCP/IP
  • Il faut distinguer le blocage par défaut des connexions en loopback d’un blocage permanent que l’utilisateur ne pourrait pas désactiver
  • La désignation d’un administrateur d’appareil ou l’octroi d’autorisations d’accessibilité peuvent aussi être accordés à une application malveillante par action de l’utilisateur, mais cette seule possibilité ne conduit pas à supprimer ces fonctionnalités

Un compromis laissant le choix à l’utilisateur

  • Le blocage du loopback devrait être un réglage persistant que l’utilisateur peut désactiver explicitement
    • Il doit être conservé après redémarrage pour que des outils comme Shizuku restent utilisables en pratique
    • Si possible, les applications tierces ne devraient pas pouvoir lire l’état du réglage, afin d’éviter d’avoir à le modifier à répétition pour contourner la détection par des applications bancaires ou des jeux
    • Si la permission WRITE_SECURE_SETTINGS est accordée manuellement à une application, certaines restrictions peuvent être contournées
  • Une approche adaptée consisterait à permettre à l’utilisateur de désactiver la fonction de sécurité et d’autoriser le débogage sur l’appareil, tout en assumant le risque d’exposition à de futures vulnérabilités
  • Un blocage permanent d’ADB sur l’appareil affecterait un écosystème open source de niche, notamment

À lire aussi

2 commentaires

 
unsure4000 1 시간 전

beurk…
 
GN⁺ 3 시간 전
Avis de Hacker News

  • Je suis globalement favorable aux améliorations de sécurité, mais ici le bénéfice semble quasi nul. Pour que cette attaque fonctionne, l’utilisateur doit activer à la fois les options développeur et ADB à distance ; ce n’est donc pas un vecteur d’attaque réaliste pour 99,9 % des gens, et les 0,1 % restants savent généralement ce qu’ils font.
    Une modification limitant l’accès à une interface ou une IP donnée serait bienvenue, mais il suffirait de permettre aux développeurs de le restreindre à localhost. On a fortement l’impression qu’ils cherchent à bloquer Shizuku, Canta, etc., en les faisant passer pour des dommages collatéraux.

    • Désormais, dans le logiciel, la sécurité vire au désastre. Le moindre site exige l’authentification à deux facteurs, vous déconnecte toutes les quelques heures, et même si vous tapez disable sandbox pour lancer un agent en mode illimité, ça ne fonctionne pas sur mobile.
      Dans Firefox, on ne peut même pas installer d’extensions non signées sans passer par la Developer Edition ; les sites imposent les passkeys ; même un simple bucket S3 se retrouve entouré de dizaines de couches de contrôle d’accès, d’identités de service, d’IAM et d’OAuth. OAuth ne fonctionne pas sur les appareils headless, des banques exigent leur appli dédiée au lieu de TOTP, les VPN sont bloqués, la surveillance sous identité réelle est justifiée au nom de la protection de l’enfance, et des initiatives cherchent aussi à interdire les modèles à poids ouverts sous prétexte que les informations partiraient en Chine.
      La sécurité est devenue une valeur absolue, toujours prioritaire sur le confort, l’utilisabilité, la vie privée, la possibilité de modifier les choses et l’ouverture ; le secteur de la sécurité informatique devrait en avoir honte.
    • Les options développeur et ADB à distance ne suffisent même pas. Les builds Android ordinaires redemandent à l’utilisateur d’approuver la clé du client lors de la connexion.
      Ce changement ne semble pas viser la sécurité des utilisateurs, mais la protection des intérêts des entreprises.
    • Depuis l’iPhone, une bonne partie des changements présentés comme des fonctions de sécurité ont en réalité été des suppressions de fonctionnalités des appareils.
      Au début, on disait d’utiliser seulement Safari sans App Store, et je pense que la racine se trouvait dans la paranoïa propre à Steve Jobs, qui aurait répugné, même pendant son traitement contre le cancer, à laisser un dispositif médical au design peu élégant toucher son corps. Cette volonté d’empêcher quelque chose d’« impur » de toucher l’appareil « parfait » a été justifiée après coup dans le langage de la sécurité.
      À l’époque, on disait qu’il fallait éviter une situation à la Windows 98, infesté de logiciels malveillants, mais les systèmes d’exploitation modernes ont déjà largement dépassé le niveau de sécurité fragile de Windows à cette époque.
    • Même en tant que développeur ayant publié une appli Android, il m’est arrivé de ne pas pouvoir accéder à mon appareil quand l’écran était cassé, parce que le pénible bouton ADB à distance était désactivé. Le cas où les options développeur et ADB à distance sont activés en même temps est si rare en conditions réelles qu’on peut l’ignorer comme vecteur d’attaque.
    • Dire que « les acteurs malveillants ne peuvent pas obtenir de connexion ADB dans des circonstances normales » dépend de la façon dont on définit un acteur malveillant.
      Le but de bloquer les outils de confidentialité sans root basés sur Shizuku n’est pas la sécurité du propriétaire, mais celle du gouvernement. Les applications en environnement d’exécution de confiance comme l’EU Digital Identity Wallet, ainsi que les fonctionnalités qui seront exigées à l’avenir au nom de la protection de l’enfance, reposent fortement sur l’hypothèse que l’utilisateur ne peut pas manipuler l’appareil ni installer de logiciel non autorisé. Tout le monde sait comment les choses évoluent avec Intel SGX.

  • La restriction d’ADB est l’étape suivante logique. Même si cette proposition n’est pas adoptée telle quelle, Google a déjà fait en sorte que des tâches normales d’informatique personnelle dépendent d’interfaces développeur internes à l’appareil ou accessibles par USB/sans fil.
    Un jour, il faudra probablement fournir son identité et payer une redevance annuelle, ou subir de fortes limitations pour utiliser Android de façon significative. Google ne veut pas que des applications Android soient développées en dehors des circuits de distribution contrôlés, et la bataille était déjà perdue quand il n’est pas revenu sur les changements interdisant le sideloading normal et légal.
    Les avertissements d’enregistrement d’appel sont aussi de la responsabilité de Google. Quand les fabricants ont adopté le dialer Google au lieu de leurs meilleurs dialers maison, cela s’est appliqué uniformément même dans des régions où il n’y avait pas d’obligation légale. C’est particulièrement pénible sur les SoC MediaTek, qui ne prennent pas en charge au niveau matériel l’enregistrement via des applis tierces stables.
    Au final, c’est la preuve que je ne possède pas « mon » appareil ; dans quelques années, Gemini écoutera et résumera peut-être nos appels via un canal de surveillance approuvé.

    • Mon cas est différent. J’écris depuis un smartphone GNU/Linux Librem 5.
    • Si vous pouvez installer votre propre système d’exploitation, alors vous possédez l’appareil. Google l’a constamment permis, donc c’est vers les autres fabricants qui le bloquent qu’il faut diriger votre colère.

  • Je me demande si des solutions de remplacement pour les usages légitimes seront aussi fournies. Quand on supprime une fonctionnalité sans proposer d’alternative, les développeurs sont poussés vers des contournements plus fragiles, voire parfois contraires aux règles.

  • Cette réaction me semble être une grosse sur-réaction née d’un malentendu. J’utilise ADB à distance pour installer de nouveaux builds d’un projet Android en développement et récupérer les logs, et je me connecte actuellement via un VPN Tailscale.
    Mais avec la méthode actuelle, une faille pré-authentification pourrait être exposée sur tous les Wi-Fi publics auxquels l’appareil se connecte. Si l’on pouvait limiter l’accès à l’interface Tailscale uniquement, ce serait au contraire une amélioration.
    Le cœur de la proposition est de spécifier l’interface à laquelle se lier lors de la configuration d’ADB à distance, au lieu de toutes les interfaces. Rien n’indique que localhost serait refusé, et la courte proposition consistant à se lier uniquement à wlan0 est manifestement mauvaise, car moins fiable qu’un VPN, et ne sera sans doute pas l’orientation réelle de l’implémentation.

  • Même si le spam du thread pousse un développeur Google à verrouiller l’issue et à ignorer les retours, cela ne changera rien par rapport à aujourd’hui. Si la critique en elle-même vous dérange, vous pouvez librement exprimer votre soutien, puisque les retours utiles aussi peuvent être verrouillés.

    • Il faut distinguer la critique d’une politique et l’assaut collectif d’une foule Reddit.
    • Le présupposé du billet selon lequel les développeurs Google auraient simplement raté ou mal compris des cas d’usage importants, et qu’il suffirait de les leur signaler pour qu’ils reconsidèrent la chose, est franchement insultant.
    • Dès qu’un tel billet arrive sur HN ou Reddit, toute chance de faire changer quelqu’un d’avis disparaît, et l’issue GitHub risque vite d’être envahie.
      Google prend parfois en compte les retours des développeurs d’applications, mais il est naturel qu’il accorde plus de poids au jugement de ses équipes internes qu’à celui de développeurs open source dépendant de ce genre d’astuces.
      Le daemon ADB n’a clairement pas été conçu pour permettre à une appli d’ouvrir une session ADB sur l’adresse de loopback afin de rendre possible l’enregistrement des appels. https://xkcd.com/1172/ me revient encore en tête.
      Cela ne veut pas dire que les développeurs ont tort de ne pas aimer le changement. Google a lui aussi ajouté l’enregistrement des appels à son dialer, donc il soutient cette fonctionnalité en tant que telle, mais cela ne signifie pas pour autant que l’équipe ADB ne devrait pas renforcer la sécurité.

  • Quand Google a annoncé pour la première fois des restrictions sur le sideloading, on disait « il reste toujours ADB », et ceux qui s’y opposaient ont été vivement critiqués.
    Désormais, il faudra même attendre une méthode de contournement pour activer ADB, et Android n’est plus plus ouvert qu’iOS depuis longtemps. Cette tendance va continuer.
    C’est un problème non technique, lié à la mentalité de Google, donc il ne peut pas être résolu par une solution technique.

    • Dès l’introduction de l’attestation matérielle à distance, Android était déjà condamné.
      Même si vous pouvez installer votre propre logiciel, l’appareil est considéré comme « modifié ». Si l’attestation échoue, vous n’êtes plus considéré comme fiable et devenez un citoyen de seconde zone, exclu de presque tous les domaines de la société numérique : télécoms, banque, streaming, jeux, etc.
      C’est l’avenir d’Android, et GrapheneOS est le dernier espoir, car certaines entreprises ont miraculeusement commencé à faire confiance aux clés d’attestation de GrapheneOS. Si même cet espoir disparaît, autant acheter un iPhone.
    • Les lignes de contrôle derrière cette mentalité vont bien au-delà de la direction et du conseil d’administration de Google. Cela rappelle le OBEY du classique de Carpenter.

  • C’était évidemment inévitable. La prochaine fois, les gens seront sans doute surpris si la limite de 24 heures sur le sideloading devient illimitée.

    • La probabilité qu’elle devienne illimitée dépendra surtout de l’existence, avant cela, d’une alternative réaliste vers laquelle migrer.
      Il n’est pas nécessaire de conquérir tout le marché : il suffit de faire hésiter Google, ou de rendre la mesure difficile à appliquer juridiquement. Un rôle idéal comparable à celui de Firefox face à Chrome.

  • Voir Android se verrouiller à ce point est un signal d’alarme majeur. Les éléments qui faisaient la qualité d’Android sont lentement supprimés un par un.

  • Je crains que la même chose n’arrive bientôt aux sites web. Pour permettre l’ouverture d’un site sur les appareils Apple, il faudrait payer Apple, et sur les appareils Android, payer Google sous forme de frais mensuels.

    • Le nouveau reCAPTCHA qui exige une attestation à distance va déjà dans cette direction.
      https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...
      Il n’y a pas encore de frais, mais Google peut désormais décider, pour un grand nombre de sites web, quels appareils sont autorisés à se connecter.
    • Le web pourrait se scinder en deux : un nouveau web, où les grands sites paient, et un ancien web, accessible seulement si l’on possède un PC personnel équipé d’un navigateur sans restrictions.
      Il est aussi très probable que le contenu de l’ancien web soit massivement aspiré par des entreprises d’IA, puis reproduit au public via le nouveau web.
    • C’est déjà similaire avec Netflix et d’autres services de streaming vidéo. Il n’est pas nécessaire de payer directement, mais on ne peut pas utiliser de navigateur open source.

  • Il faut un Linux pour smartphone. Si les opérations bancaires peuvent se faire dans un navigateur, une application n’est pas nécessaire, mais les fonctions de communication sans fil et les grandes applications comme Sonos ou Spotify doivent fonctionner.

    • Beaucoup de banques au Royaume-Uni ne proposent désormais ni portail web ni agence physique.
      Il faut une loi imposant un environnement web pleinement fonctionnel pour les services essentiels comme la banque et les services publics. Sinon, le duopole actuel se renforcera encore.
      Moi aussi, je devrais soutenir plus activement les fournisseurs qui proposent des services web.
    • Recommander Android, LineageOS ou GrapheneOS n’est pas approprié, et Sailfish vaut aussi mieux être évité, car il contient beaucoup de composants propriétaires. Le meilleur choix est postmarketOS ; Mobian et d’autres méritent aussi d’être envisagés, tandis qu’Ubuntu Touch et UBports m’ont déçu.
      Consultez le wiki de postmarketOS pour vérifier les appareils compatibles et voir si votre appareil actuel est pris en charge ; si possible, contribuez à améliorer cette prise en charge. Sinon, vous pouvez trouver sur eBay des appareils d’occasion bien pris en charge.
      Le Librem 5 et le PinePhone sont plutôt bien pris en charge, mais d’anciens appareils Android comme le OnePlus 6T peuvent offrir un meilleur rapport performances/prix. Avant d’acheter, vérifiez que les fonctions importantes marchent bien.
      Les applications Android populaires peuvent être exécutées avec Waydroid.
    • Il faut exiger une parité fonctionnelle entre les sites web bancaires et les applications natives. Ma banque ne permet le dépôt de chèques à distance que via l’application, et celle-ci ne fonctionne pas sur les anciens appareils, ce qui m’oblige à utiliser PayPal.
    • Tous les smartphones devraient avoir un bootloader déverrouillable. Cela permettrait à davantage de systèmes d’exploitation d’émerger.
    • Aujourd’hui, les banques imposent leurs applications au nom de la « sécurité », et il est presque impossible d’effectuer des opérations sans elles.
      L’alternative, l’authentification par SMS, n’est pas sûre non plus et disparaît progressivement ; du point de vue de la sécurité, c’est la bonne direction, mais il manque d’autres moyens réellement utilisables.