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.