Spectre beschreibt Angriffsszenarien, bei denen Prozesse durch Sicherheitslücken in Mikroprozessoren mit out-of-order execution Informationen des virtuellen Speichers, auf die sie keinen Zugriff haben sollten, auslesen.
Die Angreifer umgehen Sicherheitsmechanismen wie Sandboxing oder die Trennung zwischen Programmcode und vom Benutzer bereitgestelltem Code (z. B. Interpreter vs. Skript). Während der out-of-order execution des Prozessors wird vorläufig der Inhalt einer Speicherzelle aus dem eigenen Adressraum ausgelesen, auf die der aufrufende Prozess normalerweise nicht zugreifen könnte. Das „vorläufige Auslesen“ hinterlässt im Cache eine von außen bemerkbare Spur, auch nachdem das Ergebnis der spekulativen Ausführung verworfen wurde.
Geschichte Spectre wurde unabhängig voneinander durch Forscher von Googles Project Zero so wie von Paul C. Kocher in Zusammenarbeit mit Daniel Genkin, Mike Hamburg, Moritz Lipp und Yuval Yarom entdeckt und am 3. Januar 2018 in Zusammenhang mit der verwandten Sicherheitslücke Meltdown veröffentlicht, nachdem die betroffenen Software- und Hardware-Hersteller bereits am 1. Juni 2017 informiert worden waren.Meltdown and Spectre: ‘worst ever’ CPU bugs affect virtually all computers. In: theguardian.com, 4. Januar 2018. Entdeckt wurde die Sicherheitslücke Spectre, gemeinsam mit Meltdown, auf der weit verbreiteten x86-Architektur von Intel und AMD, wobei auch andere Architekturen als verwundbar gelten.
Über acht Jahre nach der Entdeckung der Sicherheitslücke hat ein Team der ETH Zürich die Ausnützung der Variante Spectre V2 bei der Virtualisierung, wie sie unter Linux mit QEMU u. a. bei Cloud-Anbietern vorzufinden ist, festgestellt. Dass die ansonsten bereits gepatchte Lücke hier immer noch ausgenutzt werden kann, ist auf ungenügende Trennung zwischen Wirt und Gast zurückzuführen. Diese VMScape getaufte Variante wurde in den Linux-Kernel-Versionen 6.16.7, 6.12.47, 6.6.106, 6.1.152, 5.15.193 und 5.10.244 von September 2025 geschlossen.
Betroffene Prozessoren Theoretisch anfällig sind alle Prozessoren, die speculative execution branch prediction, im Besonderen mit indirect branching bieten.
Nicht von der Sicherheitslücke Spectre betroffen sind x86-Prozessoren vor 1995 und jene ohne speculative execution oder ohne out-of-order execution, etwa Atom-Prozessoren vor 2013, sowie die Itanium-Architektur von Intel und HP.
Am 4. Januar 2018 bestätigte AMD die Anfälligkeit bisheriger Prozessoren gegenüber Spectre V1, sprach bei Spectre V2 aber von einem „Risiko nahe Null“, da noch kein erfolgreicher Angriff über Variante 2 von Spectre belegt sei.
Apple, IBM und Motorola entwickelten ab 1991 PowerPC-Prozessoren auf Basis der IBM-POWER-Architektur. Da diese spekulative Ausführungen vorsieht, ist ein Großteil aller PowerPC- und POWER-Prozessoren anfällig. Tests ergaben, dass ältere Prozessoren der Modellreihe G3 (PPC750) und G4 (nur PPC7400 bzw. 7410) in der Praxis nicht anfällig sind, spätere Modelle ab PPC7450 – G4 744x und 745x sowie PowerPC G5 (PPC970) – und der POWER6 jedoch schon. IBM bestätigte die Anfälligkeit von POWER7+, POWER8 und POWER9.
Prozessoren von MIPS sind teilweise betroffen, etwa die Modelle P5600 und P6600 von 2013.
Auch Prozessoren von Oracle mit der von Sun entwickelten SPARC-Architektur sind von Spectre betroffen. Fujitsu veröffentlichte Updates für Server mit den Prozessoren SPARC64 XII und SPARC64 X+. Ältere Prozessormodelle wie SPARC64 VI enthalten ebenfalls Sprungvorhersage.
Prozessoren mit Arm-Architektur können anfällig sein, wie die SoCs Snapdragon 845 von Qualcomm oder einige Modelle der Tegra-Serie von Nvidia.nvidia.custhelp.comnvidia.custhelp.comnvidia.custhelp.comnvidia.custhelp.com Auch von Apple produzierte Arm-Prozessoren, der Apple A11, sind anfällig. Aufgezählt werden alle Geräte, auf denen iOS als Betriebssystem läuft, etwa das iPad oder das Apple TV, in denen besagte Arm-Prozessoren verbaut sind.Arm-Prozessoren mit in-order execution sind nicht betroffen, das sind etwa Arm Cortex-A7- und -A53-Designs wie sie im Raspberry Pi verwendet werden.
Apple bestätigte ebenfalls die Anfälligkeit aller 2018 aktuellen Mac-Modelle (früher Macintosh), die x86-Prozessoren von Intel nutzen und somit auch von Meltdown betroffen sind. In älteren Macs verwendete Apple von 1994 bis 2006 PowerPC-Prozessoren, die wie oben beschrieben ebenfalls teilweise anfällig sind.
Grafikprozessoren sind von Spectre nicht betroffen. Die wegen Spectre z. B. von Nvidia veröffentlichten aktualisierten Grafiktreiber sollten lediglich Angriffe durch spekulative Befehlsausführung auf x86-Prozessoren vermeiden, die Teile der Treibersoftware sind.
Wirkungsweise und Auswirkungen Angriffe mittels Spectre-Lücke erfordern wie bei der Meltdown-Lücke, dass der Prozessor out-of-order execution unterstützt. Hierbei führt der Prozessor manche Befehle spekulativ aus, um eine hohe Effizienz zu erzielen. Nach der Idee der out-of-order execution ist der Zustand des Prozessors selbst bei Fehlspekulation so, als wäre der Befehl nie ausgeführt worden. Die Spectre-Angriffe nutzen aus, dass sich der Zustand des Systems an bestimmten Punkten doch verändert, obwohl das Ergebnis der spekulativen Ausführung verworfen wird. Diese Veränderungen, z. B. das Laden einer Speicherseite in den Cache, dienen als verdeckter Kanal, um Information aus dem Adressraum des angegriffenen Prozesses auszuschleusen. Der empfangende Prozess dekodiert die übermittelte Information aus den Veränderungen im System und kann sie damit lesen.
Mit Varianten des ursprünglichen Spectre-Angriffs liest man nicht nur unbefugt den Speicher aus, sondern erhält auch andere geschützte Informationen. Mit der Lazy FP State Restore Variante aus dem Spectre-NG-Satz kann man Fließkommaregister auslesen. Dies ist brisant, da manche Verschlüsselungsprogramme in diesen Registern private Schlüssel speichern.
Bei einem Angriff lässt man bestimmte vom Angreifer eingebrachte Befehle spekulativ ausführen, z. B. durch Return Oriented Programming unter Ausnutzung eines Pufferüberlaufs oder mit einem vom Angreifer bereitgestellten und vom Benutzer ausgeführten Programm (z. B. in einer interpretierten Skriptsprachen wie JavaScript). Hierbei kann die Spectre-Lücke ausgenutzt werden, um Informationen aus dem Adressraum des ausführenden Interpreters, wie bspw. des Webbrowsers, zu extrahieren. Dabei kann ein Angreifer über ein von einem Webserver geladenes bösartiges JavaScript Passworte aus dem Passwortspeicher des Webbrowsers auslesen.
Die Autoren demonstrierten ein Szenario, in dem ein Programm den Inhalt einer Zeichenkette oder einer beliebigen Speicherstelle des eigenen Adressraums ausgibt, ohne direkt über den Zeiger auf die Zeichenkette zuzugreifen. Als Auslöser für die spekulative Ausführung diente eine bewusst falsch herbeigeführte Sprungvorhersage. Auch indirekte Sprünge, bei denen Cache-Misses zu spekulativer Ausführung von sonst nicht ausgeführtem Code führen, ermöglichen den Angriff.
Der demonstrierte Angriff (Spectre V1) unter Ausnutzung einer fehlerhaften Sprungvorhersage funktioniert wie folgt:
Kommentierter Beispielcode: #define PAGESIZE 4096 unsigned int array1_size = 16; uint8_t array1 = { 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 }; uint8_t array2[256 * PAGESIZE]; uint8_t temp; void victim_function(size_t x) { if (x < array1_size) { // Dieser Vergleich wird für die fehlerhafte Sprungvorhersage ausgenutzt temp &= array2[array1[x] * PAGESIZE]; // Der Zugriff auf array2[] lädt eine Seite in den Cache, deren Adresse // vom Inhalt von array1[x] abhängt. Das ist der verdeckte Kanal.
Zunächst wählt der Angreifer eine Speicherstelle p und berechnet deren Offset x_m bezüglich des von ihm kontrollierten Arrays array1. Dann trainiert er die Sprungvorhersage des Prozessors für den Sprung in Zeile 7 so, dass der Prozessor annimmt, dass die Bedingung vorzugsweise zutrifft, indem er victim_function sehr oft mit Werten aus dem Intervall 0...15 aufruft. Anschließend beeinflusst der Angreifer den Cache des Systems so, dass der Wert von array1_size nicht im Cache vorhanden ist, während der Inhalt der auszulesenden Speicherstelle im Cache vorhanden ist. Nun führt er den Code mit x=x_m aus. Die Bedingung in Zeile 7 wird also nicht zutreffen. Da array1_size nicht im Cache vorhanden ist, wird der Prozessor den nachfolgenden Code spekulativ ausführen, während array1_size aus dem Speicher geladen wird, denn die zuvor gelernte Sprungvorhersage geht von einer zutreffenden Bedingung aus. array1[x_m] zeigt nun auf p. Dessen Inhalt wird spekulativ geladen, zu einer Seitenadresse umgerechnet und die entsprechende Seite aus array2 zum Laden in den Cache vorgemerkt. array1_size wurde aus dem Speicher geladen und der Prozessor stellt fest, dass die spekulativ ausgeführten Anweisungen zu verwerfen sind. Dabei verbleibt eine einzelne Seite aus array2 abhängig vom Inhalt der Speicherstelle p im Cache. Anschließend analysiert der Angreifer, welche Seiten aus array2 in den Cache geladen wurden, und schließt daraus auf den Inhalt der Speicherstelle p zurück.
Varianten CVE-Nr. Name Ausgenutzter Mechanismus Angriff Microcode CVE-2017-5715 Spectre V2 Branch Target Injection (BTI) Spekulative Sprungvorhersage für indirekte Sprünge ja CVE-2017-5753 Spectre V1 Bounds Check Bypass Spekulative Lesezugriffe mit indirekter Adressierung CVE-2018-3693 Spectre V1.1 Bounds Check Bypass Store Spekulative Lesezugriffe, bevor Schreibzugriffe bestätigt sind ja n. a. Spectre V1.2 Read-only Protection Bypass Spectre NG CVE-2018-3640 Spectre V3a Rogue System Register Read (RSRE) Spekulative Lesezugriffe auf Systemregister ja CVE-2018-3639 Spectre V4 Speculative Store Bypass (SSB) Spekulativer Schreibzugriff außerhalb des gültigen Bereichs CVE-2018-3665 n. a. Lazy FP State Restore Spekulativer Zugriff auf Gleitkommaregister CVE-2018-3615 n. a. Foreshadow (L1 Terminal Fault – SGX)Christof Windeck: Angriff auf die Cloud heise.de, ct Ausgabe 19/2018, am 31. August 2018. ja CVE-2018-3620 n. a. L1 Terminal Fault – OS Kernel, SMM ja CVE-2018-3646 n. a. L1 Terminal Fault – Virtual Machines ja Varianten via Return Stack Buffer (RSB) n. a. Spectre V5 ret2spec n. a. n. a. SpectreRSB Return Mispredict weitere Varianten CVE-2018-9056 n. a. Branch Scope n. a. n. a. SGXPectre n. a. n. a. NetSpectren. a.n. a. Spectre-STC (Single-Threaded Contention)Verzögerungen beim Zugriff auf gemeinsam genutzte Ressourcen (bspw. ALU-Einheiten) gibt Aufschluss über geschützte DatenCVE-2025-40300VMScapeBranch Target Injection (BTI) bei der Virtualisierung, die durch ungenügenden Trennung der Sprungvorhersage (engl. ) zwischen Host und Gast ermöglicht wird, z. B. bei QEMU unter Linux. Durch zwischen Host und Gast wird die Lücke geschlossen. wie Spectre V2
Schadensminderung