Eine Gruppe von Forschern der Vrije Universiteit Amsterdam hat mehrere neue Spectre-v2-Sicherheitsanfälligkeiten entdeckt, die unter dem Codenamen Training Solo veröffentlicht wurden und es ermöglichen, die Mechanismen der Speicherisolation zu umgehen. Im Kontext von Virtualisierungssystemen erlauben die Anfälligkeiten, den Inhalt des Speichers der Host-Umgebung aus Gast-Systemen zu ermitteln, und im Kontext von Servern, den Inhalt des Speichers des Kernels bei der Ausführung eines Exploits im Benutzerspeicher zu bestimmen. Beispiele für Exploits zum Durchführen solcher Angriffe sind auf GitHub veröffentlicht. Die vorgestellten Exploits ermöglichen es, beliebige Daten aus dem Kernel-Speicher mit einer Geschwindigkeit von 17 KB/s und aus dem Hypervisor-Speicher mit 8,5 KB/s zu extrahieren.
Bei Spectre-v2-Angriffen wird zur Organisierung eines Datenlecks eine Wertsetzung im Branch Target Buffer oder im Branch History Buffer eingesetzt, die zur Vorhersage der nächsten Branch-Operation verwendet werden. Durch Manipulation der Branch-Historie entstehen Bedingungen für falsche Vorhersagen bei spekulativer Abarbeitung von Anweisungen. Die Aufgabe des Angreifers besteht darin, dass bei der Abarbeitung einer spekulativen Branch-Operation die Zieladresse aus dem gewünschten Speicherbereich entnommen wird. Nach dem spekulativen Übergang bleibt die aus dem Speicher gelesene Adresse im Cache des Prozessors zurück (in Form einer Adresse werden die für den Angreifer benötigten Daten aus dem Speicher gelesen). Um Informationen aus dem Cache zu extrahieren, kann eine der Methoden zur Bestimmung des Cache-Inhalts basierend auf der Analyse der Zugriffszeiten zu gecachten und ung gecachten Daten verwendet werden.
Die Angriffsmethoden Training Solo zielen darauf ab, die Mechanismen zur Isolation von Ausführungsbereichen (Domain Isolation) zu umgehen, wie IBPB, eIBRS und BHI_NO, die eingesetzt werden, um Angriffe der Klasse Spectre-v2 zu blockieren. Beispielsweise sorgt die IBPB-Anweisung (Indirect Branch Prediction Barriers) dafür, dass der Zustand des Vorhersageblocks bei jedem Kontextwechsel zurückgesetzt wird — sei es beim Wechsel zwischen Benutzermodus und Kernel oder zwischen einem Gastsystem und der Hostumgebung. Das Zurücksetzen des Zustands blockiert die Möglichkeit, eigenen Code zu nutzen, um das Verhalten des Blocks für indirekte Sprungvorhersagen zu beeinflussen.
Die Unterschiede der Training Solo-Methoden bestehen darin, dass zur Beeinflussung des Übergangsprognoseblocks vorgeschlagen wird, keinen kontrollierten Angreifercode auszuführen, sondern bereits vorhandenen Code auf der privilegierten Ausführungsseite (Kernel oder Hypervisor) zu nutzen, aus dessen Leak der Angreifer profitiert. Ansonsten ähneln die Methoden einem klassischen Spectre-v2-Angriff. Darüber hinaus haben die Forscher zwei Hardwareprobleme (CVE-2024-28956 und CVE-2025-24495) identifiziert, die es ermöglichen, die Isolation der Ausführungsbereiche vollständig zu umgehen undLeaks aus Prozessen anderer Benutzer, anderer Gastbetriebssysteme oder der Hostumgebung zu realisieren.
Es wurden drei Arten von Training Solo-Angriffen vorgeschlagen:
- Verzerrung der Logik der Vorhersage von Sprüngen durch den Aufruf bereits im Kern vorhandener Befehlsfolgen (Gadgets), die den Inhalt des Verlaufsbuffers beeinflussen. Als solche Gadgets wird der Zugriffskontrollmechanismus für Systemaufrufe SECCOMP vorgeschlagen, der es ermöglicht, durch substitution eigene BPF-Filter einen falschen indirekten Sprung im spekulativen Modus zu erzielen (Filter in SECCOMP werden mittels klassischem cBPF festgelegt, welches standardmäßig aktiviert ist, im Gegensatz zu eBPF). Bei Tests auf Intel Tiger Lake und Lion Cove betrug die Geschwindigkeit des Lecks bei Verwendung dieser Methode 1,7 KB/s.
- Verwendung von IP-Kollisionen (Instruction Pointer) im Sprungvorhersageblock. Ein Angreifer kann Bedingungen schaffen, unter denen die Adresse für den spekulativen Sprung nur basierend auf der bereits im Buffer vorhandenen Sprungadresse ausgewählt wird, ohne die Historie der Sprünge zu berücksichtigen. Die Idee ist, dass eine indirekte Sprungoperation eine andere beeinflussen kann, wenn eine Kollision bei der Speicherung ihrer Adress-Hashes im BTB (Branch Target Buffer) auftritt.
- Der Einfluss direkter Sprünge auf die Vorhersage indirekter Sprünge. Dieses Verhalten wird durch zwei Hardware-Schwachstellen verursacht: CVE-2024-28956 — ITS (Indirect Target Selection) und CVE-2025-24495 — ein Problem mit CPUs von Intel mit Lion Cove-Kernen. Die Geschwindigkeit der Datenleckage aus dem Speicher bei Verwendung dieser Methode betrug 17 KB/s. Im demonstrierten Exploit zur Bestimmung des Hashes des root-Benutzers, der nach dem Aufruf des Befehls «passwd -s» im Speicher gespeichert wurde, wurden 60 Sekunden aufgewendet.
Der Angriff, der den Buffer mit der Historie der Sprünge verzerrt, betrifft alle Intel-CPUs, die den eIBRS-Mechanismus unterstützen, einschließlich Intel CPUs der Coffee Lake- und Lion Cove-Generation. Um die Schwachstelle zu schließen, hat Intel ein Mikrocodes-Update mit der Implementierung der neuen Anweisung IBHF (Indirect Branch History Fence) veröffentlicht, die nach dem Code angegeben werden sollte, der den Sprunghistorienbuffer beeinflusst. Für ältere Intel-CPUs wird empfohlen, eine Softwaremethode zur Bereinigung der Sprunghistorie zu verwenden. Im Linux-Kernel wurde eine Änderung angenommen, die sowohl Software- als auch Hardware- Schutzmaßnahmen gegen, die mit cBPF durchgeführt werden. AMD hat erklärt, dass diese Angriffsmethode auf ihren CPUs nicht wirkt. ARM teilte mit, dass das Problem nur ältere ARM-Prozessoren betrifft, die anfällig für Spectre-v2-Angriffe sind und die Erweiterungen FEAT_CSV2_3 und FEAT_CLRBHB nicht unterstützen.
Die Schwachstelle Indirect Target Selection (ITS, CVE-2024-28956) betrifft Intel Core CPUs der 9. bis 11. Generation (Cascade Lake, Cooper Lake, Whiskey Lake V, Coffee Lake R, Comet Lake, Ice Lake, Tiger Lake und Rocket Lake) sowie Intel Xeon CPUs der 2. bis 3. Generation. Die Schwachstelle CVE-2025-24495 tritt bei CPUs auf, die auf den Mikroarchitekturen Lunar Lake und Arrow Lake basieren. Die Probleme wurden mit dem gestrigen Mikrokode-Update behoben. Eine Änderung wurde in den Linux-Kernel aufgenommen, die das Problem durch das Auslagern von indirekten Sprüngen an den oberen Teil des Cache-Strings blockiert.
Quelle: opennet.ru
