Meltdown und Spectre. Verständlich erklärt

Meltdown und Spectre

„Dann sind wir performancemäßig wieder am Ende der 90er“

Wir haben mit einem der Entdecker von Meltdown und Spectre gesprochen. Er erklärt, was spekulative Befehlsausführung mit Kochen zu tun hat und welche Maßnahmen Unternehmen und Privatnutzer ergreifen sollten.

Daniel Gruß kennt sich mit Sicherheitslücken in Hardware aus. Gemeinsam mit anderen hat er bereits Sicherheitslücken in DRAM-Modulen aufgedeckt, die sogenannten Rowhammer-Bitflips. Auch an der Forschung zu den CPU-Sicherheitslücken Meltdown und Spectre war er mit anderen Forschern der TU Graz und Jann Horn von Googles Project Zero beteiligt.

Daniel Gruß erzählt im Interview von seinen Forschungen zu Meltdown und Spectre.

Daniel Gruß erzählt im Interview von seinen Forschungen zu Meltdown und Spectre. (Bild: Helmut Lunghammer/TU Graz mit freundlicher Genehmigung)

Gruß gibt im Interview mit Golem.de über Meltdown und Spectre Entwarnung für Privatnutzer. Diese müssten derzeit wenig fürchten, wenn sie ihr Betriebssystem auf dem aktuellen Stand halten und die Meltdown-Patches von Microsoft, Apple oder im Linux-Kernel installieren. Denn obwohl die Spectre-Lücken schwieriger zu schließen sind als Meltdown, gibt es für Letzteres bereits erste Exploits.

Viele der mit Spectre und Meltdown bekanntgewordenen Probleme werden uns nach Meinung unseres Experten über die kommenden Jahre begleiten. Es gäbe zwar Möglichkeiten, die Sicherheitsprobleme etwa durch die komplette Deaktivierung der Branch-Prediction komplett zu verhindern. Doch dann, so Gruß, würden wir von der Performance her dort landen, wo wir Ende der 90er waren.

Golem.de: In einfachen Worten: Welche Funktionsweisen von Prozessoren nutzen die Sicherheitslücken aus, die Ihr Team gefunden hat?

Daniel Gruß: Eigentlich ist das wie beim Kochen: Es passiert mir häufiger, dass ich dabei das ganze Rezept durchgehe und ganz am Ende steht dann „Jetzt mit Reis servieren“. Und dann denke ich: Ich habe noch gar keinen Reis gekocht. Dann habe ich einfach nicht weit genug vorausgeschaut. Der Prozessor hat ein ähnliches Problem.

Deswegen startet er schon mal alle Prozesse, die parallel laufen können. Bei der spekulativen Befehlsausführung zieht der Prozessor also Berechnungen vor, die er aktuell noch nicht machen müsste, aber später brauchen könnte. Das führt aber dazu, dass am Ende auch Ergebnisse berechnet werden, die er letztlich gar nicht braucht, weil es in den Programmen Verschachtelungen und Alternativen gibt. Manchmal will ich eventuell was Vegetarisches kochen, mal was mit Fleisch. Ich als Mensch kann meist beurteilen, was ich am Ende benötige. Der Prozessor hingegen führt einfach stur Befehle aus und versucht, möglichst viel spekulativ auszuführen. Das können Angreifer ausnutzen.

Das zweite, was wir ausnutzen, ist das Caching von Informationen. Das kommt beim Kochen genauso vor. Wenn ich Kartoffeln kochen will, dann muss ich die natürlich vorher einkaufen – und das dauert lange. Und dann komm ich zurück und mir fällt auf, dass ich auch Karotten brauche – dann muss ich schon wieder zum Geschäft, und das dauert dann natürlich wieder sehr lang. Deswegen ist es clever, dass ich die Kartoffeln oder Karotten, die ich nicht gebraucht habe, lokal einlagere, etwa im Kühlschrank oder einem Kasten, so dass ich sie nachher immer griffbereit habe, wenn ich was Ähnliches zubereite.

Der Prozessor macht eigentlich genau das Gleiche. Der holt sich Daten aus dem langsameren Arbeitsspeicher und speichert sie in seinem Cache zwischen. Und da sind sie immer abrufbereit für neue Arbeitsaufträge. Das sind die beiden Effekte, die wir ausnutzen.

Erst Befehle ausführen, dann Fehlermeldungen prüfen

Golem.de Wie genau werden die Effekte bei Meltdown ausgenutzt?

Gruß: Bei Meltdown nutzen wir die spekulative Befehlsausführung und sagen dem Prozessor, dass er auf ein Geheimnis zugreifen soll, auf das wir eigentlich nicht zugreifen dürften. Ein Geheimnis, das irgendwo im Adressbereich des Betriebssystems liegt. Das wird der Prozessor erstmal machen, aber er wird dann auch merken, dass wir das gar nicht dürfen, und wird uns letztlich daran hindern. Durch die spekulative Ausführung haben wir das Ergebnis aber schon vorher bekommen.

Was der Prozessor nicht verhindern kann: Ich kann dieses Geheimnis, das ich ausgelesen habe, als Index nutzen, um auf eine andere Speicherstelle zuzugreifen. Diese andere Speicherstelle kommt in den Prozessorcache. Damit lerne ich den Index, auf den die spekulative Ausführung zugegriffen hat. Und dieser Index war am Ende genau das Geheimnis. Ich weiß also das Geheimnis, weil ich den Index gelernt habe.

Golem.de: Und wie ist das bei Spectre?

Gruß: Bei Spectre ist die Grundidee relativ ähnlich. Aber hier gehe ich nicht über die Grenze hinweg, dass ich auf etwas nicht zugreifen darf. Da ist es so, dass ich bei Javascript einen Boundscheck, also die korrekte Prüfung meine Anfrage, habe, und da greife ich auf etwas zu, auf das ich tatsächlich zugreifen darf. Normalerweise würde aber eine andere Funktion verhindern, dass ich darauf zugreife. In Javascript habe ich zum Beispiel einen Boundscheck, wenn ich auf einen Array zugreife. Da wird überprüft, ob das noch im Array liegt oder schon dahinter. Wenn der Test fehlschlägt, wird das Array entweder vergrößert oder ich bekomme einen Fehler.

Mit Spectre ist es so, dass der Zugriff darauf spekulativ erst einmal erfolgt, ohne Fehlermeldung. Erst danach stellt der Prozessor fest, dass das eigentlich gar nicht hätte passieren dürfen. Das bedeutet: Bei Meltdown greife ich immer den eigenen Adressraum an, obwohl Dinge eigentlich nicht zugreifbar sind. Bei Spectre sorge ich dafür, dass ein anderes Programm, etwa Javascript, für mich auf etwas zugreift, das ich nicht selbst vollständig kontrollieren kann. Am Ende muss ich diesen Zugriff dann nur noch beobachten, um das Geheimnis zu lernen.

Golem.de: Wie konnte es zu den Sicherheitslücken kommen? Haben die CPU-Hersteller die Sicherheit einfach vernachlässigt?

Gruß: Natürlich geht es hier vor allem um Performance, das sind Marktkräfte. Ich würde sicher auch selbst keinen Prozessor kaufen wollen, der 200 Euro mehr kostet, aber langsamer ist als das Vorgängermodell, nur weil diese CPU nicht für Angriffe verwundbar ist, von denen ich als Kunde noch nie gehört habe.

Wenn diese Angriffe nicht diese Bedeutung gewonnen hätten, dann wären das jetzt völlig belanglose Namen, die nirgendwo im Gespräch wären. Dann wäre niemand bereit, mehr Geld in die Hand zu nehmen und eine schlechtere Performance in Kauf zu nehmen. Die Kunden wollen das schnellere Produkt haben.

Aber vielleicht ist das ein Punkt, wo uns allen bewusst wird, dass wir sichere Systeme haben wollen. Prozessoren, bei denen wir nicht davon ausgehen müssen, dass jedes Passwort, das ich auf dem System gespeichert habe, von einem Angreifer auslesbar ist.

Was Privatanwender und Admins tun sollten

Golem.de: Was sollten unsere Leser unternehmen? Sie sind Privatanwender, aber viele sind natürlich auch in Unternehmen tätig.

Gruß: Das ist in Unternehmen natürlich besonders kritisch. Viele Systeme sind in Umgebungen oft lange nicht mit Updates versorgt – und dann auch weiterhin anfällig.

Hier könnte der Meltdown-Angriff dafür sorgen, dass ein Mitarbeiter, der eigentlich nicht die notwendigen Berechtigungen hat, Daten auslesen kann, die er nicht auslesen können sollte. Das gilt natürlich vor allem für Systeme wie Thin-Clients, wo mehrere Geräte auf einem Firmenserver arbeiten.

Privatanwender sind derzeit nicht gefährdet – wenn sie die Softwareupdates installieren

Gruß: Für Privatanwender besteht im Moment erstmal keine Gefahr, wenn die Updates installiert sind. Bei Spectre wird es noch etwas dauern, bis das in eine Exploitform übergeht. Bei Meltdown haben wir das schon nach wenigen Tagen gesehen. Leute haben uns gezeigt, was sie mit Meltdown alles machen können. Damit konnte der gesamte Prozessspeicher ausgelesen werden, einige haben sogar Taskmanager nachgebaut, die gar keine Privilegien brauchen und alle Informationen auflisten und sogar den Speicherbereich eines ganz bestimmten Prozesses auslesen können. Da wird es nicht lange dauern, bis nutzbare Exploits im Umlauf sind. Die Meltdown-Updates sind also besonders wichtig.

Golem.de: Microsoft hat bekanntgegeben, dass vor allem ältere Systeme durch die Meltdown-Patches größere Performanceeinbußen haben werden, was vermutlich mit der Kompatibilität von Prozessoren mit den Process Context IDs zusammenhängt. Hat Ihr Team da genauere Informationen?

Gruß: Unsere Beobachtung dazu ist, dass es bei Intel-Prozessoren ab der Skylake-Generation durch die Verwendung der Process Context IDs nur zu geringen Leistungseinbußen kommt. Auf älteren Systemen ohne Unterstützung für die PCIDs sind die Verluste da in der Tat deutlich größer. Aber es sollte auf keinen Fall auf das Einspielen der Updates verzichtet werden, das wäre fahrlässig. Jede kleine App auf dem System kann dann meine Passwörter auslesen, und das ist sicherlich keine Lösung.

Golem.de: Wie sieht es bei Systemen bei Cloud-Providern aus?

Gruß: Hier gibt es zwei Ebenen: einmal die Anbieter selbst und dann natürlich die Kunden.

Erst einmal muss sich der Cloud-Provider gegen die Kunden absichern und den eigenen Hypervisor updaten, so dass kein Zugriff auf den Hostspeicher mehr möglich ist. Damit sind auch alle anderen virtuellen Maschinen auf dem Server gegen Cross-VM-Angriffe geschützt. In vielen Fällen ist es nicht einmal erforderlich, ein Update zu installieren. Bei vielen virtuellen Maschinen war es schon in den vergangenen Jahren so, dass der Hostspeicher nicht in den einzelnen virtuellen Maschinen gemappt wurde.

Bei paravirtualisierten Maschinen ist das oft anders, etwa bei Xen. Da war es schon so, dass der Speicher zwar gemappt war, aber nicht für den Gast erreichbar, ähnlich wie bei einem Betriebssystem-Kernel.

Golem.de Und die Kunden selbst?

Gruß: Wenn wir aber auf das von Nutzern selbst installierte Betriebssystem auf Cloud-Rechnern schauen, gibt es eine andere Situation. Wenn die Updates dort nicht installiert werden, aber Fremdsoftware ausgeführt wird, dann kann diese natürlich die Geheimnisse aus meiner VM alle auslesen. Da schützt mich der Cloud-Betreiber mit seinen Maßnahmen nicht dagegen.

Golem.de: Es gibt erste Mikrocode-Updates, aber diese verursachen aktuell noch viele Probleme. Inwieweit helfen die? Oder müssen wir drei bis vier Jahre warten, bis CPUs erscheinen, die grundsätzlich nicht mehr angreifbar sind?

Gruß: Da sind wir wieder bei dem Performance-Problem. Gerade wenn wir Branch-Prediction ausschalten, dann können wir die aktuelle Geschwindigkeit nicht mehr halten. Niemand gibt Geld aus für ein neues System, das langsamer ist als ein älteres, das man bereits hat. Es müssen also Lösungen gefunden werden, die Performance wieder so weit zu steigern, dass am Ende kein Leistungsverlust rauskommt. Es muss am Ende Systeme geben, die marginal schneller sind oder andere Vorteile bieten. Das könnte auch ein verringerter Stromverbrauch sein.

‚Bei Spectre habe ich geringes Vertrauen in die Softwarelösungen‘

Golem.de: Sind Sie von den Lösungsstrategien der Hard- und Softwarehersteller überzeugt?

Gruß: Meltdown sollte durch die Software-Updates komplett verhindert werden. Davon gehe ich auch aus. Bei den Mikrocode-Updates gegen Meltdown bin ich etwas skeptischer. Da wird nicht die Ursache bekämpft. Vielmehr wird nur einer der Effekte, die ausgenutzt werden, so verändert, dass man den Angriff nicht mehr einfach durchführen kann. Die Idee dahinter ist offenbar, dass einige Operationen so verzögert werden, dass der Angriff nicht mehr durchführbar ist. Wir sind uns aber nicht sicher, ob der Angriff dadurch wirklich schwieriger wird.

Denn es gibt eine Fülle an Covert-Channels. Denn der Flush-and-Reload-Channel, den wir für die Speicherzugriffe verwenden, ist nur eine Möglichkeit für einen erfolgreichen Angriff. Es gibt noch viele weitere Varianten, mit denen man ein Geheimnis heraussenden kann.

Bei den Updates gegen Spectre sieht es anders aus. Da habe ich geringes Vertrauen in die Softwarelösungen. Die werden entweder mit einem großen Performance-Overhead kommen oder nicht sehr treffsicher sein. Außerdem wissen wir noch gar nicht, welche Varianten es gibt, also welche Kombinationen von Instruktionen ausgenutzt werden können, um Spectre-Angriffe zu starten. Auch hier sind die Covert Channels das Problem. Wir wissen nicht genau, welche Channels es genau gibt und welche ausgenutzt werden. Es ist sehr schwierig, auf Softwareebene eine zufriedenstellende Lösung zu schaffen.

Golem.de: Und wie sieht das bei Spectre aus?

Gruß: Da schaut es auf der Hardwarebene etwas besser aus, hier könnten in der Hardware Funktionen wie die Branch-Prediction-Unit und der Branch-Target-Buffer nachgebessert werden. Wenn die für einen Angreifer nicht mehr manipulierbar sind, ist das für die Sicherheit ein großer Schritt nach vorne.

Auf der anderen Seite ist die Spectre-Variante 1 natürlich auch so, dass ich dort ganz stupide zwei Werte reinjagen kann und dann habe ich immer noch eine 50-Prozent-Chance, dass ich in die spekulative Befehlsausführung reinkomme. Auch hier ist also die Frage, ob wir Angriffe vollständig verhindern können.

Es gibt noch drastischere Maßnahmen: Im Gespräch war vor der Veröffentlichung auch, die Branch-Prediction komplett auszuschalten. Aber wir rechnen dann mit Performanceverlusten, die nicht schön sind. Das wäre so Faktor 5 bis hin zu Faktor 20, um den das System dann langsamer würde. Damit wären wir von der Performance her wieder am Ende der 90er angelangt. Das will natürlich keiner.

Golem.de: Wie sind Sie eigentlich darauf gekommen, die spekulative Befehlsausführung zu erforschen?

Gruß: Wir arbeiten schon länger in dem Forschungsgebiet Mikroarchitekturangriffe. Da schauen wir uns an, was eigentlich auf der Hardwareebene passiert. Die Frage ist ja: Was kann ein Angreifer verwenden, um Sachen herauszubekommen, die er eigentlich nicht herausbekommen sollte?

Beim konkreten Fall von Spectre und Meltdown war es so, dass wir zuerst schon die Gegenmaßnahme entwickelt haben, „Kaiser“, und die hat dann sehr viel Aufmerksamkeit bekommen. Darüber sind wir dann erst darauf aufmerksam geworden, dass es dort eine gravierende Sicherheitslücke geben muss. [Kaiser ist eine Abkürzung für Kernel Address Isolation to have Side-channels Efficiently Removed und ist ein Patch im Linux-Kernel, Redaktion]

Golem.de: Wie sind Sie denn darauf gekommen, eine Gegenmaßnahme für etwas zu entwickeln, was als Sicherheitsrisiko noch nicht komplett bekannt war?

Gruß: Bei Gegenmaßnahmen, wie eigentlich bei allen Sicherheitsmaßnahmen, versucht man sich gegen etwas zu schützen, was man noch nicht kennt. Wenn ich eine Alarmanlage für ein Haus baue, dann versuche ich auch, mich gegen Einbrecher zu schützen, von denen ich noch nicht genau weiß, auf welchem Wege sie eventuell mal ins Haus kommen.

Genauso ist es auch bei uns gewesen. Wir haben uns mit Angriffen auf die Randomisierung von Betriebssystemen im Speicherbereich beschäftigt. Da gab es drei sehr interessante Angriffe im Jahr 2016. Einer davon war von uns. Und dann haben wir mit Kaiser eine Gegenmaßnahme entwickelt, die dafür sorgt, dass der ganze Adressbereich des Betriebssystems nicht mehr im Prozess enthalten ist, der ist dann einfach ungültig. Damit ist eine ganze Klasse von Angriffen auf die Randomisierung des Betriebssystems nicht mehr möglich.

Das Spannende ist, dass Meltdown auch ausnutzt, dass der Speicherbereich vom Betriebssystem in jedem Nutzerprozess gemappt ist, und damit haben wir diesen Angriff auch gleich mit verhindert.

Golem.de: Woran wollen Sie in Zukunft weiter forschen, nachdem DRAM und CPU erfolgreich angegriffen wurden?

Gruß: Ich glaube, dass wir bei beiden noch nicht das Ende vom Forschungsthema erreicht haben. Ich glaube, dass wir bei Rowhammer weiterhin Angriffe sehen werden, die immer einfacher werden und die auf eine immer größere Anzahl von Systemen anwendbar sind.

Gleichzeitig wird es bei Meltdown und Spectre so sein, dass wir immer neue Variationen von diesen Angriffen sehen werden. Insbesondere bei Spectre gehe ich davon aus, dass das über Jahre ein Katz-und-Maus-Spiel wird, wo Antivirenhersteller immer wieder einen Exploit verhindern oder ein bestimmter Angriff durch akademische Forschung oder durch die CPU-Hersteller entdeckt werden kann. Aber schon kleine Änderungen am Angriff können bewirken, dass so ein Angriff weiter durchgeführt werden kann.

Golem.de: Danke für das Gespräch!  (hg)


Verwandte Artikel:
Jessica Barker im Interview: „Die Kriminellen sind bessere Psychologen als wir“
(28.11.2017, https://glm.io/131261 )
Updates: Wie man Spectre und Meltdown loswird
(12.01.2018, https://glm.io/132125 )
Nach Meltdown und Spectre: Intel richtet neue Sicherheitsabteilung ein
(10.01.2018, https://glm.io/132082 )
Überwachungstechnik: EU-Parlament fordert schärfere Ausfuhrregeln
(18.01.2018, https://glm.io/132237 )
Cannon Lake: Intel will erste 10-nm-Chips ausgeliefert haben
(11.01.2018, https://glm.io/132101 )


© 1997–2018 Golem.de, https://www.golem.de/
Original-URL des Artikels: https://www.golem.de/news/meltdown-und-spectre-dann-sind-wir-performancemaessig-wieder-am-ende-der-90er-1801-132224.html    Veröffentlicht: 18.01.2018 12:00    Kurz-URL: https://glm.io/132224
Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

w

Verbinde mit %s

%d Bloggern gefällt das: