iLeakage: Browserbasierter, timerloser Speculative-Execution-Angriff auf Apple-Geräte

 (ileakage.com)
1 Punkte von GN⁺ 2023-10-26 | 1 Kommentare | Auf WhatsApp teilen
  • Obwohl Spectre-Abwehrmaßnahmen seit rund sechs Jahren bestehen, zeigt iLeakage, dass sich Side Channels durch speculative execution in Safari auf Mac, iPad und iPhone weiterhin ausnutzen lassen
  • Angreifer können Nutzer dazu bringen, eine bösartige Webseite zu besuchen und anzuklicken, und Safari anschließend mit JavaScript und WebAssembly dazu veranlassen, beliebige Webseiten zu rendern, um sensible Informationen wiederherzustellen
  • Die Demonstrationen umfassen die Betreffzeilen aktueller Gmail-Nachrichten, automatisch ausgefüllte Instagram-Zugangsdaten, den YouTube-Wiedergabeverlauf sowie die Wiederherstellung eines Facebook-Passworts und eines SMS-2FA-Tokens auf einem MacBook Pro mit Apple M3
  • Betroffen sind macOS- und iOS-Geräte mit Apple-A-Series- und M-Series-CPUs; die Schwachstelle wurde in iOS 17.2 und macOS 14.2 mit Safari 17.2 entschärft
  • Lockdown Mode oder das Deaktivieren von JavaScript können den Angriff ebenfalls verhindern, schränken aber Funktionen ein; da der Angriff innerhalb von Safari läuft und keine Spuren in Systemlogs hinterlässt, ist er sehr schwer zu erkennen

Spectre-Risiko auf Apple-Geräten erneut sichtbar

  • iLeakage ist ein Side-Channel-Angriff durch speculative execution auf den Safari-Webbrowser
  • Ziel sind macOS- und iOS-Geräte mit Apples A-Series- oder M-Series-CPUs
    • Dazu gehören aktuelle iPhones und iPads
    • Ebenso Apple-Notebooks und -Desktops seit 2020
  • Eigentlich sollte Code in einem Browser-Tab den Inhalt anderer Tabs nicht erschließen können; iLeakage kann jedoch Inhalte einer Zielwebseite auslesen, wenn Nutzer die Angreiferseite besuchen und anklicken
  • Wiederherstellbare Informationen können personenbezogene Daten, Passwörter und Kreditkarteninformationen umfassen
  • Die Forschenden legten ihre Ergebnisse Apple am 12. September 2022 offen, 408 Tage vor der öffentlichen Veröffentlichung

Tatsächlich wiederhergestellte sensible Daten

  • Die Forschenden demonstrierten die Wiederherstellung von hochwertigen Informationen aus populären Diensten

  • Instagram-Zugangsdaten

    • Verwendet wurde ein Szenario in macOS Safari, in dem sich ein Nutzer mit dem Autofill-Credential-Manager von LastPass bei Instagram anmeldet

  • Gmail-Posteingang

    • Unter der Annahme, dass der Nutzer in iOS Safari bei Google angemeldet ist, wurden auf einem iPad die Betreffzeilen aktueller Nachrichten eines Gmail-Kontos wiederhergestellt

  • YouTube-Wiedergabeverlauf

    • Der YouTube-Wiedergabeverlauf wurde in Chrome für iOS wiederhergestellt
    • Chrome für iOS funktioniert aufgrund der Apple-App-Store-Richtlinien als Shell über der Safari-Browsing-Engine

  • Facebook-Passwort und 2FA-Token

    • In einer Umgebung mit einem MacBook Pro mit Apple-M3-Chip, macOS 14.1.1 und Safari 17.1 wurde zunächst das Facebook-Passwort wiederhergestellt
    • Anschließend wurde über Google Messages der per SMS an ein Android-Smartphone gesendete 2FA-Token wiederhergestellt

Funktionsweise von Spectre und Side Channels

  • Die meisten modernen CPUs nutzen speculative execution: Wenn das Ergebnis einer Verzweigung nicht sofort feststeht, sagen sie den Ausführungspfad voraus und verarbeiten die Befehle dieses Pfads vorab
  • Ist die Vorhersage falsch, macht die CPU Zustandsänderungen rückgängig; in mikroarchitektonischen Zuständen wie dem Cache können jedoch Spuren zurückbleiben
  • Spectre ist eine Hardware-Schwachstelle, die diese Spuren ausnutzt, um Daten zu lesen, auf die gemäß der ursprünglichen Programmlogik nicht zugegriffen werden dürfte
  • Side Channels können Eigenschaften der Systemimplementierung ausnutzen, selbst wenn ein Programm einen sicheren Algorithmus ausführt
    • Beispiele sind Schall, elektromagnetische Abstrahlung, Thermal Throttling und die gemeinsame Nutzung mikroarchitektonischer CPU-Ressourcen
  • Wenn Angreifer und Ziel auf derselben CPU laufen, teilen sie sich Ressourcen wie Kerne, Caches und interne Puffer; diese Konkurrenz kann indirekt über Variablen wie Timing oder Stromverbrauch gemessen werden

Timerlose Angriffskonstruktion zur Umgehung der Safari-Abwehr

  • Browseranbieter haben seit Spectre ihre Abwehr gegen speculative-execution- und transient-execution-Angriffe verstärkt
  • Zu Safaris Abwehrmaßnahmen gehören 35-bit addressing, value poisoning, eine Prozessisolierungsrichtlinie pro Tab und Timer mit niedriger Auflösung
  • iLeakage ist die erste Demonstration eines Speculative-Execution-Angriffs gegen Apple-Silicon-CPUs und Safari
  • Der Angriff beginnt mit der empirischen Rekonstruktion der nicht öffentlich dokumentierten Cache-Konfiguration von Apple-CPUs
    • Anschließend wird ein auf speculation basierendes Gadget gebaut, das Cache-Hits und -Misses auch nur mit Timern niedriger Auflösung unterscheiden kann
    • Auch eine Variante, die ohne Timer eine Race Condition nutzt, wurde demonstriert
  • Dieses Gadget wird sowohl für Tests zur Erzeugung von eviction sets als auch für den covert channel verwendet
  • Nach der Übertragung der Technik auf Safari wird Safari dazu gebracht, während speculative execution durch die CPU Code für bestimmte Datentypen auf vom Angreifer erzeugten Objekten falschen Typs auszuführen
  • Am Ende wird ein out-of-bounds read an beliebiger Stelle im Adressraum des Safari-Rendering-Prozesses möglich
  • Kombiniert mit einer neuen Methode, Websites verschiedener Domains im selben Adressraum zusammenzuführen, führt dies zu einem speculative type confusion-Angriff, der sensible Informationen preisgibt

Abhilfen, Erkennungsschwierigkeit und Auswirkungen je Browser

  • iLeakage wurde in Safari 17.2 entschärft; Safari 17.2 ist in iOS 17.2 und macOS 14.2 enthalten
    • Die Gegenmaßnahme besteht darin, Apple-Geräte auf die aktuelle OS-Version zu aktualisieren
  • Lockdown Mode entschärft iLeakage, indem er Safaris JIT-Kompilierung deaktiviert
    • JIT-Kompilierung ist eine Performance-Funktion, die iLeakage zum Aufbau der Angriffsprimitive nutzt
    • Lockdown Mode kann das Geräteverhalten ändern, etwa indem bestimmte Nachrichtenanhänge und FaceTime-Anrufe von unbekannten Personen blockiert werden
    • Die vollständige Liste steht in Apples Lockdown-Mode-Dokumentation
  • Auch das Deaktivieren von JavaScript verhindert iLeakage, kann aber dazu führen, dass Safari manche Websites fehlerhaft oder unvollständig rendert und fortgeschrittene Webfunktionen wie Online-Zahlungen nicht funktionieren
  • iLeakage läuft innerhalb von Safari und hinterlässt keine Spuren in Systemlogdateien, weshalb die Erkennung sehr schwierig ist
    • Spuren des Besuchs der Angreifer-Webseite können jedoch im Browser-Cache der zuletzt besuchten Seiten verbleiben
  • Es gibt keine Belege für eine Ausnutzung in der Praxis
    • Der End-to-End-Angriffsaufbau ist sehr schwierig und erfordert fortgeschrittenes Wissen über browserbasierte Side-Channel-Angriffe und die Safari-Implementierung
  • Die weitere Nutzung von Credential-Managern wird empfohlen
    • iLeakage kann automatisch in Webseiten eingetragene Zugangsdaten wiederherstellen
    • Viele Plattformen verlangen eine Nutzerinteraktion, damit Autofill erfolgt
  • Chrome, Firefox und Microsoft Edge unter macOS verwenden andere JavaScript-Engines; daher funktioniert iLeakage dort nicht, weil es Besonderheiten der Safari-JavaScript-Engine ausnutzt
  • Unter iOS verwenden aufgrund der Apple-App-Store- und Sandboxing-Richtlinien auch andere Browser-Apps die Safari-JavaScript-Engine
    • Chrome, Firefox und Edge für iOS sind Wrapper über Safari, die Zusatzfunktionen wie das Synchronisieren von Lesezeichen und Einstellungen bieten
    • Fast alle Browser-Anwendungen im App Store sind für iLeakage anfällig
  • Das wissenschaftliche Paper ist als iLeakage paper verfügbar und wurde auf der 2023 ACM Conference on Computer and Communications Security veröffentlicht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-10-26
Meinungen auf Hacker News

  • In dieser FAQ scheint etwas zu fehlen: Ich frage mich, ob das eine WebKit-Schwachstelle oder eine Safari-Schwachstelle ist, ob das Aktivieren des Lockdown Mode sie abmildert, da es in Mobile Safari diese Entwicklereinstellung nicht gibt, und wann Apple informiert wurde.
    Später wurde die Seite aktualisiert und die letzte Frage beantwortet: Die Forschenden haben Apple die Ergebnisse am 12. September 2022 offengelegt, 408 Tage vor der öffentlichen Veröffentlichung.

    • Technisch gesehen könnte man es als Hacker News Favorite Processor, also als M1/M2-Schwachstelle, betrachten, aber die relevanten CPUs auf dem aktuellen Markt haben alle dieselbe Verwundbarkeit, sodass es faktisch zu einer Eigenschaft geworden ist, für die Software Gegenmaßnahmen vorsehen muss.
      Es ist unrealistisch, in WebKit alle möglichen Spectre-Gadgets zu entfernen; deshalb müssen Browser die Spectre-Mitigationen des Betriebssystems nutzen, etwa indem sie verschiedene Websites in unterschiedliche Prozesse isolieren.
      Da in der FAQ steht, dass man „letztlich ein Out-of-Bounds-Read an beliebiger Stelle im Adressraum des Safari-Rendering-Prozesses erreicht“, würde ich persönlich es als Schwachstelle in der fehlerhaften Implementierung der Site-Isolation von Safari sehen.
    • Die letzte Frage ist in der FAQ beantwortet: Die Forschenden haben Apple die Ergebnisse am 12. September 2022 offengelegt, 408 Tage vor der öffentlichen Veröffentlichung.
    • Das sieht nach einer Architekturschwachstelle aus, bei der sich in Safari oder anderen Browsern ein Spectre-ähnlicher Seitenkanal über spekulative Ausführung ausnutzen lässt.
      In welchen Umgebungen sie ausnutzbar ist, hängt von den Implementierungsdetails der JavaScript-basierten Gadgets ab, die diesen Seitenkanal auslösen und messen; das könnte in dem Paper stehen, das ich noch nicht gelesen habe.
    • Inzwischen steht die Antwort in der FAQ: Es ist eine Safari-Schwachstelle, und dort heißt es: „iLeakage nutzt Eigenschaften der JavaScript-Engine von Safari aus.“
      Der Lockdown Mode wirkt als Mitigation, weil er in Safari die JIT-Kompilierung deaktiviert und damit die Performance-Funktionen blockiert, die iLeakage zum Erzeugen der Angriffsprimitive verwendet.

  • Auf die Frage „Ist es riskant, einen Credential Manager zu verwenden?“ antworten die meisten mit Nein, aber wenn aus dem Speicher etwas durchsickert, müsste das dann nicht den gesamten Speicher im Safari-Prozessraum betreffen?
    Ich kenne mich in diesem Bereich nicht gut aus und verstehe nicht ganz, warum die Nutzung eines Credential Managers eine Ausnahmebedingung sein soll.

    • Im Grunde scheinen sie Folgendes zu sagen: Er bietet keinen zusätzlichen Schutz gegen genau diesen Angriff, aber die Nutzung eines Passwortmanagers ist im Allgemeinen sicherer und macht einen auch nicht anfälliger für diesen Angriff.
      Sie wollen offenbar vermeiden, dass Leute wieder zu Dingen wie „newpassword2“ zurückkehren; sicherer ist es, AutoFill zu deaktivieren und die Felder per Tastenkürzel oder einer anderen Benutzerinteraktion auszufüllen.
    • Eine der Demos zeigte, wie die Benutzername/Passwort-Kombination einer Drittanbieter-Website wie Instagram wiederhergestellt wurde, weil der Passwortmanager die Felder automatisch ausgefüllt hatte und die Daten dadurch im Speicher lagen.
      Man könnte das so lesen, dass man immun ist, wenn man keinen Passwortmanager nutzt, nichts im Browser speichert und jedes Mal alles manuell eingibt, aber das ist aus mehreren Gründen kein gutes Gegenargument.
      Passwortmanager sind aus vielen anderen Gründen nützlich, und selbst wenn ein Passwort gestohlen wird, ist zumindest nur eine Website kompromittiert.
      Diese Technik kann vermutlich auch Session-Tokens stehlen; das ist zwar nicht ganz dasselbe wie Passwortdiebstahl, aber immer noch schlecht.
      Wenn man den Passwortmanager so konfiguriert, dass er erst nach einem Klick ausfüllt, lässt sich auch dieser Angriff verhindern.
    • Gemeint scheint zu sein, dass man durch die Nutzung eines Passwortmanagers nicht verwundbarer wird.
      Ein automatisch in eine Seite eingefügtes Passwort kann wie ein manuell eingegebenes Passwort wiederhergestellt werden, aber alle im Passwortmanager gespeicherten Passwörter lassen sich nicht direkt auslesen.
    • Ich verstehe diese Schwachstelle so, dass sie nur Zugriff auf den Speicher des betreffenden Safari/WebKit-Prozesses erlaubt, konkret auf Websites, die über einen window.open-Aufruf geöffnet wurden.
      Passwörter, die in einer separaten Passwortmanager-App gespeichert sind, sind nicht zugänglich, solange diese App sie nicht automatisch in ein kompromittiertes Safari-Fenster oder einen kompromittierten Prozess einfügt.
    • Nach meinem Verständnis legt Safari verschiedene Origins und Erweiterungen normalerweise in unterschiedliche Adressräume und ist daher nicht anfällig für Angriffe über spekulative Ausführung.
      Dieser Angriff hat einen Weg gefunden, zwei verschiedene Origins dazu zu bringen, denselben Adressraum zu teilen; auf Erweiterungen scheint er nicht anwendbar zu sein.
      Im Paper heißt es: „Wir zeigen eine neue Technik, die Safaris Site-Isolation-Richtlinie ausnutzt, sodass eine Angreiferseite nur über die JavaScript-API window.open eine beliebige Opferseite öffnen muss, damit beide den Adressraum teilen.“

  • Ich bin unsicher, ob das Framing als WebKit-spezifisch wirklich stimmt. Die Cache-Ausnutzung selbst wirkt allgemein, und im Zitat heißt es, man habe in Safari, Firefox und Tor nahezu perfekte Genauigkeit erzielt.
    Außerdem frage ich mich, ob der Angriff über window.open() wirklich WebKit-spezifisch ist oder ob diese Studie WebKit nur besonders gründlich untersucht hat.
    window.open() deutet einen gemeinsamen Kontext an: Das aufrufende Fenster erhält eine Referenz auf das neue Fenster, und das neue Fenster hat über window.opener eine Rückreferenz. Da frage ich mich, ob andere Browser-Engines wirklich vollständige Isolation erreichen.

    • Chromium und Firefox haben in ihren Desktop-Browsern Site-Isolation implementiert, sodass Seiten, die nicht zur selben Site gehören, nicht im selben Prozess geladen werden sollten.
      In mobilen Browsern ist Chromiums Site-Isolation eingeschränkt, und Firefox hat die Implementierung noch nicht abgeschlossen.
      https://www.chromium.org/Home/chromium-security/site-isolati...

  • Verwirrend. Das sieht nach einem Problem mit hoher Schwere aus, aber der Fix steckt hinter einem Debug-Menü. Ich verstehe nicht, warum das veröffentlicht wurde, bevor es ordentlich überall ausgerollt wurde.
    Außerdem zeigt es, dass Side-Channel-Abhilfen praktisch nutzlos sind und man nicht so tun sollte, als seien solche Angriffe behoben.
    Auf einem Host, der auf modernen CPUs mehrere Anwendungen ausführt, ist es nicht sicher, nicht vertrauenswürdigen Code auszuführen, egal wie stark man ihn sandboxt.

    • Apple hatte offenbar über 400 Tage Zeit, das zu beheben, und damit schon länger, als ich ihnen gegeben hätte.
      Es ist meiner Meinung nach viel besser, die Risiken bekannt zu machen, als Apple-Nutzer noch ein weiteres Jahr oder länger unwissend gefährdet zu lassen.
      Ich bin dafür, Unternehmen Zeit zu geben, Bugs zu beheben, aber ab einem gewissen Punkt ist es unverantwortlicher, die Betroffenen nicht zu informieren.
    • Der Stand der Mitigationen verwirrt mich auch, aber das Paper ist klarer als die Website.
      Das Paper erklärt, dass ein spekulativer Ausbruch aus der JavaScript-Sandbox weiterhin möglich ist, der Angreifer aber auf seinen eigenen Adressraum und das Lesen seiner eigenen Daten beschränkt wird.
      Zum Zeitpunkt der Erstellung sei Apples Patch öffentlich und in Safari Technology Preview 173 oder höher implementiert gewesen; [57] ist https://github.com/WebKit/WebKit/pull/10169.
      Darunter verlinkt ein Engineer weitere Hardening-Patches zu window.open() und Prozessisolierung.
    • Ich dachte, in Safari 17.0 Standard unter Ventura sei Swap Processes on Cross-Site Window Open bereits aktiviert und als Stable markiert.
      Ich hatte es nicht selbst eingeschaltet und dachte daher, Apple habe es vielleicht schon aktiviert und die Beschreibung sei veraltet; später stellte sich aber heraus, dass ich auf das ähnlich benannte Swap Processes on Cross-Site Navigation geschaut hatte, und derzeit scheint es standardmäßig nicht aktiviert zu sein.
    • Weil Apple, das sich als „letzte Bastion für Datenschutz und Sicherheit“ darstellt, das über 400 Tage liegen ließ und nicht behoben hat.
      Man sollte eher Apple dafür verantwortlich machen, so lange untätig gewesen zu sein, als die Forschenden, die es vor der Auslieferung des Fixes veröffentlicht haben.
    • Dieser Fix musste vermutlich das Prozessmodell von WebKit ändern und steckt deshalb vor dem vollständigen Rollout noch hinter einem Debug-Menü, während er getestet wird.
      Nicht alle Side-Channel-Angriffe sind behoben, aber zu sagen, Side-Channel-Abhilfen seien nutzlos, ist unangemessen.
      Auch mit Sicherheitsgurt sterben Menschen bei Autounfällen, aber das macht Sicherheitsgurte nicht nutzlos; Mitigationen erhöhen den Aufwand für die Ausnutzung erheblich.

  • Es heißt: „Die Forschenden haben Apple die Ergebnisse am 12. September 2022 offengelegt“ – ich frage mich wirklich, warum Apple das über ein Jahr fast liegen gelassen hat.

    • Weil sie es können.
      Apple ist einer der CVE-Machtakteure und kann die Vergabe von CVEs für die eigenen Produkte verweigern; mit dieser Macht kann man sich so viel Zeit lassen, wie man will.

  • Ich meine, auf der iLeakage-Website einen Hinweis zum Fix gesehen zu haben, aber er ist verschwunden. Ich dachte erst, ich hätte mich getäuscht, aber die Website wurde tatsächlich innerhalb der letzten Stunde geändert.
    Dort stand sinngemäß: „Apple hat gerade iOS 17.1, iPadOS 17.1 und macOS Sonoma 14.1 veröffentlicht, also aktualisiert eure Geräte“, und jetzt wurde das zurückgenommen.
    https://github.com/ileakage-authors/ileakage-authors.github....

    • Einer der Autoren des Papers scheint diesen Thread zu lesen.
      Nachdem ich darauf hingewiesen hatte, dass es auf der Website keinen Offenlegungszeitplan gibt, wurde der FAQ ein kurzer Abschnitt hinzugefügt; da der Stand der Fix-Auslieferung verwirrend ist, scheinen nun auch die Forschenden mitverwirrt zu sein.
    • Seltsam. Nach dem Update auf iOS 17.1 gibt es unter Settings -> Safari -> Advanced -> Feature Flags Swap Processes on Cross-Site Navigation, und es ist standardmäßig aktiviert.
      Ich frage mich, ob das etwas anderes ist als Swap Processes on Cross-Site Window Open unter macOS.

  • Die Formulierung „iLeakage ist ein Angriff, der bis zum Ende ziemlich schwer auszuführen ist und fortgeschrittenes Wissen über browserbasierte Side-Channel-Angriffe und die Safari-Implementierung erfordert“ könnte der Grund sein, warum Apple sich nicht besonders darum kümmert.

    • Das klingt so, als sei er so schwer auszuführen, dass er praktisch unmöglich ist und das reale Risiko effektiv nahe 0 % liegt.
      Noch ein gruseliger Spitzname samt Domainname wirkt weder professionell noch vertrauenswürdig.

  • Wenn macOS- oder iOS-Geräte mit Apple-A- oder M-Series-CPU betroffen sind, also aktuelle iPhones/iPads sowie Apple-Laptops und -Desktops seit 2020, dann bin ich als seltener Intel-Mac-Nutzer wohl nicht betroffen.

    • Wahrscheinlich bist du doch betroffen.
      Die Cache-Hierarchie ist nur etwas anders, und der Proof of Concept bräuchte vermutlich kleinere Änderungen.
    • Unter macOS kann man einfach Safari nicht verwenden.
      Unter iOS muss man den Lockdown Mode nutzen; das ist die einzige Möglichkeit, ein iPhone sicher zu verwenden.
      Benchmarks ohne Lockdown Mode sollte man als genauso nutzlos betrachten wie CPU-Benchmarks mit mitigations=off.

  • Ein weiterer guter Grund, auf iOS-Geräten andere Browser-Engines zuzulassen.

    • Die EU-Regulierung könnte Apple am Ende dazu zwingen.

  • Wenn beim Ausführen des folgenden Befehls ein Fehler auftritt, erteile dem Terminal Full Disk Access und versuche es erneut.
    defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1