Le contournement présumé du chiffrement DNS dans macOS Sequoia 15 était en réalité un problème de Little Snitch 6.1

 (obdev.at)
1 points par GN⁺ 2024-09-18 | 2 commentaires | Partager sur WhatsApp
  • Dans Little Snitch 6.1, le chiffrement DNS pouvait échouer dans certaines situations, mais le problème a été circonscrit à cette version plutôt qu’à macOS dans son ensemble, et corrigé dans la 6.1.1
  • Pour un fonctionnement normal, les requêtes DNS de macOS doivent être transmises au proxy DNS de Little Snitch, qui effectue ensuite la résolution chiffrée
  • Lors de l’enquête, il a été observé que certaines requêtes via des API héritées de bas niveau n’atteignaient pas le proxy et envoyaient des requêtes UDP 53 non chiffrées au serveur de noms par défaut du système
  • La reproduction consiste à activer le chiffrement DNS dans Little Snitch, à lancer Wireshark avec le filtre port 53, puis à appeler getaddrinfo("dnsproxytest.com") dans un playground Xcode
  • Les résolutions fondées sur des API de haut niveau, comme celles de Safari et Chrome, semblaient initialement ne pas être affectées, tandis que Firefox semblait l’être, mais le périmètre final a été ramené au proxy DNS de Little Snitch 6.1

Échec du chiffrement DNS survenu dans Little Snitch 6.1

  • La fonction de chiffrement DNS de Little Snitch 6 route les résolutions de noms d’hôte vers Little Snitch afin de les traiter sous forme chiffrée
  • Pour cela, Little Snitch enregistre un proxy DNS, et macOS doit envoyer toutes les requêtes DNS à ce proxy
  • Il a été constaté que certaines requêtes DNS, en particulier celles effectuées via certaines API héritées de bas niveau, n’étaient pas reçues par le proxy
  • Ces requêtes pouvaient être envoyées sous forme non chiffrée au serveur de noms par défaut du système, ce qui était visible dans Wireshark sous forme de trafic UDP sur le port 53
  • Le trafic de ces résolutions n’apparaissait pas dans Little Snitch Network Monitor, car la résolution contournait entièrement le filtre réseau

Procédure de reproduction et chronologie des mises à jour

  • Procédure de reproduction

    • Activer DNS encryption dans les réglages de Little Snitch
    • Lancer Wireshark avec le filtre de capture port 53
    • Dans un playground Xcode, lancer une résolution de dnsproxytest.com avec getaddrinfo
    • La résolution de dnsproxytest.com peut apparaître sur UDP 53 sous forme non chiffrée

  • Portée initiale de l’impact

    • Les résolutions DNS via des API de haut niveau semblaient ne pas être affectées
    • La navigation web avec Safari et Chrome semblait conserver les bénéfices des résolutions chiffrées
    • Firefox semblait être affecté

  • Historique des mises à jour

    • 2024-09-17 19:10 : il a été confirmé que ce problème pouvait exister depuis macOS 14.5 Sonoma, et les systèmes 14.x plus anciens n’ont pas pu être testés
    • 2024-09-18 12:05 : le problème a été requalifié comme n’étant pas un problème général de proxy DNS de macOS, mais comme n’affectant que le proxy DNS de Little Snitch 6.1
    • 2024-09-18 15:52 : le problème a été corrigé dans Little Snitch 6.1.1

À lire aussi

2 commentaires

 
GN⁺ 2024-09-18
Avis de Hacker News

  • Le fait que getaddrinfo() soit considéré comme une « API bas niveau héritée » me paraît un peu étrange
    Sur macOS, la situation peut être très différente, mais sous Linux et probablement *BSD, c’est la méthode standard utilisée pour la résolution de noms
    La plupart des apps macOS utilisent sans doute Foundation ou des frameworks du type NetworkKit pour les requêtes DNS, mais je trouve aussi surprenant que, sous le capot, cela ne finisse pas par descendre vers des appels comme getaddrinfo()
    Comme GAI est bloquant, il existe probablement un autre appel asynchrone bas niveau

    • Exact. CFNetwork est open source, donc on peut vérifier son implémentation, et il me semble qu’à l’époque où je l’avais regardée, elle utilisait une variante comme getaddrinfo_async
      Cela dit, Apple ne veut pas que les utilisateurs finaux résolvent eux-mêmes une IP via getaddrinfo ou une variante asynchrone exposée par CF, puis fassent un connect() vers cette IP
      De manière générale, on est incité à se connecter par nom d’hôte, afin qu’Apple puisse gérer en interne son implémentation de happy eyeballs
      On peut voir pourquoi Apple n’apprécie pas le modèle getaddrinfo() ici : https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf. Il y a aussi des notes du présentateur sous chaque diapositive
    • Je ne pense pas que getaddrinfo() soit considéré comme hérité. Je crois que le billet de blog s’est trompé sur ce point
      Le fait que ce soit « bas niveau » ou non dépend du point de vue
    • getaddrinfo() n’est pas lié à Linux, c’est simplement une fonction glibc
      Les gens supposent que glibc est la méthode standard dans l’espace utilisateur Linux, mais ce n’est pas forcément obligatoire
      Par exemple, systemd a créé son propre mécanisme resolved, qui s’est révélé bien meilleur que celui de glibc
      Comme je développe moi aussi un logiciel autonome visant Linux, il est très probable que je finisse un jour par créer quelque chose de similaire
    • Sur OpenBSD, au moins, les fonctions DNS traditionnelles et standard comme getaddrinfo/gethostbyname sont toutes des wrappers autour de l’implémentation asr de la libc OpenBSD, écrite par Eric Faurot
      https://man.openbsd.org/man3/asr_run.3
      https://github.com/openbsd/src/tree/master/lib/libc/asr
    • Je ne sais pas si c’est exactement le cas ici, mais même des fonctions système portant le même nom peuvent avoir des implémentations internes très différentes entre *Linux/BSD/macOS
      Il existe aussi des différences entre les *BSD
      Sur certains systèmes, un appel de fonction peut rester pendant des années la « bonne » méthode, tandis que sur d’autres il peut être réellement obsolète et peu utile

  • Il s’est avéré que le problème traité ici ne concerne pas macOS dans son ensemble, mais uniquement Little Snitch 6.1, et qu’il doit être corrigé par une mise à jour de Little Snitch plus tard aujourd’hui

    • Ce serait bien que le titre soit mis à jour pour refléter cela

  • Des investigations supplémentaires ont montré que ce bug existait déjà au moins depuis macOS 14.5 Sonoma
    Peut-être même avant, mais il n’aurait actuellement pas accès à un système 14.x plus ancien pour le tester

    • Je me demande s’ils avaient déjà testé que cela fonctionnait réellement avec getaddrinfo
      Ou s’ils l’ont simplement vu fonctionner une fois avec CFNetwork, puis ont publié plus tard un billet de blog disant que c’était cassé
    • Le fait que les développeurs doivent encore conserver séparément d’anciennes versions de l’OS pour les tests n’a toujours aucun sens
      Il n’y a pratiquement aucune raison technique qui empêcherait Apple d’autoriser le downgrade
    • Quand on vend un produit et que le nouvel OS est sorti hier, c’est quand même assez aberrant

  • Sequoia, lorsque le pare-feu de macOS est activé et qu’une app est enregistrée comme « bloquer les connexions entrantes », casse la capacité de cette app à utiliser le DNS, et probablement les fonctionnalités basées sur UDP en général
    https://waclaw.blog/macos-firewall-blocking-web-browsing-aft...

    • Je n’arrive pas à le reproduire. Certains disent que c’est lié à ESET : https://www.reddit.com/r/MacOS/comments/1fievr5/updating_mad...
    • Avant Sequoia, même en utilisant OpenDNS avec un VPN, iMessage et d’autres apps continuaient de fonctionner tout en étant connecté au VPN ; depuis Sequoia, les messages iMessage et autres ne fonctionnent plus pendant la connexion VPN
      Si je déconnecte le VPN, tout passe
      Je me demande si c’est lié. Le pare-feu macOS est activé, mais je ne bloque pas toutes les connexions entrantes
    • Après la mise à niveau vers Sequoia, je ne pouvais plus naviguer avec Safari ni Mozilla
      En allant dans les paramètres DNS de la connexion Wi‑Fi et en ajoutant les serveurs DNS de Google, 8.8.8.8 et 8.8.4.4, le problème a été résolu, et ils ont remplacé les serveurs DNS qui avaient été renseignés automatiquement auparavant
    • Honnêtement, ce comportement me paraît acceptable. Une application ne devrait pas résoudre elle-même le DNS en dehors de ce qui est défini dans les réglages
      Si les apps font cela, c’est pour empêcher l’utilisateur de bloquer des choses comme la télémétrie
      C’est mon ordinateur, donc c’est à moi que devrait revenir la décision finale sur ce qui sort

  • Le titre laisse entendre que c’est intentionnel ou appliqué de façon privilégiée à Apple, mais en réalité cela ressemble plutôt à un simple bug.
    Quand on dit avoir signalé ce genre de chose, ce serait bien de publier aussi le numéro FB et les détails du signalement.

    • Pour jouer l’avocat du diable, ils pourraient l’avoir conçu ainsi volontairement pour éviter les réactions négatives, puis le faire passer pour un bug non corrigé.
      Tant que l’objectif est atteint, la manière de l’implémenter peut être très flexible.
    • Si c’était intentionnel, il s’agirait probablement d’une URL codée en dur et chiffrée.
      Certains appareils ont déjà commencé à utiliser ce genre de méthode pour contourner le blocage des publicités.

  • Je me trompe peut-être, mais j’ai comme une impression de déjà-vu : à chaque nouvelle version d’iOS ou de Mac, il y a un problème DNS qui affecte des outils comme Little Snitch ou Mullvad.
    Si c’est vrai, on peut vraiment se demander ce que fait Apple pendant des mois de développement et de tests développeurs/bêta.

  • La mention de Little Snitch prêtait à confusion, mais en lisant davantage, cela ressemble à un bug de LS qui ne se manifeste que dans certains cas.
    Si c’est le blog de LS, la seule question est pourquoi c’est décrit comme un bug de macOS.
    Je ne dis pas qu’ils ont tort, c’est leur domaine et pas le mien, mais le texte seul ne semble pas vraiment le justifier.

    • Si l’OS permet d’enregistrer un proxy DNS et que certains appels contournent ce proxy, c’est clairement un bug de l’OS.

  • Il me semble qu’Apple avait déprécié l’utilisation de certaines API réseau pour les développeurs tiers.
    Mais les apps d’Apple elles-mêmes, par exemple l’App Store, ne sont pas soumises à la même restriction.
    Donc, quand on essayait de filtrer le trafic réseau via un pare-feu applicatif avec la nouvelle API, cela échouait parce que l’App Store utilisait l’API legacy.
    Cela pourrait faire partie d’un vieux bug que je pensais corrigé depuis longtemps.

    • getaddrinfo() n’est pas une API legacy, mais une API standard multiplateforme pour les requêtes DNS.

  • Les annonces du genre « Bug découvert dans la nouvelle version de l’OS ! Correctif : en fait, c’était un bug présent depuis assez longtemps ! » sont toujours amusantes.

  • J’utilise routedns [0] comme résolveur stub local, ce qui me permet de choisir moi-même quelles requêtes vont où et quel mode de transport utiliser.
    Il permet aussi les listes de blocage, les réécritures, le cache, la répartition de charge et le traitement des requêtes de secours, donc il offre beaucoup de contrôle.
    Pour les requêtes locales, j’utilise un listener stub sur localhost:53, et la plupart des requêtes sont transmises avec cache à Cloudflare 1.1.1.1 via UDP QUIC, c’est-à-dire TLS 0-RTT.
    C’est rapide et plutôt sûr.
    [0] https://github.com/folbricht/routedns
 
nearfall 2024-09-18

Merci pour cette information importante.
C’est déjà rassurant de savoir que Safari et Chrome semblent, pour l’instant, pouvoir être considérés comme sûrs.