Angreifer können routingbasierte VPNs offenlegen

 (leviathansecurity.com)
3 Punkte von GN⁺ 2024-05-07 | 1 Kommentare | Auf WhatsApp teilen
  • TunnelVision (CVE-2024-3661) missbraucht eine bestehende DHCP-Funktion, um den Traffic von Nutzern am VPN-Tunnel vorbeizuleiten; die Pakete werden dabei nicht vom VPN verschlüsselt
  • Angreifer können über DHCP Option 121 spezifischere Routen einschleusen, die Vorrang vor dem virtuellen VPN-Interface haben, und den Traffic über das physische Interface leiten
  • Der Angriff ist möglich, wenn das Ziel eine vom Angreifer kontrollierte DHCP-Lease akzeptiert und der Client Option 121 implementiert; in Tests waren Windows, Linux, iOS und macOS betroffen, Android dagegen nicht
  • Der VPN-Steuerkanal bleibt weiterhin bestehen, sodass Nutzer die Verbindung als aktiv sehen; in beobachteten Fällen konnte auch ein Kill Switch das Lecken von Traffic nicht verhindern
  • Network Namespaces unter Linux können eine starke Lösung sein, während Firewall-basierte Abmilderungen selektive Denial-of-Service-Effekte und einen Seitenkanal zur Ableitung von Traffic-Zielen erzeugen können

VPN-Decloaking durch TunnelVision

  • TunnelVision ist eine Netzwerktechnik, die VPN-Kapselung umgeht und den Traffic von Nutzern zwangsweise aus dem Tunnel herausleitet
  • Angreifer können DHCP (Dynamic Host Configuration Protocol) nutzen, damit Zielpakete ohne VPN-Verschlüsselung übertragen werden
  • Da der VPN-Steuerkanal erhalten bleibt, sieht es für Nutzer weiterhin so aus, als seien sie mit dem VPN verbunden; dieser Effekt wird als Decloaking bezeichnet
  • Diese Technik könnte bereits seit 2002 möglich gewesen sein; nach der Veröffentlichung wurde bestätigt, dass es mindestens seit 2015 frühere Untersuchungen zu DHCP Option 121 und ihren Auswirkungen auf VPNs gab

Warum VPN-Routing zur Angriffsfläche wird

  • Ein VPN erstellt einen Tunnel für Traffic zwischen dem Host-Gerät und einem Server in einem anderen Netzwerk; der VPN-Client ver- und entschlüsselt Traffic auf einem virtuellen Netzwerk-Interface
  • Eine Konfiguration, die den gesamten Traffic durch das VPN schickt, heißt Full-Tunnel-VPN; eine Konfiguration mit Ausnahmen, etwa für das lokale Netzwerk, heißt Split-Tunnel-VPN
  • Da das VPN die Verbindung zum Server aufrechterhalten muss, benötigt es eine Ausnahme-Route, die Traffic zur IP-Adresse des VPN-Servers über das physische Interface sendet
  • Die Routing-Tabelle legt den Traffic-Pfad je nach Ziel fest; in den meisten Netzwerk-Stacks haben spezifischere CIDR Prefix Lengths höhere Priorität
    • Eine /32-Route hat Vorrang vor /24 oder /0
    • Viele Full-Tunnel-VPNs leiten Traffic über 0.0.0.0/0 oder zwei /1-Routen an das VPN-Interface

Routeneinschleusung mit DHCP Option 121

  • DHCP stellt Geräten im lokalen Netzwerk dynamisch IP-Adress-Leases bereit und übermittelt über Options auch Einstellungen wie Standard-Gateway und DNS-Server
  • Der übliche Ablauf ist, dass der Client DHCPDISCOVER per Broadcast sendet und der Server mit DHCPOFFER eine zeitlich begrenzte Lease anbietet
  • Die in RFC 3442 eingeführte DHCP Option 121 ist die Funktion Classless Static Routes, mit der ein DHCP-Server statische Routen zur Routing-Tabelle des Clients hinzufügen kann
  • Option 121 erlaubt es dem DHCP-Server nicht, das Netzwerk-Interface-Gerät der zu installierenden Route direkt anzugeben
    • Der DHCP-Server gibt einen CIDR-Bereich und einen Router an
    • Der Client wählt implizit das Interface, über das er mit dem DHCP-Server kommuniziert, als Interface für diese Route aus
  • Durch dieses Verhalten kann Traffic über eingeschleuste Routen nicht über das virtuelle VPN-Interface, sondern über das physische Netzwerk-Interface laufen, das mit dem DHCP-Server kommuniziert

Angriffsbedingungen und Vorgehen

  • Für einen TunnelVision-Angriff sind zwei Bedingungen erforderlich
    • Der Ziel-Host muss eine Lease eines vom Angreifer kontrollierten DHCP-Servers akzeptieren
    • Der DHCP-Client des Ziel-Hosts muss DHCP Option 121 implementieren
  • Ein Angreifer im selben Netzwerk kann auf verschiedene Weise zum DHCP-Server des Ziels werden
    • Durchführung eines DHCP-Starvation-Angriffs gegen den echten DHCP-Server und anschließende Antworten an neue Clients
    • Schnellere Antwort auf DHCPDISCOVER-Broadcasts und Ausnutzung des First-Offer-Auswahlverhaltens von DHCP-Clients
    • Abfangen des Traffics zwischen echtem DHCP-Server und Client per ARP-Spoofing und Warten auf die Lease-Erneuerung
  • Der Angreifer betreibt im selben Netzwerk wie der VPN-Nutzer einen DHCP-Server und setzt sich selbst als Gateway
  • Anschließend fügt er über DHCP Option 121 beliebige Routen in die Routing-Tabelle des VPN-Nutzers ein und setzt spezifischere Routen als die /0-Route des VPNs, sodass sie Vorrang vor dem virtuellen VPN-Interface haben
    • Mit mehreren /1-Routen kann die von den meisten VPNs verwendete Gesamt-Traffic-Regel 0.0.0.0/0 nachgebildet werden
    • Der Angreifer kann auswählen, welche IP-Adressen durch den VPN-Tunnel gehen und welche über das Interface laufen, das mit dem DHCP-Server des Angreifers kommuniziert
  • Dies lässt sich auch auf bereits bestehende VPN-Verbindungen anwenden; durch kurze DHCP-Lease-Zeiten können Aktualisierungen der Routing-Tabelle häufiger erzwungen werden

PoC und Testszenarien

  • Die veröffentlichten Materialien sind:
  • Die Testumgebung ist so aufgebaut, dass sie mehrere Angriffsszenarien abbildet
    • Wenn ein Angreifer einen DHCP-Server oder Access Point kompromittiert hat
    • Wenn ein böswilliger Administrator die Infrastruktur direkt besitzt und konfiguriert hat
    • Wenn ein Angreifer an einem physischen Ort wie einem Café oder Büro einen Evil-Twin-WLAN-AP installiert hat
    • Nach einer künftigen Veröffentlichung von ArcaneTrickster kann auch ein Angreifer simuliert werden, der sich als benachbarter Host im selben LAN befindet, aber keine privilegierte Netzwerkposition hat

Betroffene Betriebssysteme und VPNs

  • In den Tests waren Betriebssysteme betroffen, die DHCP-Clients gemäß RFC-Spezifikation implementieren und DHCP-Option-121-Routen unterstützen
    • Betroffen beobachtet: Windows, Linux, iOS, macOS
    • Ausnahme: Android unterstützt DHCP Option 121 nicht und ist daher nicht betroffen
  • VPNs, die den Schutz des Host-Traffics allein auf Routing-Regeln stützen, sind verwundbar
  • Auch Systemadministratoren, die eigene VPN-Server betreiben, können betroffen sein, wenn sie die VPN-Client-Konfiguration nicht gehärtet haben
  • Die Stärke der Verschlüsselungsalgorithmen spielt keine Rolle
    • TunnelVision bricht nicht die VPN-Protokolle selbst, etwa WireGuard, OpenVPN oder IPsec
    • Stattdessen wird die Routing-Konfiguration des Betriebssystem-Netzwerk-Stacks so verändert, dass Nutzer den VPN-Tunnel nicht verwenden

Korrekturen und Abmilderungen

  • Network Namespaces unter Linux können dieses Verhalten vollständig beheben
    • Die WireGuard-Dokumentation zeigt, wie Traffic von Anwendungen, die das VPN nutzen müssen, in einem separaten Namespace verarbeitet und anschließend in einen anderen Namespace mit physischem Interface weitergeleitet wird
    • Unklar ist, ob es unter Windows, macOS und anderen Betriebssystemen eine ähnlich robuste Lösung gibt
  • Einige VPN-Anbieter setzen als Abmilderung Firewall-Regeln ein, die sämtlichen ein- und ausgehenden Traffic des physischen Interface blockieren
    • Für LAN und zur Aufrechterhaltung der Verbindung zum VPN-Server sind Ausnahmen für DHCP und die IP-Adresse des VPN-Servers erforderlich
    • Per Deep Packet Inspection könnten auch nur DHCP und das VPN-Protokoll zugelassen werden, was jedoch wahrscheinlich Performance-Kosten verursacht
  • Firewall-Abmilderungen erzeugen bei Traffic, der DHCP-Routen nutzt, einen selektiven Denial of Service und fügen einen Seitenkanal hinzu
    • Ein Angreifer kann Veränderungen im Volumen des VPN-verschlüsselten Traffics analysieren und statistisch nachweisen, ob der Zielnutzer Traffic zu einem bestimmten Ziel sendet
    • Er kann dies mit vordefinierten Listen abgleichen, selektive Sperren als Zensurmechanismus durchführen oder IP-Adressräume wie bei einer binären Suche blockieren, um aktuelle Verbindungen in logarithmischer Zeit zu finden
  • Eine weitere Möglichkeit ist, Option 121 während der VPN-Nutzung zu ignorieren; diese Funktion kann jedoch für legitime Netzwerkverbindungen nötig sein und dadurch Verbindungsprobleme verursachen
    • Wenn diese Abmilderung optional ist, kann ein Angreifer den Netzwerkzugang verweigern und so VPN oder Nutzer dazu bringen, Option 121 wieder zu aktivieren
  • Hotspots oder VMs können ebenfalls zur Abmilderung beitragen
    • Ein passwortgeschütztes LAN, das von einem Mobilfunkgerät kontrolliert wird, hilft, lokalen Netzwerkzugang durch Angreifer zu verhindern
    • Eine VM verhält sich ähnlich, wenn ihr Netzwerkadapter nicht im Bridged Mode betrieben wird

Erforderliche Maßnahmen für Nutzer und Betreiber

  • Für sensiblen Traffic sollte die Nutzung nicht vertrauenswürdiger Netzwerke vermieden werden; wenn sie unvermeidbar ist, sollte ein VPN-Anbieter mit wirksamen Abmilderungen gegen TunnelVision genutzt werden
  • Selbst bei einem VPN-Decloak bleiben beim Zugriff auf HTTPS-Websites die meisten Nutzerdaten für lokale Netzwerkangreifer unsichtbar, doch Ziel und Protokoll können offengelegt werden
  • Wenn Unternehmens-VPNs in Cafés, Hotels, Flughäfen usw. genutzt werden, sollten Netzwerkadministratoren auf das Risiko hinweisen und empfehlen, dies möglichst zu vermeiden
    • Wenn das nicht praktikabel ist, sollte die Nutzung eines VPNs mit Abmilderung oder Fix empfohlen werden
    • Möglich ist auch, einen vertrauenswürdigen Hotspot zu verwenden und anschließend die VPN-Verbindung aufzubauen oder das VPN innerhalb einer VM auszuführen, die ihre Lease von einem virtuellen DHCP-Server erhält
  • Unternehmen, die eigene Netzwerke oder Site-to-Site-VPNs betreiben, sollten Switches prüfen und Layer-2-Schutzfunktionen wie DHCP Snooping und ARP-Schutz aktivieren
    • Solche Schutzmaßnahmen helfen, Rogue-DHCP-Server zu reduzieren, beseitigen aber nicht das Szenario eines böswilligen Administrators
    • HTTPS oder andere verschlüsselte Protokolle für interne Ressourcen helfen, Datenlecks bei VPN-Nutzern zu verhindern, die sich aus nicht vertrauenswürdigen Netzwerken verbinden
  • VPN-Anbieter können ihren Clients Firewall-Funktionen hinzufügen, die ausgehende Pakete über Netzwerk-Interfaces blockieren; Nutzer können dann jedoch nicht mehr mit lokalen Netzwerkressourcen interagieren
  • Full-Tunnel-VPN-Clients für Linux sollten Isolation mithilfe von Network Namespaces in Betracht ziehen
  • Betriebssystem-Maintainer sollten prüfen, ob sie Funktionen im Zusammenhang mit Network Namespaces auf Nicht-Linux-Betriebssystemen hinzufügen oder stärken können
  • Für LAN-Sicherheitsforschung und praktische Angriffsvorführungen wird eine adversarial infrastructure library namens ArcaneTrickster entwickelt, die später veröffentlicht werden soll

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-05-07
Hacker-News-Kommentare

  • Das ist eine leicht abgewandelte Variante von Samy Kamkars PoisonTap-Angriff aus dem Jahr 2016. Das Gleiche lässt sich mit einem USB-/Thunderbolt-Netzwerkadapter machen: Wenn man ihn an das Gerät des Opfers anschließt und zwei spezifischere Routen wie 0.0.0.0/1 und 128.0.0.0/1 bewirbt, kann man unabhängig von der Reihenfolge der Interfaces sämtlichen Traffic vor anderen System-Interfaces abfangen: https://github.com/samyk/poisontap
    Vermutlich gibt es noch andere frühere Beispiele, aber das hier ist ein sehr bekanntes. Der Titel des Artikels behauptet, alle VPN-Clients seien betroffen, aber wie auch im Text eingeräumt wird, setzen viele VPN-Clients Firewall-Regeln, die Traffic über physische Interfaces blockieren
    VPNs, die mit Anonymität werben oder bei denen diese besonders wichtig ist, setzen das in der Regel um. Oft ist es zwar nicht standardmäßig aktiviert, aber produktiver wäre es gewesen zu dokumentieren, bei wie viel Prozent der großen privaten/kommerziellen/Unternehmens-VPN-Lösungen das standardmäßig eingeschaltet ist
    Die Erklärung für allgemeine Leser ist gut, aber wenn viele Clients mit solchen Firewall-Regeln die meisten Datenlecks verhindern und frühere Arbeiten auf diesem Gebiet nicht anerkannt werden, wirkt der Titel etwas übertrieben

    • Gut auf den Punkt gebracht. Abgesehen von VPNs, bei denen vermutlich ohnehin schon viel ausläuft, weil ihnen sogar grundlegende Firewall-Regeln fehlen, ist das keine besonders bedeutende Schwachstelle
      Bei der Formulierung „Seitenkanalangriff“ hätte ich fast mein Getränk ausgespuckt
      Edit: Wie es aussieht, hat NordVPN zumindest auf macOS keine solchen grundlegenden Firewall-Regeln und ist daher offenbar für diesen Angriff anfällig

  • Ich verstehe nicht, warum dieser Artikel so lang ist
    DHCP Option 121 erlaubt es dem DHCP-Server, Routing-Regeln für bestimmte CIDR-Bereiche zu setzen, und da sie längere Präfixe haben, erhalten sie eine höhere Priorität als die Standardregel 0.0.0.0/0

    • Ich bin einer der Autoren des Artikels. Wir wollten die zugehörigen Themen zuerst erklären, weil wir davon ausgegangen sind, dass auch Leser ohne technischen Hintergrund vorbeischauen
      Die Hälfte der VPN-Informationen im Internet stammt von VPN-Anbietern, und um zu erklären, wie das Ganze tatsächlich funktioniert, sind diese Informationen oft ungenau oder nicht technisch genug
      Ich wollte am Anfang einen verlinkten Satz einfügen wie „Wenn du das schon kennst, spring zum POC-Abschnitt“, werde das aber noch so anpassen, dass es besser sichtbar ist
    • Und damit ein Angreifer diesen Angriff auslösen kann, muss er sich im selben Layer-2-Netzwerk wie das Opfer befinden
      Das ist nur eine Vermutung anhand des obigen Kommentars, ich habe den Artikel nicht gelesen

  • Ich meinte, diesen Angriff früher schon einmal von anderen Autoren gelesen zu haben, habe danach gesucht und nach dem Kampf durch den Spam von VPN-Anbietern frühere Arbeiten [1] gefunden
    Dieser Artikel geht tiefer darauf ein, wie sich die Schwachstelle ausnutzen lässt, und enthält auch Code, der bei einem Proof of Concept hilft
    1: https://www.usenix.org/conference/usenixsecurity23/presentat...

    • Auf diese Arbeit wird im Anhang verwiesen
      Allerdings hat keine der beiden in der Arbeit vom August 2023 vorgestellten Techniken DHCP Option 121 verwendet, um Routen zu pushen. Wenn man Routen per DHCP pusht, ist die Wirkung von derselben Angreiferposition aus deutlich größer. Zum Beispiel an einer Position, an der man IP-Leases außerhalb des RFC1918-Bereichs verteilen oder DNS-Antworten fälschen kann
    • Dieser „Angriff“ ist weithin bekannt und wird auch von der OpenVPN-Client-Konfigurationsoption redirect-gateway def1 genutzt

  • Das Bedrohungsmodell ist, dass ein beliebiger Angreifer irgendwie zum DHCP-Server in meinem LAN werden kann; das ist unwahrscheinlich, aber nicht unmöglich
    Wenn man dagegen ein vom ISP bereitgestelltes Gateway-Gerät nutzt, sieht die Sache anders aus

    • Wenn „ein beliebiger Angreifer wird in meinem LAN zum DHCP-Server“ nur unwahrscheinlich, aber nicht unmöglich ist, dann ist ein Café-WLAN doch genau so ein Fall, oder?
      Das ist schließlich der wichtigste Verkaufsgrund vieler VPN-Produkte
      Die richtige Reaktion in so einem Fall ist, eine 4G-/5G-Verbindung zu nutzen und sich nicht mit dubiosen Netzwerken zu verbinden, denen man nicht vertraut
    • Die Formulierung „dieser DHCP-Server“ setzt voraus, dass es im Netzwerk ein separates spezielles Gerät gibt, und diese Annahme ist falsch. DHCP ist ein Broadcast-Protokoll, und ein Gerät akzeptiert das erste Angebot
      In normalen Haushalten wird DHCP vom Router bereitgestellt und antwortet deshalb meist zuerst, aber das ist nebensächlich. Jedes bösartige Gerät im Netzwerk kann diese Schwachstelle ausnutzen
    • Ist nicht einer der großen Anwendungsfälle von VPN, dass ich dem Netzwerk, mit dem ich verbunden bin, gerade nicht vertrauen kann?
    • Oder dass ich in einem WLAN eines Drittanbieters selbst zum DHCP-Server werde
    • Schutz in einem nicht vertrauenswürdigen WLAN ist doch einer der häufigsten Gründe, mit denen VPNs beworben werden

  • Unter Linux lässt sich das auch abmildern, indem man das VPN-Interface in ein VRF legt. systemd-networkd unterstützt das zum Beispiel standardmäßig
    Zu beachten ist, dass beim Aktivieren von VRF der ip-rule-Eintrag für l3mdev auf 1000 gesetzt wird, die Regel für lokalen Traffic aber auf 0 bleibt. Die lokale Regel muss auf 1000 oder höher verschoben werden

    • Gibt es heutzutage eine Möglichkeit, Apps in einem bestimmten VRF auszuführen?

  • Dieser „Angriff“ ist nichts weiter als eine clevere Nutzung von DHCP Option 121. Gegen stark fehlerhafte Client-Konfigurationen ist das ein wirksamer Angriff
    Es ist nicht sicher, die Standardroute zu ändern oder sie durch zwei /1-Routen zu überschreiben und dann eine Host-Route zum VPN-Endpunkt hinzuzufügen. Um gekapselten Traffic sauber vom unterliegenden Netzwerk zu isolieren, muss man Policy-based Routing verwenden, etwa Linux-Netzwerk-Namespaces, FreeBSD vnet oder OpenBSD rdomains
    Der Versuch, Paketfilter und einen User-Space-„Kill Switch“ irgendwie zusammenzuflicken, ist schon im Design kaputt und zeigt, wie wenig die üblichen VPN-Hoster von ihrer angeblichen Kernkompetenz verstehen oder wie wenig sie sich darum scheren. Wieder einmal das alte Problem des „schlechte Dinge aufzählen“

  • Nichts wirklich Neues
    Mehr Sorgen machen mir Leute, die auf ihrem System IPv6 aktiviert haben, aber einen reinen IPv4-VPN-Dienst nutzen
    Das kann wirklich massiv schiefgehen

  • Es gibt sehr viele Möglichkeiten, den VPN auf dem Client-Gerät zu umgehen. Deshalb bevorzuge ich, wenn ein VPN nötig ist, einen Router zwischen Client und Internet zu platzieren, der den VPN-Tunnel terminiert und keinen alternativen Pfad zulässt.
    Solche Reiserouter lassen sich sehr einfach einrichten und überallhin mitnehmen, und genau das mache ich auch

    • Zu Hause empfehle ich nachdrücklich einen dedizierten VPN-Router, bei dem jeder Router sein eigenes WLAN-Netz hat. Ich halte das für einfacher zu verbinden und stabiler, als auf jedem Gerät lokal VPN-Software laufen zu lassen.
      Zum Beispiel gibt es einen „work“-WLAN-Router, der dauerhaft per VPN mit dem Intranet der Firma verbunden ist, ein „Australia“-WLAN, das jedes Mal einen VPN zu einem australischen Server aufbaut, wenn man australisches TV sehen möchte, und schließlich das normale Heim-WLAN.
      Mit ein paar alten WLAN-Routern ist das sehr einfach umzusetzen, und selbst günstige Heimrouter scheinen heute eine gewisse VPN-Unterstützung zu haben. Neben der Zentralisierung der VPN-Konfiguration, die Fehlerquellen reduziert, hat das den großen Vorteil, dass jedes Gerät den VPN nutzen kann, sobald es sich mit dem betreffenden WLAN verbindet.
      Ich nutze es so mit mehreren alten Routern, aber eigentlich scheint es auch einen Markt für ein Produkt zu geben, bei dem ein einzelner Heimrouter VPN-Verbindungen zu verschiedenen Standorten weltweit aufbaut und je Standort unterschiedliche WLAN-Netze bereitstellt. Der Zweck wäre, TV/Roku/iPad ohne Aufwand so erscheinen zu lassen, als würden sie aus einer anderen Region zugreifen
    • Dieser Angriff ist nur möglich, wenn sich im lokalen LAN ein nicht vertrauenswürdiges Gerät befindet. Wenn man bereits ein Gerät mit laufendem VPN-Gateway direkt mit sich herumträgt, sind nicht vertrauenswürdige LAN-Geräte wohl kein so großes Problem.
      Wenn sich allerdings ein nicht vertrauenswürdiges Gerät im LAN befindet und DHCP verwendet wird, kann dieses Gerät mit dieser Technik unverschlüsselten Traffic belauschen. Die echte IP kann es aber trotzdem nicht ermitteln, weil das Gateway sie verbirgt.
      Am realistischsten ist dieser Angriff in Situationen wie Café-WLANs. An solche Orte bringt man den eigenen Router eher selten mit.
      Mit „unverschlüsseltem Traffic“ ist hier Traffic gemeint, der nicht gekapselt ist, um an den VPN-Anbieter gesendet zu werden. Da heute meistens HTTPS verwendet wird, dürfte der Inhalt dieses Traffics selbst weiterhin verschlüsselt sein
    • Es wäre hilfreich, ein paar brauchbare Hardware- und Softwareoptionen aufzulisten
    • Die meisten Reiserouter dürften für dieses Problem weiterhin anfällig sein

  • Für technisch versierte Leute hätte das ziemlich offensichtlich sein sollen, aber als Einführung in Networking und VPNs ist es gut. Ich habe ein paar Mal Linux-VPN-Gateway-VMs eingerichtet, und eine Architektur, die sich nur auf die Routing-Tabelle verlässt, fühlte sich immer anfällig an, besonders wenn sie auf derselben Maschine läuft, die die Verbindung nutzt.
    Neben Netzwerk-Namespaces und physischen VPN-Gateway-Routern kann auch eine VM-basierte Architektur dieses Problem lösen. In meinem Homelab blockiert die Firewall unerwarteten Traffic, der aus der VPN-Gateway-VM kommt. Geräte im VPN-VLAN können sich nicht direkt nach außen verbinden, und die Gateway-VM hat ein separates VLAN für externe Verbindungen.
    Als persönliche Lösung ermöglicht QubesOS eine ähnliche Konfiguration mit vergleichsweise wenig Reibung, erfordert aber ebenfalls mehr technisches Wissen als ein normales Betriebssystem

  • Interessant ist die Aussage: „Android war als einziges nicht betroffen, weil es die Unterstützung für DHCP option 121 nicht implementiert hat“
    Ich frage mich, ob das eine bewusste Entscheidung von Google war, weil man das Problem kannte, oder ob es reiner Zufall war

    • Unter https://issuetracker.google.com/issues/117544989 sieht es so aus, als habe Google diese Feature-Anfrage größtenteils ignoriert, ohne Gründe zu nennen. Das frage ich mich auch. Ein Google-Mitarbeiter mit Zugriff auf den internen Buganizer weiß vielleicht mehr.
      Meine Vermutung ist, dass das Android-Networking-Team IPv6 gegenüber sehr aufgeschlossen ist. An obskuren Randfunktionen von IPv4 scheint man wenig Interesse zu haben. Auch für IPv6 scheint es eine bestimmte Vorstellung davon zu geben, wie es verwendet werden soll, was dazu führt, dass Funktionen wie zustandsbehaftetes DHCPv6 bewusst nicht unterstützt werden
    • Es gibt sehr viele DHCP-Optionen; bei Android ist es daher sinnvoll, zunächst nur ein Minimum zu unterstützen und zusätzliche Unterstützung erst zu aktivieren, wenn Bedarf für bestimmte Optionen aufkommt.
      Da diese DHCP-Option nicht häufig verwendet wird, ist es gut möglich, dass sie bei einer solchen Strategie unabhängig von Sicherheitsbedenken nicht unterstützt wurde
    • Android hat nicht einmal die neue DHCP-Version implementiert, die bereits vor 21 Jahren erstmals definiert wurde: https://www.rfc-editor.org/rfc/rfc3315
      Insofern ist das nicht besonders überraschend