Eine Gruppe von Forschern der Vrije Universiteit Amsterdam hat mehrere neue Spectre-v2-Schwachstellen identifiziert, die unter dem Codename Training Solo veröffentlicht wurden und die es ermöglichen, Mechanismen zur Speicherisolierung zu umgehen. Im Kontext von Virtualisierungssystemen erlauben diese Schwachstellen, den Inhalt des Host-Speichers aus Gastbetriebssystemen zu entschlüsseln, während sie im Kontext von Servern den Inhalt des Kernel-Speichers beim Ausführen eines Exploits im Benutzermodus preisgeben können. Beispiele für Exploits zur Durchführung 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 Datenleckage die Manipulation von Werten im Branch Target Buffer oder dem Branch History Buffer verwendet, die für die Vorhersage der nächsten Verzweigungsoperationen zuständig sind. Durch Manipulationen an der Historie der Übergänge werden Bedingungen für Fehlvorhersagen bei spekulativer Ausführung von Anweisungen geschaffen. Das Ziel des Angreifers ist es, bei der spekulativen Verzweigungsoperation die Adresse für den Übergang aus dem gewünschten Speicherbereich zu entnehmen. Nach der Ausführung des spekulativen Übergangs verbleibt die aus dem Speicher gelesene Übergangsadresse im Prozessorcache (die benötigten Daten des Angreifers werden unter dem Vorwand der Adresse gelesen). Zur Extraktion von Informationen aus dem Cache kann ein Verfahren verwendet werden, das den Inhalt des Caches anhand der Analyse der Zugriffszeiten auf zwischengespeicherte und nicht zwischengespeicherte Daten bestimmt.
Die Methoden des Angriffs Training Solo zielen darauf ab, Mechanismen zur Isolierung von Ausführungsbereichen, wie IBPB, eIBRS und BHI_NO, zu umgehen, die zur Blockierung von Angriffen der Spectre-v2-Klasse eingesetzt werden. Beispielsweise sorgt der Befehl IBPB (Indirect Branch Prediction Barriers) dafür, dass der Zustand des Vorhersageblocks für Übergänge bei jedem Kontextwechsel – beim Wechsel der Kontrolle zwischen Benutzer- und Kernel-Modus oder zwischen Gast- und Hostumgebung – zurückgesetzt wird. Das Zurücksetzen des Zustands blockiert die Möglichkeit, eigenen Code zur Beeinflussung des Verhaltens des Vorhersageblocks für indirekte Sprünge zu verwenden.
Die Methoden von Training Solo unterscheiden sich darin, dass zur Beeinflussung des Vorhersageblocks für Sprünge kein vom Angreifer kontrollierter Code ausgeführt wird, sondern bereits vorhandener Code aus dem privilegierten Ausführungsbereich (Kernel oder Hypervisor) verwendet wird, den der Angreifer ausnutzt. Ansonsten ähneln die Methoden einem klassischen Spectre-v2-Angriff. Darüber hinaus haben die Forscher zwei Hardware-Probleme (CVE-2024-28956 und CVE-2025-24495) identifiziert, die es ermöglichen, die Isolation der Ausführungsbereiche vollständig zu umgehen und Lecks aus Prozessen anderer Benutzer, anderer Gastsysteme oder der Host-Umgebung zu realisieren.
Es werden drei Arten von Angriffen im Training Solo vorgeschlagen:
- Verzerrung der Logik zur Vorhersage von Sprüngen durch den Aufruf bereits existierender Befehlsequenzen (Gadgets) im Kernel, die den Inhalt des Sprunghistorienpuffers beeinflussen. Als solche Gadgets wird ein Zugriffsbeschränkungsmechanismus für Systemaufrufe (SECCOMP) vorgeschlagen, der es ermöglicht, durch Substitution eigener BPF-Filter einen falschen indirekten Sprung im spekulativen Modus zu erreichen (Filter in SECCOMP werden mit klassischem cBPF gesetzt, das standardmäßig aktiviert ist, im Gegensatz zu eBPF). Bei Tests auf CPUs von Intel Tiger Lake und Lion Cove betrug die Leckrate bei Verwendung dieser Methode 1,7 KB/s.
- Verwendung von IP-Kollisionen (Instruction Pointer) im Block zur Vorhersage von Sprüngen. Der Angreifer kann Bedingungen schaffen, unter denen die Adresse für den spekulativen Sprung nur auf Basis der bereits im Puffer vorhandenen Sprungadresse ausgewählt wird, ohne die Sprunggeschichte zu berücksichtigen. Die Idee ist, dass eine indirekte Sprungoperation eine andere beeinflussen kann, wenn es eine Kollision bei der Speicherung der Hashes ihrer Adressen im BTB (Branch Target Buffer) gibt.
- Verwendung des Einflusses 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 Intel-CPUs der Lion Cove-Kerne. Die Leckrate von Daten aus dem Speicher bei Verwendung dieser Methode betrug 17 KB/s. Im demonstrierten Exploit zur Ermittlung des Passwort-Hashes des Benutzers root, das nach dem Aufruf des Befehls „passwd -s“ im Speicher gespeichert war, wurden 60 Sekunden benötigt.
Alle Intel CPUs, die den eIBRS-Mechanismus unterstützen, einschließlich Intel Coffee Lake und Lion Cove, sind anfällig für Angriffe, die den Verlauf des Branch-History-Puffers verzerren. Um die Schwachstelle zu beheben, hat Intel ein Mikrocode-Update mit der neuen Anweisung IBHF (Indirect Branch History Fence) veröffentlicht, die nach dem Code, der den Branch-History-Puffer beeinflusst, angegeben werden sollte. Für ältere Intel CPUs wurde ein Softwareansatz zur Bereinigung des Branchverlaufs empfohlen. Im Linux-Kernel wurde eine Änderung angenommen, die eine Software- und Hardware-Lösung hinzufügt Schutzmaßnahmen gegen Angriffe, die unter Verwendung von cBPF umgesetzt werden. AMD gab an, dass der Angriffsmethode bei ihren CPUs nicht funktioniert. ARM berichtete, dass das Problem nur ältere ARM-Prozessoren betrifft, die anfällig für Spectre-v2-Angriffe sind und die FEAT_CSV2_3- und FEAT_CLRBHB-Erweiterungen 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 im gestrigen Mikrocode-Update behoben. Eine Änderung wurde im Linux-Kernel angenommen, die das Problem durch das Verschieben von indirekten Sprüngen an den oberen Rand des Cachezeilen adressiert.
Quelle: opennet.ru
