AMD, Intel & ARM: Spectre geht weiter um

Zwei neue Spectre-Schwachstellen betreffen AMDs Prozessoren mit Zen-1- und Zen-2-Architektur. Gegenmaßnahmen von Intel und ARM sind wirkungslos.

Artikel veröffentlicht am 11. März 2022, 15:21 Uhr, Johannes Hiltscher

Vereinfachte Darstellung: Sprungvorhersage in modernen CPUs (Bild: Wikimedia Commons/CC0 1.0)

In regelmäßigen Abständen tauchen weitere Varianten der Schwachstelle Spectre auf. Aktuell wurden zwei neue bekannt. Eine fand Sicherheitsforscher Pawel Wieczorkiewicz von Open Source Security, die zweite veröffentlichte (PDF) eine Forschergruppe aus den Niederlanden. Der Grund ist auch diesmal die spekulative Befehlsausführung von Prozessoren.

Wieczorkiewicz entdeckte eine Spectre-v1-Variante in der Sprungvorhersage von AMDs Prozessoren mit Zen-1- und Zen-2-Mikroarchitektur. Die Details sind in zwei sehr ausführlichen Blogartikeln dokumentiert. Die niederländische Gruppe stellte fest, dass sich in aktuellen Intel- und ARM-Prozessoren integrierte Maßnahmen gegen Spectre-v2 umgehen lassen.

Bei der Spectre-v1-Variante führen die betroffenen Prozessoren nach unbedingten Sprungbefehlen mit fester Zieladresse stehenden Code spekulativ weiter aus. Betroffen sind die Befehle JMP, CALL und RET, welche so zur Ausleitung von Kerneldaten nutzbar sind.

Dies ist, wie Entdecker Wieczorkiewicz selbst schreibt, sehr unerwartet. Alle Daten liegen vor, eigentlich gibt es keinen Grund, Befehle nach den Sprunganweisungen weiter auszuführen. Allerdings ist bei ARM ähnliches Verhalten als Straight-Line Speculation bekannt. Da die betroffenen Anweisungen sehr häufig vorkommen, steigt die Zahl der potenziell für Angriffe nutzbaren Codesequenzen.

Der Grund liegt in einer Heuristik der Sprungvorhersage. Diese nutzt unter anderem den Branch Target Buffer (BTB), welcher die Adressen von Sprungzielen speichert. Jeder Sprung, für den kein Eintrag im BTB existiert, wird als nicht ausgeführt angenommen. Dies wendet das Frontend der Prozessoren, welches Befehle aus dem Speicher holt und die Sprungvorhersage enthält, auf alle Sprungbefehle an. So werden auch die oben genannten Sprünge übergangen, die immer ausgeführt werden.

Unvollständige Gegenmaßnahmen bei Intel und ARM

Bei Spectre-v2 hingegen steuert eine Anwendung die spekulative Ausführung einer höheren Prioritätsebene (Kernel oder Hypervisor) gezielt in eine bestimmte Richtung. Dies wird als Branch Target Injection (BTI) bezeichnet und sollte durch Hardware-Maßnahmen in neueren Intel- und ARM-Prozessoren verhindert werden. Allerdings fand das niederländische Forscherteam Lücken in der Umsetzung. Betroffen sind Intels Prozessoren der Generationen zehn bis zwölf sowie Cascade- und Ice-Lake-Xeons, bei ARM Cortex A76 und X1.

Die Hardware-Gegenmaßnahmen versagen, da sie nicht auf alle Sprung-Caches wirken. Sie sollen verhindern, dass Sprungbefehle einer Anwendung sich auf eine höhere Prioritätsebene auswirken. Zwar sind die Einträge des BTB isoliert, der Branch History Buffer (BHB) wird jedoch weiterhin für alle Prioritätsebenen genutzt.

Den BHB nutzt die Sprungvorhersage, um bei bedingten Sprüngen den spekulativ ausgeführten Pfad auszuwählen. Da der BHB weiterhin von einer Anwendung manipuliert werden kann, lässt sich der privilegierte Code auf einen gewünschten spekulativen Pfad schicken. Das Forscherteam wählte daher die Bezeichnung Branch History Injection (BHI).

Einordnung und Gegenmaßnahmen

Die gefundenen Schwachstellen sind beide kompliziert auszunutzen. Auch die Rate, mit der Daten ausgelesen werden können, ist bei beiden gering. So stuft beispielsweise Suse beide Schwachstellen als moderat ein.

AMDs Prozessoren lassen sich zwar durch Löschen des BTB gezielt in den anfälligen Zustand bringen. Allerdings können nur wenige Befehle ausgeführt werden, da die spekulative Ausführung schnell beendet wird. Der Zugriff auf Daten ist sehr eingeschränkt, da diese entweder in einem Register oder im Store-Buffer liegen müssen.

AMD schlägt Abhilfen vor (PDF), sie erhöhen jedoch entweder die Codemenge oder verringern die Leistung. Hinter JMP und RET kann mittels wirkungsloser Anweisungen wie INT3 aufgefüllt werden, um das Spekulationsfenster zu schließen. Für CALL existieren verschiedene Lösungen, da einige mit bestimmten Konventionen zum Funktionsaufruf Probleme bereiten. Die einfachste ist, die spekulative Ausführung mittels LFENCE zu verbieten, dies kostet allerdings viel Leistung.

Als Maßnahme gegen BHI schlagen die Entdecker vor, wieder auf Retpoline zu setzen, dies sei die Maßnahme mit den geringsten Leistungseinbußen. Außerdem sollte die Möglichkeit, nutzerkontrollierten Code in den Kernel einzuspeisen, auf privilegierte Nutzer beschränkt werden. Der extended Berkeley Packet Filter (eBPF) beispielsweise erlaubt dies, wodurch gezielt Schwachstellen im Kernel installiert werden können.