Verdacht auf Umgehung der DNS-Verschlüsselung in macOS Sequoia 15 – tatsächlich ein Problem von Little Snitch 6.1

• Bei Little Snitch 6.1 konnte die DNS-Verschlüsselung in bestimmten Situationen fehlschlagen; inzwischen wurde das Problem nicht als allgemeines macOS-Problem, sondern auf diese Version eingegrenzt und in 6.1.1 behoben
• Für korrektes Verhalten müssen DNS-Anfragen von macOS an den DNS-Proxy von Little Snitch weitergeleitet werden, der dann die verschlüsselte Abfrage ausführt
• Während der Untersuchung wurde beobachtet, dass einige Anfragen über Low-Level-Legacy-APIs den Proxy nicht erreichten und stattdessen unverschlüsselte UDP-53-Abfragen an den Standard-Nameserver des Systems sendeten
• Reproduzieren lässt sich dies, indem man in Little Snitch die DNS-Verschlüsselung aktiviert, Wireshark mit dem Filter port 53 ausführt und anschließend in einem Xcode Playground getaddrinfo("dnsproxytest.com") aufruft
• Abfragen auf Basis von High-Level-APIs, etwa in Safari und Chrome, schienen zunächst nicht betroffen zu sein; Firefox schien betroffen zu sein, doch der endgültige Umfang wurde auf den DNS-Proxy von Little Snitch 6.1 eingegrenzt

---

Fehlgeschlagene DNS-Verschlüsselung in Little Snitch 6.1

• Die DNS-Verschlüsselungsfunktion von Little Snitch 6 leitet Hostnamen-Abfragen an Little Snitch weiter, wo sie in verschlüsselter Form verarbeitet werden
• Dafür registriert Little Snitch einen DNS-Proxy, und macOS muss alle DNS-Anfragen an diesen Proxy senden
• Es wurde festgestellt, dass einige DNS-Anfragen, insbesondere solche über bestimmte Low-Level-Legacy-APIs, nicht beim Proxy ankamen
• Diese Anfragen konnten unverschlüsselt an den Standard-Nameserver des Systems gesendet werden und waren in Wireshark als Traffic auf UDP-Port 53 sichtbar
• Im Little Snitch Network Monitor wurde dieser Abfrage-Traffic nicht angezeigt, da die Abfrage den Netzwerkfilter vollständig umging

Reproduktionsschritte und Verlauf der Updates

• Reproduktionsschritte

  • In den Einstellungen von Little Snitch DNS encryption aktivieren
  • Wireshark mit dem Capture-Filter port 53 ausführen
  • In einem Xcode Playground eine Abfrage von dnsproxytest.com mit getaddrinfo ausführen
  • Die Abfrage von dnsproxytest.com kann auf UDP 53 in unverschlüsselter Form sichtbar sein

• Anfänglicher Umfang der Auswirkungen

  • DNS-Abfragen über High-Level-APIs schienen nicht betroffen zu sein
  • Web-Browsing mit Safari und Chrome schien weiterhin von verschlüsselten Abfragen zu profitieren
  • Firefox schien betroffen zu sein

• Update-Verlauf

  • 2024-09-17 19:10: Es wurde bestätigt, dass dieses Problem möglicherweise seit macOS 14.5 Sonoma existierte; ältere 14.x-Systeme konnten nicht getestet werden
  • 2024-09-18 12:05: Das Problem wurde nicht als allgemeines DNS-Proxy-Problem von macOS, sondern als Problem eingeordnet, das nur den DNS-Proxy von Little Snitch 6.1 betrifft
  • 2024-09-18 15:52: Das Problem wurde in Little Snitch 6.1.1 behoben

[GN⁺]

Hacker-News-Meinungen

• Es fühlt sich etwas seltsam an, dass getaddrinfo() als „Low-Level-Legacy-API“ behandelt wird.
  Unter macOS kann die Lage deutlich anders sein, aber unter Linux und vermutlich *BSD ist es der Standardweg für Namensauflösung.
  Die meisten macOS-Apps verwenden für DNS-Abfragen wohl Frameworks wie Foundation oder NetworkKit; überraschend ist aber auch, dass diese intern offenbar nicht letztlich auf Aufrufe wie getaddrinfo() heruntergehen.
  Da GAI blockierend ist, gibt es vermutlich einen anderen Low-Level-asynchronen Aufruf.

  • Stimmt. CFNetwork ist Open Source, man kann sich die Implementierung ansehen, und soweit ich mich von früher erinnere, nutzte es Varianten wie getaddrinfo_async.
    Allerdings will Apple nicht, dass Endnutzer IPs direkt über getaddrinfo oder die von CF bereitgestellten asynchronen Varianten auflösen und dann per connect() zu dieser IP verbinden.
    Insgesamt wird man dazu angehalten, per Hostname zu verbinden, damit Apple intern die Happy-Eyeballs-Implementierung handhaben kann.
    Warum Apple das getaddrinfo()-Modell nicht bevorzugt, sieht man unter https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf. Unter jeder Folie gibt es auch Vortragenden-Notizen.
  • Ich sehe nicht, dass getaddrinfo() als Legacy gilt. Ich glaube, der Blogbeitrag hat diesen Teil falsch dargestellt.
    Ob es „Low-Level“ ist, hängt von der Perspektive ab.
  • getaddrinfo() ist nichts Linux-Spezifisches, sondern einfach eine glibc-Funktion.
    Leute nehmen an, glibc sei der Standardweg im Linux-Userspace, aber das muss nicht zwingend so sein.
    Zum Beispiel hat systemd seinen eigenen resolved-Mechanismus gebaut, der sich als deutlich besser herausgestellt hat als die glibc-Seite.
    Ich baue ebenfalls eigenständige Software für Linux, daher ist es gut möglich, dass ich irgendwann selbst etwas Ähnliches baue.
  • Unter OpenBSD sind zumindest die traditionellen, standardmäßigen DNS-Funktionen wie getaddrinfo/gethostbyname allesamt Wrapper um die von Eric Faurot geschriebene OpenBSD-libc-asr-Implementierung.
    https://man.openbsd.org/man3/asr_run.3
    https://github.com/openbsd/src/tree/master/lib/libc/asr
  • Ich weiß nicht, ob das hier genau der Fall ist, aber selbst Systemfunktionen mit demselben Namen können sich in ihrer internen Implementierung zwischen *Linux/BSD/macOS stark unterscheiden.
    Auch zwischen den *BSDs gibt es Unterschiede.
    Auf einem System kann ein Funktionsaufruf über Jahre hinweg beibehalten werden und der „richtige“ Weg sein, während er auf einem anderen System tatsächlich veraltet und wenig nützlich sein kann.

• Es hat sich herausgestellt, dass das hier behandelte Problem kein macOS-weites Problem ist, sondern nur Little Snitch 6.1 betrifft; es soll später heute mit einem Little-Snitch-Update behoben werden.

  • Es wäre gut, wenn auch der Titel aktualisiert werden könnte, um das widerzuspiegeln.

• Weitere Untersuchungen haben ergeben, dass dieser Bug mindestens seit macOS 14.5 Sonoma existierte.
  Vielleicht sogar schon früher, aber offenbar gibt es derzeit keinen Zugriff auf ein älteres 14.x-System zum Testen.

  • Ich frage mich, ob jemals getestet wurde, ob es mit getaddrinfo tatsächlich funktionierte.
    Oder ob man es einmal mit CFNetwork funktionieren sah, es dabei beließ und später einen Blogpost darüber schrieb, dass es kaputt sei.
  • Dass Entwickler für Tests immer noch alte OS-Versionen separat aufbewahren müssen, ist nach wie vor absurd.
    Es gibt praktisch keinen technischen Grund, warum Apple Downgrades nicht erlauben könnte.
  • Wenn man bedenkt, dass es sich um ein verkauftes Produkt handelt und das neue OS gestern erschienen ist, ist auch das ziemlich absurd.

• Sequoia macht, wenn die macOS-Firewall aktiviert ist und eine App mit „eingehende Verbindungen blockieren“ registriert ist, die Fähigkeit dieser App zur DNS-Nutzung kaputt, vermutlich auch UDP-basierte Funktionen allgemein.
  https://waclaw.blog/macos-firewall-blocking-web-browsing-aft...

  • Ich kann das nicht reproduzieren. Manche sagen, es hänge mit ESET zusammen: https://www.reddit.com/r/MacOS/comments/1fievr5/updating_mad...
  • Vor Sequoia funktionierten iMessage und andere Apps weiter, während ich per VPN verbunden war, auch wenn ich im VPN OpenDNS nutzte; seit Sequoia funktionieren iMessage-Nachrichten usw. während einer VPN-Verbindung nicht mehr.
    Wenn ich das VPN trenne, geht alles durch.
    Ich frage mich, ob das damit zusammenhängt. Die macOS-Firewall ist aktiviert, aber nicht „alle eingehenden Verbindungen blockieren“.
  • Nach dem Upgrade auf Sequoia konnte ich weder mit Safari noch mit Mozilla browsen.
    Als ich in den DNS-Einstellungen der WLAN-Verbindung die Google-DNS-Server 8.8.8.8 und 8.8.4.4 hinzugefügt habe, war es behoben; sie ersetzten die zuvor automatisch eingetragenen DNS-Server.
  • Ehrlich gesagt finde ich dieses Verhalten in Ordnung. Anwendungen sollten DNS nicht eigenständig außerhalb dessen auflösen, was in den Einstellungen festgelegt ist.
    Der Grund, warum Apps das tun, ist, dass sie verhindern wollen, dass Nutzer Dinge wie Telemetrie blockieren.
    Es ist mein Computer, also sollte ich die letzte Entscheidungsgewalt darüber haben, was nach außen geht.

• Der Titel deutet an, dass dies absichtlich oder privilegiert für Apple gilt, tatsächlich wirkt es aber eher einfach wie ein Bug
  Wenn man so etwas meldet, wäre es gut, auch die FB-Nummer und Details zur Meldung mit zu veröffentlichen

  • Als Advocatus Diaboli könnte man sagen: Um Gegenwind zu vermeiden, könnte man es absichtlich so bauen und wie einen nicht behobenen Bug aussehen lassen
    Solange das Ziel erreicht wird, ist die Implementierung beliebig flexibel
  • Wenn es absichtlich wäre, wäre es vermutlich eine hartcodierte und verschlüsselte URL gewesen
    Einige Geräte beginnen bereits, solche Verfahren zu nutzen, um Adblocker zu umgehen

• Vielleicht täusche ich mich, aber ich habe ein Déjà-vu, dass es bei jedem neuen iOS- oder Mac-Release DNS-Probleme gibt, die Dinge wie Little Snitch und Mullvad betreffen
  Falls das stimmt, fragt man sich wirklich, was Apple während der monatelangen Entwickler- und Beta-Tests macht

• Die Erwähnung von Little Snitch hat mich verwirrt, aber nach weiterem Lesen wirkt es wie ein LS-Bug, der nur in bestimmten Fällen auftritt
  Wenn das der LS-Blog ist, bleibt meine einzige Frage, warum es wie ein macOS-Bug beschrieben wird
  Ich meine nicht, dass das falsch ist; das ist ihr Fachgebiet, nicht meins, aber allein aus dem Text wirkt es nicht besonders gut begründet

  • Wenn das OS die Registrierung eines DNS-Proxys erlaubt und einige Aufrufe diesen Proxy dann umgehen, ist das eindeutig ein OS-Bug

• Ich meine mich zu erinnern, dass Apple die Nutzung bestimmter Netzwerk-APIs für Drittentwickler deprecated hatte
  Apples eigene Apps, etwa der App Store, unterliegen aber nicht denselben Einschränkungen
  Wenn man also versucht hat, Netzwerk-Traffic mit der neuen API über eine App-Firewall zu filtern, scheiterte das, weil der App Store die Legacy-API verwendete
  Das könnte Teil eines alten Bugs sein, von dem ich dachte, er sei längst behoben

  • getaddrinfo() ist keine Legacy-API, sondern die standardmäßige plattformübergreifende API für DNS-Lookups

• Ankündigungen wie „Bug in neuem OS-Release gefunden! Korrektur: Tatsächlich war es ein Bug, den es schon ziemlich lange gibt!“ sind immer amüsant

• Ich nutze routedns [0] als lokalen Stub-Resolver und wähle selbst aus, welche Anfragen wohin gehen und welches Transportverfahren verwendet wird
  Es kann auch Blocklisten, Rewrites, Cache, Load Balancing und Fallback-Request-Handling, wodurch man viel Kontrolle hat
  Für lokale Anfragen verwende ich einen Stub-Listener auf localhost:53, und die meisten Anfragen werden mit Cache über UDP QUIC, also TLS 0-RTT, an Cloudflare 1.1.1.1 weitergeleitet
  Schnell und ziemlich sicher
  [0] https://github.com/folbricht/routedns

[nearfall]

Vielen Dank für diese wichtigen Informationen.
Es ist auf jeden Fall beruhigend, dass man sich bei Safari und Chrome erst einmal keine Sorgen machen muss.