macOS-14-Sonoma-Bug legt Mullvad-VPN-App lahm

 (mullvad.net)
1 Punkte von GN⁺ 2023-09-14 | 1 Kommentare | Auf WhatsApp teilen
  • In der Beta und im Release Candidate von macOS 14 Sonoma filtert die PF-Firewall Traffic nicht korrekt, wodurch die Mullvad-VPN-App nicht ordnungsgemäß funktioniert
  • Wenn bestimmte Einstellungen wie Freigabe im lokalen Netzwerk aktiviert sind, kann dies zu Traffic-Leaks führen; Mullvad geht daher davon aus, dass sich Funktionalität und Sicherheit unter macOS 14 schwer garantieren lassen
  • Mullvad untersuchte das Problem nach der sechsten Beta und meldete es an Apple, doch der Bug ist auch in späteren Betas und im Release Candidate weiterhin vorhanden
  • Es wurde geprüft, ob sich das Problem durch einen Patch in der App selbst umgehen lässt, aber es wurde keine sichere Lösung gefunden; grundsätzlich ist eine Korrektur der Firewall durch Apple nötig
  • Nutzerinnen und Nutzer sowie Apps, die auf PF-Filtering angewiesen sind, sollten beim Upgrade auf macOS 14 vorsichtig sein; solange der Bug besteht, ist es sicherer, bei macOS 13 Ventura zu bleiben

PF-Firewall-Problem in macOS 14 Sonoma

  • Während der Beta-Phase von macOS 14 Sonoma hat Apple einen Bug in die macOS-Firewall packet filter(PF) eingeführt
  • Durch diesen Bug funktioniert die Mullvad-VPN-App nicht; wenn bestimmte Einstellungen aktiviert sind, kann es zu Traffic-Leaks kommen
    • Als Beispieleinstellung wird die Freigabe im lokalen Netzwerk genannt
  • Mullvad untersuchte das Problem nach Erscheinen der sechsten macOS-14-Beta und meldete den Bug an Apple
  • Auch in späteren macOS-14-Betas und im Release Candidate besteht dasselbe Problem weiterhin
  • Mullvad hat geprüft, ob sich durch einen Patch allein an der VPN-App unter macOS 14 sowohl Funktionalität als auch Sicherheit erhalten lassen, kommt derzeit jedoch zu dem Schluss, dass es keine gute Lösung gibt
  • Der Umfang der Auswirkungen beschränkt sich nicht nur auf die Mullvad-VPN-App
    • Firewall-Regeln werden nicht korrekt auf Netzwerk-Traffic angewendet
    • Traffic, der nicht zugelassen werden sollte, kann passieren
    • Nutzerinnen und Nutzer sowie Apps, die im Hintergrund PF-Filtering verwenden oder darauf angewiesen sind, sollten beim Upgrade auf macOS 14 vorsichtig sein
  • macOS 14 Sonoma soll am 26. September erscheinen; falls der Bug weiterhin besteht, wird Mullvad-Nutzern empfohlen, bis zur Behebung bei macOS 13 Ventura zu bleiben

Schritte zur Reproduktion und tatsächliches Ergebnis

  • Das Problem lässt sich unter macOS 14 reproduzieren; dieses Experiment löscht die in PF geladenen Firewall-Regeln
  • Im Terminal wird ein virtuelles Logging-Interface erstellt und anschließend der Traffic überwacht, der zu den später hinzugefügten Regeln passt
sudo ifconfig pflog1 create
sudo tcpdump -nnn -e -ttt -i pflog1
  • In der Datei pfrules werden die folgenden Firewall-Regeln geschrieben
pass quick log (all, to pflog1) inet from any to 127.0.0.1
block drop quick log (all, to pflog1)
  • In einem anderen Terminal wird PF aktiviert und die Regeln werden geladen
sudo pfctl -e
sudo pfctl -f pfrules
  • Ein Ping wird an den Webserver von mullvad.net gesendet
ping 45.83.223.209
  • Erwartet wird, dass der Ping blockiert wird, da er nicht zur Bedingung der einzigen pass-Regel passt, und dass der Traffic in pflog1 als Treffer der block-Regel protokolliert wird
  • Tatsächlich geht der Ping ins Internet hinaus, die Antwort kommt zurück, und in pflog1 wird kein Traffic protokolliert
  • Nach dem Experiment wird die Firewall deaktiviert und alle Regeln werden gelöscht
sudo pfctl -d
sudo pfctl -f /etc/pf.conf

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-14
Hacker-News-Kommentare

  • Derselbe PF-Bug macht auch eine Netzwerkfunktion von OrbStack kaputt.
    Als ich die Ursache bis hierhin eingegrenzt hatte, war es schwer zu glauben, aber offenbar bin ich nicht der Einzige. Ich hoffe sehr, dass das vor der Veröffentlichung der stabilen Version behoben wird.
    Ich konnte es erst gestern an Apple melden; es wirkt wie eine recht neue Regression, vermutlich etwa seit Beta 6.
    PF sollte eigentlich eine Firewall sein, bei der die zuletzt passende Regel angewendet wird, aber macOS scheint sich fast so zu verhalten, als würde die erste passende Regel gelten. Eine frühere block-Regel überschreibt auch ohne quick eine pass-Regel aus einem anderen Anchor, was natürlich Probleme verursacht.

    • „Ich hoffe sehr“ reicht hier nicht. Das muss vor dem Release behoben werden.
      Wenn die stabile Version in diesem Zustand erscheint, ist das inakzeptabel und für mich persönlich ein Grund, Mac OS aufzugeben. Wenn das für ernsthafte Arbeit genutzt werden soll, darf man kein Produkt mit solchen Regressionen ausliefern.

  • Der Beitrag ist sehr knapp und informativ, und gut ist auch, dass die Schritte zur Reproduktion des Bugs einfach enthalten sind.
    Mullvad gefällt mir.
    Nebenbei: macOS hatte in den letzten Releases insgesamt viele seltsame Firewall-Bugs, und ich frage mich, warum man die Firewall-Seite umkrempeln und neu bauen musste.

    • Der Rewrite hatte mit Sicherheit damit zu tun, dass beim Übergang von Catalina zu Big Sur der Wechsel von Kernel Extensions zu System Extensions im Userspace erzwungen wurde, insbesondere zu NetworkExtension: https://developer.apple.com/documentation/networkextension
    • Wenn einen solche Bugs in der lokalen Betriebssystemplattform beunruhigen, könnte man auch überlegen, den lokalen Zugriffspunkt über einen Remote-Browser zu abstrahieren.
      Unabhängig davon, welche lokale Maschine und welches Betriebssystem man nutzt, kann man das Browsing über einen dedizierten Server laufen lassen. Das kapselt nicht die gesamte Netzwerkverbindung, sondern nur das Browsing, aber innerhalb dieses Bereichs ändert es die IP-Adresse, verbirgt den Standort und bietet zusätzlichen Schutz vor Browser-Zero-Days.
      In BrowserBox fügen wir laufend Funktionen hinzu, die Privatsphäre respektieren und schützen und die gesamte Erfahrung verbessern. Es ist Open Source, man kann es also nach Wunsch anpassen. Wenn AGPL-3.0 nicht gefällt, ist auch eine kommerzielle Lizenz möglich: https://github.com/dosyago/BrowserBoxPro
      Wenn man Open Source nicht mag und den Komfort eines großen Unternehmens bevorzugt, scheint auch Mullvad mit dem Mullvad Browser etwas Ähnliches zu haben.
    • Noch besser wäre es gewesen, auch die rdar-/Feedback-Nummer anzugeben.
    • macOS hat jahrelang versucht, den Networking-Stack weiterzuentwickeln, ist bei Regressionen aber immer wieder zurückgerudert.
      Ein älterer Artikel dazu: https://9to5mac.com/2015/05/26/apple-drops-discoveryd-in-lat...

  • Dieser Reproduktionscode ist wirklich schön anzusehen.

    • Dass er einfach ist, ist gut, aber besonders gut ist, dass auch der Aufräumschritt enthalten ist. Das fehlt bei solchen Reproduktionsanleitungen oft.
    • Mir scheint, es werden einfach simple Firewall-Regeln gesetzt und dann eine Anfrage versucht, die gegen diese Regeln verstößt.
      Natürlich ist genau das der Umfang des Bugs, aber besonders ausgefeilt oder schön wirkt dieser Test auf mich nicht.

  • Ich weiß nicht, ob das damit zusammenhängt, aber direkt nach den letzten beiden macOS-Upgrades funktionierte das Netzwerk nicht.
    Ich konnte mich mit WLAN, Ethernet und Hotspots verbinden, aber echte Verbindungen wie Browser oder ping funktionierten gar nicht, und auch der Router war nicht erreichbar.
    In beiden Fällen reichte es, die Mullvad-VPN-App einmal zu öffnen, und danach funktionierte alles wieder. Warum allein das Öffnen der App das Problem behebt, weiß ich nicht.

    • Eine VPN-App ändert die Routing-Tabelle; daher wurde der Traffic vermutlich auf ein nicht existierendes Interface geroutet, bis die VPN-App gestartet wurde.

  • Nicht vollständig verwandt, aber es gibt noch einen anderen alten Bug: ein 11 Jahre alter Bug in macOS Popen(): https://news.ycombinator.com/item?id=37238433

    • Wenn es dein Bug ist, solltest du am besten auch Feedback samt Patch schicken. Das Open-Source-Projekt nimmt normalerweise keine PRs an.

  • Zur Info: Mit Mullvad.app hatte ich Verbindungsprobleme, aber wenn ich die Mullvad-WireGuard-Konfiguration in Wireguard.app ausführe, funktioniert es gut.

  • Ich habe kürzlich die neueste Sonoma-Beta installiert, und jetzt verstehe ich, warum ich Mullvad partout nicht zum Laufen bekommen konnte.
    Gut, dass Mullvad an einem Workaround arbeitet. Heute Morgen hatte ich schon überlegt, auf Ventura downzugraden; jetzt fühlt es sich so an, als hätte ich tatsächlich das richtige Problem gefunden.

    • Dort steht nicht, dass sie an einem Workaround arbeiten. Es heißt, Nutzer sollten nicht auf Sonoma upgraden, bis Apple den Bug behebt.
    • Die Kombination tailscale/mullvad scheint weiterhin zu funktionieren. Das könnte ein brauchbarer Workaround sein, bis Apple das behebt.

  • Schön, dass Mullvad den öffentlichen Druck wegen dieses Problems erhöht. Dieser Bug war definitiv auffällig und ziemlich besorgniserregend.

    • War das anderswo schon bekannt? Mullvad scheint es nach der 6. Beta gemeldet zu haben, und zu diesem Zeitpunkt ist man schon ziemlich nah am RC.
      Im Original heißt es: „we have investigated this issue after the 6th beta was released and reported the bug to Apple“.

  • In meinem Fall war die Lösung, die WireGuard-Konfiguration herunterzuladen und die Wireguard-App zu verwenden.

    • Aber sorgt die Wireguard-App nicht dafür, dass Daten leaken, und ist sie nicht weniger sicher als die Mullvad-App?
    • Das ist nur dann eine Lösung, wenn man keine PostUp- und PostDown-Firewall-Regeln in die WireGuard-Konfiguration einträgt. Dann ist es kaum noch eine Lösung.

  • Frage: Verhält sich pf wie erwartet, wenn pflog1 nicht erstellt wird?
    Wenn tcpdump nichts protokolliert, was über pflog1 hinausgeht, scheint das zu bedeuten, dass keine Daten an pflog1 gesendet werden. Dann läge das Problem also eine Stufe davor.
    War pflog1 verbunden und hochgefahren? Früher musste man das Interface manuell verbinden und hochfahren. Macht MacOS das automatisch?
    Natürlich ist es nicht die Aufgabe des Bug-Reporters, das zu isolieren. Aber irgendwann wird der zuständige Engineer solche Fragen stellen, daher ist es besser, die Antworten schon parat zu haben.

    • Gibt es etwas, das man als Workaround zu den Reproduktionsschritten hinzufügen könnte? Zum Beispiel, wie gesagt, das Interface nach dem Laden der pfrules verbinden und hochfahren.
    • Danach muss man zum Entfernen des zusätzlichen Interfaces auch Folgendes ausführen:
      ifconfig pflog1 destroy