'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!