MSI AMD Game Bundle

Zusammenfassung: ret2spec, SpectreRSB, Spectre 1.1, NetSpectre

reported by doelf, Montag der 30.07.2018, 13:13:02 Uhr

Spectre, Spectre und kein Ende: Zuerst variierte Spectre 1.1 (CVE-2018-3693) den ursprünglichen Angriff von spekulativen Lese- zu Schreibzugriffen, dann nutzten gleich zwei Forscherteams manipulierte Rücksprungadressen im "Return Stack Buffer" (RSB) und zum Abschluss der vergangenen Woche zeigte NetSpectre, wie man Daten aus der Ferne ohne eigenen Schadcode abfischen kann.

Spectre 1.1 (CVE-2018-3693): Schreiben statt Lesen
Kurz vor dem Bekanntwerden von ret2spec und SpectreRSB hatten Vladimir Kiriansky (MIT) und Carl Waldspurger (Carl Waldspurger Consulting) eine neue Variante des ersten Spectre-Angriffs publiziert (PDF-Datei). Während es sich bei Spectre 1.0 (CVE-2017-5753) und spekulative Lesezugriffe mit indirekter Adressierung handelt, stellt Spectre 1.1 (CVE-2018-3693) einen spekulativen Schreibzugriff mit indirekter Adressierung dar. Befehle wir lfence oder csdb, welche gegen Spectre 1.0 eingesetzt werden, bleiben dabei wirkungslos. Als Gegenmaßnahme empfehlen Kiriansky und Waldspurger eine neue Schutzfunktion namens SLoth, welche sie in ihrem Papier auch erläutern.

ret2spec: Neue Erkenntnisse aus dem Saarland
Giorgi Maisuradze und Christian Rossow vom "Center for IT-Security, Privacy and Accountability" (CISPA) der Universität des Saarlands haben zwei Varianten RSB-basierter Angriffe (ret2spec) vorgestellt. Sie nutzen eine fehlerhafte Vorhersage der Rücksprungadresse, welche im "Return Stack Buffer" (RSB) abgelegt wird. Dann wird die spekulative Ausführung auf eine bekannte oder - besser noch - vom Angreifer kontrollierte Code-Sequenz umgeleitet. Der Abgriff der Daten erfolgt dann, wie bei den anderen Spectre-Varianten, mit Hilfe von Cache-Manipulationen. Sind die bereits verfügbaren Spectre-Updates für Betriebssysteme installiert, wird auch ret2spec unterbunden. Allerdings bleiben auch dann JIT-Umgebungen (Just-in-time-Kompilierung) verwundbar, wie Maisuradze und Rossow konnten mit JIT-kompilierten Code (JavaScript und WebAssembly) im Webbrowser nachweisen konnten: Sie konnten Speicherbereiche außerhalb der Sandbox auslesen - und das mit einer Erfolgsquote von 80 Prozent. Um dies zu verhindern, müssen die JIT-Kompiler gehärtet werden, wahlweise mit Hilfe der Befehle lfence und mfence oder über eine entsprechende Umsetzung von Retpoline.

Intel, AMD und ARM, Microsoft und Redhat sowie Apple, Google, Microsoft und Mozilla wurden im April 2008 über die RSB-Angriffe informiert. Intel hat die Schwachstellen bestätigt, während AMD und ARM zumindest ein generelles Problem sehen. Mozilla und Google wollen ihre Webbrowser mit Hilfe unscharfer Zeitnahmen weiter absichern und auch Microsoft und Redhat haben diese Angriffe im Blick. Seitens Apple gab es im Laufe der drei Monate gar keine Reaktion.

SpectreRSB: Ähnliche Erkenntnisse aus Kalifornien
Das Team vom "Computer Science and Engineering Department" der University of California, Riverside (Esmaiel Mohammadian Koruyeh, Khaled Khasawneh, Chengyu Song und Nael Abu-Ghazaleh) hat unter dem Oberbegriff "SpectreRSB" mehrere Angriffsvarianten - "Angriff im selben Prozess", "Angriff über zwei kollidierende Threads (User-Space)", "Angriff über zwei kollidierenden Threads (Kernel-Space)", "Angriffe über die Prozessgrenze hinaus", "Angriffe auf SGX" (Intel Software Guard Extensions) und "Angriff vom User- auf den Kernel-Space" - beschrieben. Dabei zeigte sich, dass lfence, IBRS, STUBP, IBPB und Retpoline die Angriffe nicht verhindern konnten. Lediglich das Auffüllen des RSB und SMEP/SMAP sorgten in einigen Varianten für Abhilfe. Eine Lösung für Angriffe innerhalb des selben Prozesses oder Angriffe auf SGX bieten diese Maßnahmen allerdings auch nicht. Die Amerikaner hatten Intel, AMD und ARM vorab informiert. Ihre Tests fanden, genau wie bei ihren Kollegen aus Deutschland, allerdings nur auf Prozessoren von Intel statt.

NetSpectre: Variante 1.0 über das Netzwerk
Kurz nach den RSB-basierten Angriffen veröffentlichten vier Forscher - Michael Schwarz, Martin Schwarzl, Moritz Lipp und Daniel Gruss - der Technischen Universität Graz eine weitere Untervariante von Spectre 1.0. Die Wissenschaftler aus Österreich nutzen für ihren Angriff Netzwerkpakete, welche im ständigen Wechsel gültig oder fehlerhaft sind. Damit trainieren sie den Prozessor des Opfers auf fehlerhafte Spekulationen und messen die Antwortzeiten. Der Abgriff von Daten erfolgt nicht durch eigenen Code, sondern über die Netzwerk-Software bzw. die Gerätetreiber, ist aber sehr langsam. Im Schnitt benötigten die Forscher eine halbe Stunde pro Byte, konnten diese Zeit unter Nutzung von AVX aber auf acht Minuten reduzieren. Im Prinzip schützen die Maßnahmen gegen Spectre 1.0 auch vor NetSpectre. Zudem würde es helfen, in die Reaktionszeit für Netzwerkantworten eine Unschärfe einzubauen, welche ein genaues Timing unterbindet.

Reaktionen der CPU-Hersteller
ARM hat seine Meltdown-/Spectre-Informationen als erste CPU-Schmiede aktualisiert. Spectre 1.1, ret2spec und SpectreRSB finden sich dort im Whitepaper, auf der Übersichtsseite ist allerdings nur Spectre 1.1 ersichtlich. Hierauf bezieht sich auch AMDs Eintrag vom 13.07.2018. Bezüglich der RSB-Angriffe gibt es seitens AMD noch keine Reaktion. Intels Informationen datieren indes noch auf den 23. Mai 2018 - wie war das nochmal mit "Security first"? Eine Reaktion auf NetSpectre bietet derzeit noch kein Prozessor-Hersteller.

Diese Werbefläche wurde deaktiviert. Damit geht Au-Ja.de eine wichtige Einnahmequelle verloren.

Werbung erlauben ]