Falk macht IT, Gadgets und Sport

Jetzt haben Apple ihren eigenen Meltdown. (GoFetch Lücke)

02.04.2024 10:19 Falk Dübbert

Vor zwei Wochen wurde die GoFetch-Lücke veröffentlicht. Der Unterschied zu bisherigen Lücken der Apple-Silicon-Chips ist, dass sie zuverlässig funktioniert, mit relativ wenig Code und ohne root-rechte auskommt.

• Die Apple-Silicon Architektur folgt einem extremen Ansatz. Im Wesentlichen gleicht Apple den Verzicht auf proprietäre Technologien durch bisher im Commodity-Bereich unbekannte Hardware-Designs, vermehrte spekulative Ausführung und intensives Caching aus. Dadurch rücken allerdings die Grenzen der Physik bedrohlich nah und lassen kaum Raum für Korrekturen zu.
• Apple hat eine mach-damit-was-Du-willst-Lizenz für den ARM-Befehlssatz und eine Design-Lizenz für den ursprünglichen ARMv8. Alle Sicherheitsfeatures, die ARM für den ARMv8R und ARMv9 entwickelte, hätte Apple selbst nachpflegen oder lizenzieren müssen.
  Da ARM sicher ein neues Preisschild an die Lizenzen für Designs durch Apple hängen würde, ist Apple diesen Weg nie gegangen. Die Sicherheitsfeatures der Apple Silicon Chips sind laut Patenten primär darauf ausgelegt, Authentizität sicher zu stellen. Apple folgt damit der Idee des „walled garden“, die in der Vergangenheit ein Grundpfeiler der Konzernphilosophie war. Apple sieht keinen vicious code, da Ausführbare aus Apples Sicht aus dem AppStore kommen sollen. Dass dieses Konzept an der Stelle „Internet“ zerbricht, wurde Apple erst zu spät klar.
• GoFetch ist entgegen meiner Überschrift kein Äquivalent von Spectre oder Meltdown. Das war die ebenfalls über 18 Monate ausgesessene Pacman-Schwachstelle GoFetch setzt an einer anderen Stelle an.
• Die DMP-Architektur (Data Memory-Dependent Prefetcher (DMP)) ist ein stochastisch organisierter Super-Cache, in dem Apple zu erraten versucht, was die CPU für eine Anwendung als nächstes brauchen könnte und war bereits mit Augury angezählt.
• Die Existenz von PACman, Augury und GoFetch und deren stochastische Ansätze zeigen in eine ungünstige Richtung. Die hohe Verdichtung und Integration der Apple-Silicon-Chips zeigt eine generelle Anfälligkeit für Seitenkanal-Angriffe an.

Seitenkanal-Angriff auf den Apple DMP

Ein Seitenkanal-Angriff ist ein Abgriff von Information auf einem Weg, der diese Information eigentlich nicht enthalten sollte.
Wenn man bei den den Nachbarn sieht, dass der Garten weiß geschmückt wird, Pavillions aufgebaut werden und ein Catering-Dienst Warmhalte-Wannen und Tische aufstellt, weiß man ziemlich sicher, dass eine Hochzeitsparty stattfinden wird, ohne eingeladen zu sein.

Der interessante Punkt ist, dass Joe hier alle Kondensatoren und Entstörspulen ablötet, um durch Injizieren eines Fehlers in die Stromversorgung eine SCA zu fahren. Die Analogie ist, dass je höher der Optimierungsgrad einer Architektur ist, Sicherheitsmaßnahmen gegen Störungen aus der Architektur verdrängt werden. Apple hat quasi das Auslöten für die Angreifer übernommen. Die Angreifer injizieren bei PacMan, Augury und GoFetch einen Speicherfehler und beobachten wie das System darauf reagiert. In einem Fall stoppen sie einfach die Zeit.
Das ist in etwa so, als würde man die im Lebenslauf behaupteten Chemiekenntnisse prüfen, in dem man den Praktikanten ins Lager schickt eine Flasche Heliumdioxid zu holen, in der Erwartung dass dieser einem eröffnet, dass man einen an der Klarinette hat.
Der DMP hat aber keine Möglichkeit, einen Fehler zurückzugeben und holt einfach irgendwas aus dem Lager in der Hoffnung dass man es gebrauchen könnte. Es ist sogar schlimmer, denn er sagt, wo er es her hat und was drin ist. Und wenn man es oft genug macht, erhält man so geheime Schlüssel für andere Programme oder gar die SSD-Verschlüsselung.

Tragweite

Im Gegensatz zu Augury ist GoFetch zu 99% erfolgreich und das umfasst auch Post-Quantum-Era-Encryption, auch wenn es dauert. Der Zeitbedarf ist aber nicht exponentiell größer mit steigender Schlüsselstärke, sondern nur linear bis quadratisch. Da es sich um primitiven C- und C++- Code handelt, ist dieser auch noch beliebig maskierbar. Signaturbasierte Ansätze wie Virenscanner scheiden somit aus.
Den DMP auszuschalten, geht erst ab dem Apple M3 und würde erfordern, dass eine Anwendung ein Bit setzt, wenn sie Vertraulichkeit benötigt und somit Leistung durch Sicherheit eintauscht. Problematisch sind somit vor allem Browser, allein alle Gaming- und Streaming Angebote wie Netflix brauchen Sicherheit und Leistung.
Ich gehe davon aus, dass Aussitzen für Apple diesmal keine Option ist, da die Lücke es auch in die normalen Nachrichten geschafft hat und der Code vermutlich auch in ein Javascript oder in HTML5 integrierbar ist. Für MacOS ist es nicht die erste Vertreibung aus dem Paradies. Apple muss mit der Apple Silicon Architektur nun die Schritte nachziehen, die Intel vor Jahren gehen musste und sie werden Leistung kosten.
Zusätzlich wird Apple vermutlich einen kleineren Antivirus-Anbieter schlucken und heuristische-AV-Funktionalität im Betriebssystem integrieren, die das Verhalten der Threads strenger beobachten und bei wiederholten DMP-Fehlern mit Thors Hammer auf selbige schlagen wird. Das sind jedoch unscharfe Lösungen und somit ein Rennen zwischen Hase und Igel und Apple muss sich die Frage gefallen lassen, ob sie die Integration und das Performance-Tuning zu weit getrieben ohne die erforderliche Erfahrung im CPU-Design angesammelt zu haben. Ich gehe davon aus, dass erst der M5 dazu ein vertikales Compartment haben wird, das wie beim ARMv9 sichere und unsichere Threads automatisch voneinander trennen kann. Der M4 dürfte zu weit fortgeschritten sein, um noch so eine wesentliche Änderung zu erhalten. Es wäre auch zu kurzfristig und würde den Abverkauf von M2-Geräten erschweren. Bis dahin bewahrheitet sich, dass der zweite Faktor einer Sicherheitslösung von unabhängiger Hardware kommen muss, so wie die PC-Welt (nicht die Zeitschrift!) es mit dem TPM oder anderen HSMs realisiert hat. Als MacOS User würde ich zunächst auf ein Apple-Statement warten und empfindliche Dinge wie Homebanking nicht einzig auf icloud-synchronisierte Passkeys basieren lassen.