AW: Spectre und Meltdown: Intels Sicherheitsteam arbeitet noch immer an Lösungen
Ich bin mir nicht ganz sicher, wie weit die PoC für JS fortgeschritten sind. Spectre-Angriffe in JS zu schreiben ist deutlich schwerer wegen der zwischengeschalteten Interpreter. Aber wenn wir eins aus Spectre gelernt haben, dann: Nur weil man etwas noch nicht weiß oder es aufwendig erscheint, heißt das noch lange nicht, dass es unmöglich ist und es noch niemand versucht hat.
Prinzipiell greifen primäre Spectre-Angriffe jedenfalls mit missbrauchtem Target-Code aus dem Adressraum des Targets auf den Adressraum des Targets zu. Solange eine Anwendung nicht geschützt ist, ist ihr Adressraum also in Gefahr – unabhängig davon, in welchem Adressraum der Code des Angreifers läuft. Der Browser selbst ist natürlich eines der attraktivsten Ziele überhaupt und für JS-Angriffe das naheliegenste. Aber wenn man ein Return-Gadget kennt, mit dem man auch via Javascript einen Rückkanal aufbauen kann, dann kann man prinzipiell alles angreifen.
Dieser Angriff ist in der Tat zu langsam für nennenswerten Nutzen und er beschäftigt sich nur mit Angriffen auf den Adressraum des Browsers. Aber wie kann man ausschließen, dass es weitere Möglichkeiten gibt?
Der physische RAM spielt keine Rolle. Durchsucht werden muss der gesamte virtuelle Adressraum, der war auch schon früher zu groß für einen Komplett-Downland. Aber sobald man ein Element gefunden hat, dass man kennt und dass eine feste Position relativ zu interessanten Daten einnimmt (zum Beispiel weil die angegeriffene Anwendung ihre Programmbestandteile in einer bestimmten Reihenfolge lädt) muss nur noch dieser potenziell interessante Bereich durchsucht werden. So werden aus TiB KiB. Ein großer physischer RAM kann hier sogar von Vorteil sein, wenn er auch intensiv genutzt wird – einen Speer im Heuhaufen findet man schneller als eine Nadel.
Regelmäßiges schließen und öffnen des Browsers ist übrigens tatsächlich eine gute Sicherheitsmaßnahme gegen Javascript-basierte Angriffe und Reboots gegen alle anderen Formen (wenn die Angreiferanwendung nicht im Autostart steht). Die Beobachtung der Browser-Auslastung ist in Zeiten fordernder erwünschter Scripte und vor allem Werbemittel dagegen ein Balance-Spiel. Technisch versierte und aufmerksame Anwender könnten einen starken Angriff erkennen. Aber die meisten Anwender bemerken es nachweislich nicht einmal, wenn der Browser im Hintergrund Kryptowährungen für jemand anderen schürft. Diese Nutzer würden auch bei einem Spectre-Angriff nicht misstrauisch werden.
Die hohe Spezifizität von Spectre-Attacken ist tatsächlich der stärkste Schutz vor diesen, aber sie erspart dem Angreifer auch die meisten der genannten Schritte. Wer einen Angriff auf zum Beispiel Steam, Itunes oder andere beliebte, oft im Hintergrund laufende Programme mit Account-Verknüpfung ausführen möchte, der trainiert die CPU explizit für deren Code. Wenn das Programm tatsächlich läuft, ergeben sich daraus Informationen – wenn nicht, dann war der Rechner halt kein geeignetes Ziel. Der Angreifer muss aber nicht wissen, wo im physischen Speicher das Opfer tatsächlich liegt, weil er dieses selbst dazu bringt, seine Geheimnisse zu verraten. Und ihren eigenen Adressraum kennen Anwendungen naturgemäß gut; der Angreifer wiederum kennt den verwendeten Hidden Channel und damit die Strukturen, aus denen er die Informationen rekonstruiert, weil er sie selbst definiert hat. Schutz gibt es also nur, wenn man allen anfälligen Code aus allen potenziellen Opfern entfernt hat oder wenn man alle Rückkanäle in allen potenziellen Ausführumgebungen (z.B. JS) für Angreifer-Code schließt. Da werden aber immer wieder neue gefunden und dritte, beispielsweise Sicherheitstools, Firewalls, Viren-Scanner, Sandboxen und ähnliche können sonst nur nach verdächtigen Aktivitätsmustern Ausschau halten und Alarm schlagen. Zur Schadensbegrenzung helfen sie in etwas so gut wie eine physische Mauer gegen einen Hubschrauber.
Ich bin mir nicht ganz sicher, wie weit die PoC für JS fortgeschritten sind. Spectre-Angriffe in JS zu schreiben ist deutlich schwerer wegen der zwischengeschalteten Interpreter. Aber wenn wir eins aus Spectre gelernt haben, dann: Nur weil man etwas noch nicht weiß oder es aufwendig erscheint, heißt das noch lange nicht, dass es unmöglich ist und es noch niemand versucht hat.
Prinzipiell greifen primäre Spectre-Angriffe jedenfalls mit missbrauchtem Target-Code aus dem Adressraum des Targets auf den Adressraum des Targets zu. Solange eine Anwendung nicht geschützt ist, ist ihr Adressraum also in Gefahr – unabhängig davon, in welchem Adressraum der Code des Angreifers läuft. Der Browser selbst ist natürlich eines der attraktivsten Ziele überhaupt und für JS-Angriffe das naheliegenste. Aber wenn man ein Return-Gadget kennt, mit dem man auch via Javascript einen Rückkanal aufbauen kann, dann kann man prinzipiell alles angreifen.
Dieser Angriff ist in der Tat zu langsam für nennenswerten Nutzen und er beschäftigt sich nur mit Angriffen auf den Adressraum des Browsers. Aber wie kann man ausschließen, dass es weitere Möglichkeiten gibt?
Der physische RAM spielt keine Rolle. Durchsucht werden muss der gesamte virtuelle Adressraum, der war auch schon früher zu groß für einen Komplett-Downland. Aber sobald man ein Element gefunden hat, dass man kennt und dass eine feste Position relativ zu interessanten Daten einnimmt (zum Beispiel weil die angegeriffene Anwendung ihre Programmbestandteile in einer bestimmten Reihenfolge lädt) muss nur noch dieser potenziell interessante Bereich durchsucht werden. So werden aus TiB KiB. Ein großer physischer RAM kann hier sogar von Vorteil sein, wenn er auch intensiv genutzt wird – einen Speer im Heuhaufen findet man schneller als eine Nadel.
Regelmäßiges schließen und öffnen des Browsers ist übrigens tatsächlich eine gute Sicherheitsmaßnahme gegen Javascript-basierte Angriffe und Reboots gegen alle anderen Formen (wenn die Angreiferanwendung nicht im Autostart steht). Die Beobachtung der Browser-Auslastung ist in Zeiten fordernder erwünschter Scripte und vor allem Werbemittel dagegen ein Balance-Spiel. Technisch versierte und aufmerksame Anwender könnten einen starken Angriff erkennen. Aber die meisten Anwender bemerken es nachweislich nicht einmal, wenn der Browser im Hintergrund Kryptowährungen für jemand anderen schürft. Diese Nutzer würden auch bei einem Spectre-Angriff nicht misstrauisch werden.
Die hohe Spezifizität von Spectre-Attacken ist tatsächlich der stärkste Schutz vor diesen, aber sie erspart dem Angreifer auch die meisten der genannten Schritte. Wer einen Angriff auf zum Beispiel Steam, Itunes oder andere beliebte, oft im Hintergrund laufende Programme mit Account-Verknüpfung ausführen möchte, der trainiert die CPU explizit für deren Code. Wenn das Programm tatsächlich läuft, ergeben sich daraus Informationen – wenn nicht, dann war der Rechner halt kein geeignetes Ziel. Der Angreifer muss aber nicht wissen, wo im physischen Speicher das Opfer tatsächlich liegt, weil er dieses selbst dazu bringt, seine Geheimnisse zu verraten. Und ihren eigenen Adressraum kennen Anwendungen naturgemäß gut; der Angreifer wiederum kennt den verwendeten Hidden Channel und damit die Strukturen, aus denen er die Informationen rekonstruiert, weil er sie selbst definiert hat. Schutz gibt es also nur, wenn man allen anfälligen Code aus allen potenziellen Opfern entfernt hat oder wenn man alle Rückkanäle in allen potenziellen Ausführumgebungen (z.B. JS) für Angreifer-Code schließt. Da werden aber immer wieder neue gefunden und dritte, beispielsweise Sicherheitstools, Firewalls, Viren-Scanner, Sandboxen und ähnliche können sonst nur nach verdächtigen Aktivitätsmustern Ausschau halten und Alarm schlagen. Zur Schadensbegrenzung helfen sie in etwas so gut wie eine physische Mauer gegen einen Hubschrauber.
Zuletzt bearbeitet:
