Google hat mehrere Prototypen von Exploits ver\u00f6ffentlicht, die die M\u00f6glichkeit demonstrieren, Schwachstellen der Spectre-Klasse auszunutzen, indem JavaScript-Code im Browser ausgef\u00fchrt wird, um dabei zuvor implementierte Schutzmechanismen zu umgehen. Die Exploits k\u00f6nnen verwendet werden, um auf den Speicher des Prozesses zuzugreifen, der Webinhalt im aktuellen Tab verarbeitet. Zum Testen der Funktionsweise des Exploits wurde die Website leaky.page gestartet, und der Code, der die Logik beschreibt, wurde auf GitHub ver\u00f6ffentlicht. <\/p>\n
Der vorgeschlagene Prototyp ist f\u00fcr Angriffe auf Systeme mit Intel Core i7-6500U Prozessoren in einer Umgebung mit Linux und Chrome 88 ausgelegt. Um den Exploit in anderen Umgebungen anzuwenden, sind Anpassungen erforderlich. Die Ausnutzungsmethode ist nicht spezifisch f\u00fcr Intel-Prozessoren \u2014 nach entsprechender Anpassung wurde die Funktionsf\u00e4higkeit des Exploits auch auf Systemen mit CPUs anderer Hersteller, einschlie\u00dflich Apple M1 auf ARM-Architektur, best\u00e4tigt. Nach geringf\u00fcgigen Anpassungen funktioniert der Exploit ebenfalls in anderen Betriebssystemen und in anderen Browsern, die auf der Chromium-Engine basieren. <\/p>\n
In einer Umgebung basierend auf Standard-Chrome 88 und Intel Skylake-Prozessoren gelang es, Daten aus dem Prozess, der f\u00fcr die Verarbeitung von Webinhalten im aktuellen Chrome-Tab zust\u00e4ndig ist (Renderer-Prozess), mit einer Rate von 1 Kilobyte pro Sekunde auszulesen. Zus\u00e4tzlich wurden alternative Prototypen entwickelt, zum Beispiel ein Exploit, der die Stabilit\u00e4t verringert, aber die Auslesegeschwindigkeit auf bis zu 8 kB\/s erh\u00f6ht, indem der performance.now()-Timer mit einer Genauigkeit von 5 Mikrosekunden (0,005 Millisekunden) verwendet wird. Zudem wurde eine Variante vorbereitet, die mit einem Timer von einer Millisekunde Genauigkeit arbeitet und genutzt werden kann, um den Speicher eines anderen Prozesses mit einer Rate von etwa 60 Byte pro Sekunde auszulesen. <\/p>\n
Der ver\u00f6ffentlichte Demonstrationscode besteht aus drei Teilen. Der erste Teil kalibriert den Timer, um die Ausf\u00fchrungszeit der Operationen zu bewerten, die erforderlich sind, um Daten, die im Cache des Prozessors aufgrund spekulativer Ausf\u00fchrung von CPU-Anweisungen verbleiben, wiederherzustellen. Der zweite Teil ermittelt das Speichermapping, das bei der Platzierung des JavaScript-Arrays verwendet wird. <\/p>\n
Der dritte Teil nutzt die Spectre-Sicherheitsanf\u00e4lligkeit, um den Inhalt des Speichers des aktuellen Prozesses zu bestimmen, indem er Bedingungen f\u00fcr die spekulative Ausf\u00fchrung bestimmter Operationen schafft. Die Ergebnisse dieser Operationen werden vom Prozessor nach der Feststellung einer fehlerhaften Prognose verworfen, jedoch bleiben Spuren der Ausf\u00fchrung im gemeinsamen Cache und k\u00f6nnen durch Methoden zur Bestimmung des Cache-Inhalts \u00fcber Seitenkan\u00e4le rekonstruiert werden, welche die Zugriffszeit auf zwischengespeicherte und nicht zwischengespeicherte Daten analysieren. <\/p>\n
Die vorgeschlagene Ausbeutungstechnik erlaubt es, ohne hochpr\u00e4zise Timer auszukommen, die \u00fcber die API performance.now() verf\u00fcgbar sind, und ohne Unterst\u00fctzung f\u00fcr den Typ SharedArrayBuffer, der die Erstellung von Arrays im shared Memory erm\u00f6glicht. Der Exploit umfasst ein Spectre Gadget, das eine kontrollierte spekulative Ausf\u00fchrung von Code ausl\u00f6st, und einen Seitenkanalanalysator, der die im Cache befindlichen Daten identifiziert, die w\u00e4hrend der spekulativen Ausf\u00fchrung erlangt wurden. <\/p>\n
Das Gadget wird durch ein Array in JavaScript realisiert, das versucht, auf einen Bereich au\u00dferhalb der Puffergrenzen zuzugreifen, was den Zustand des Vorhersageblocks f\u00fcr Spr\u00fcnge beeinflusst, da der Compiler eine Gr\u00f6\u00dfen\u00fcberpr\u00fcfung des Puffers hinzuf\u00fcgt (der Prozessor f\u00fchrt spekulativ einen Zugriff aus, rollt aber den Zustand nach der \u00dcberpr\u00fcfung zur\u00fcck). F\u00fcr die Analyse des Cache-Inhalts unter Bedingungen unzureichender Timer-Genauigkeit wurde eine Methode vorgeschlagen, die die in Prozessoren verwendete Datenverdr\u00e4ngungsstrategie Tree-PLRU umgeht und es erm\u00f6glicht, durch die Erh\u00f6hung der Zyklen signifikant den Zeitunterschied beim Abrufen eines Wertes aus dem Cache und beim Fehlen eines Wertes im Cache zu vergr\u00f6\u00dfern. <\/p>\n
Es wird berichtet, dass Google einen Prototyp eines Exploits ver\u00f6ffentlicht hat, um die Realit\u00e4tsn\u00e4he von Angriffen unter Verwendung von Spectre-\u00e4hnlichen Schwachstellen zu demonstrieren und um Webentwickler zu ermutigen, Techniken anzuwenden, die die Risiken solcher Angriffe minimieren. Google ist der Ansicht, dass ohne erhebliche \u00dcberarbeitung des vorgeschlagenen Prototyps universelle Exploits, die nicht nur zur Demonstration, sondern auch f\u00fcr den allgemeinen Einsatz bereit sind, nicht erstellt werden k\u00f6nnen. <\/p>\n
Um das Risiko zu verringern, wird Website-Besitzern empfohlen, k\u00fcrzlich implementierte Header wie Cross-Origin Opener Policy (COOP), Cross-Origin Embedder Policy (COEP), Cross-Origin Resource Policy (CORP), Fetch Metadata Request, X-Frame-Options, X-Content-Type-Options und SameSite Cookie zu verwenden. Diese Mechanismen bieten keinen direkten Schutz vor Angriffen, erlauben jedoch, die Daten der Website von einer m\u00f6glichen Offenlegung in Prozessen zu isolieren, in denen JavaScript-Code von Angreifern ausgef\u00fchrt werden kann (diese Offenlegung erfolgt aus dem Speicher des aktuellen Prozesses, in dem neben dem Code des Angreifers m\u00f6glicherweise auch Daten einer anderen Website verarbeitet werden, die im selben Tab ge\u00f6ffnet ist). Die Hauptidee besteht darin, die Ausf\u00fchrung von Website-Code in unterschiedlichen Prozessen vom Code Dritter zu trennen, der aus unsicheren Quellen stammt, beispielsweise von Inhalten, die \u00fcber iframes eingebunden werden.
![\"Video](\"https:\/\/img.youtube.com\/vi\/V_9cQP60ZGI\/hqdefault.jpg\")
\r\n