Meltdown - War das schon alles?
Mit Meltdown soll mindestens auf jeder halbwegs aktuellen Intel-CPU beliebiger Hauptspeicher einfach auslesbar sein. Nun zeichnet sich ab, dass es doch nicht ganz so einfach ist, und sich das Gefährdungspotential möglicherweise wesentlich geringer als bislang angenommen darstellt - oder dass die große Bedrohung erst noch ansteht.
Mit Meltdown soll mindestens auf jeder halbwegs aktuellen Intel-CPU beliebiger Hauptspeicher einfach auslesbar sein. Nun zeichnet sich ab, dass es doch nicht ganz so einfach ist, und sich das Gefährdungspotential möglicherweise wesentlich geringer als bislang angenommen darstellt - oder dass die große Bedrohung erst noch ansteht.
Auch wenn es sich bei Meltdown nur um einen rein lesenden Angriff handelt, so kann dies weitreichende Konsequenzen haben. Beispielsweise kann es im Falle von Passwörtern oder kryptografischen Schlüsseln den Effekt haben, dass man Verschlüsselung dauerhaft bricht und laufende sowie mitgelesene Kommunikation entschlüsseln kann. Weiter ist denkbar, sich mit einem mitgelesenen Passwort die Berechtigungen eines Benutzer zu beschaffen – im Falle des Benutzers root oder des Administrator sind damit alle Dämme gebrochen. Noch schwerwiegender wird dies bei der Virtualisierung und dem Lesen von Speicher aus dem Hypervisor oder anderen Virtualisierungssystemen; insbesondere für Cloud-Dienste ist dies ein wahres Horror-Szenario.
Glücklicherweise zeichnet sich gerade ab, dass Meltdown nicht das bislang angenommene Schadenspotential hat. Anders als im Meltdown-Paper beschrieben, ergeben alle bisher öffentlichtlich zugänglichen Beispiele (POCs) und überprüfbaren Informationen das folgende Bild: Damit per Meltdown erfolgreich Daten ausgelesen werden können, müssen sich diese an bekannter Speicheradresse (eine 32 bzw. 64 Bit Zahl) im CPU Cache befinden. Da dies aus dem Stand eine fast unlösbare Herausforderung ist, sind alle bislang verfügbaren Beispielangriffe auf die Mitwirkung des angegriffenen Programms angewiesen - auch das Beispielprogramm der Macher des Meltdown-Papers. Derzeit gibt es keine nachprüfbaren Veröffentlichungen oder bekannt gewordene Angriffe, die belegen dass sich tatsächlich Speicher ausserhalb des CPU Caches auslesen läßt, um dieses Problem zu umgehen. Selbst Tests von Google kommen zu dem Ergebnis, dass eine CPU-Cache Abhängigkeit besteht.
Die Autoren des Meltdown-Papers räumten auf Nachfrage diesen Sachverhalt bedingt ein, ohne allerdings wirklich Licht ins Dunkel zu bringen. Es wurden neue und bislang unbekannte Abhängigkeiten eingeräumt und mit Videos belegt, welche allerdings nach unserem Verständnis dem Meltdown-Paper widersprechen. Nach unseren eigenen Tests, Beobachtungen und Bewertungen der Aussagen erhärtet sich für uns die Theorie, dass Meltdown mindestens auf der überwiegend verbreiteten Hardware diesen besagten CPU-Cache Einschränkungen unterliegt, und auf der restlichen Hardware erst nach aufwendigen Anpassungen pro Hardware funktionieren kann. Zudem dürften die auf diesen betroffenen Systemen erzielbaren Datenraten weit geringer sein als angegeben: wenige Byte/sek. Da die Informationen hierzu nur sehr reduziert verfügbar sind sowie nur per Video vorgeführt wurden, kann diese allerdings derzeit nicht genauer analysiert werden.
Sollten sich diese Theorie bestätigen, so würde sich das Gefahrenpotential von Meltdown massiv reduzierten. Auch in diesem Szenario ist Meltdown allerdings nicht zahnlos - es rückt allerdings neu vor allem der Kernelspeicher in den Fokus, da ich diesen als Angreifer unter Umständen durch Funktionsaufrufe des Kernels in den Cache befördern kann. Insbesondere ist hierzu als Angriffsvektor zu sehen, dass man Kernelfunktionen mißbrauchen könnte um den Zugriff auf Speicher anderer Anwendungen zu provozieren und somit Daten in den Cache zu befördern; hierzu sollten alle vom Prozess ansprechbaren Kernelfunktionen auf derartiges Mißbrauchspotential überprüft werden.
Es könnte allerdings auch ganz anders kommen: Sollten sich der von den Meltdown-Autoren neu eingeräumten Abhängigkeiten doch auf mehr Hardware oder einfacher erfüllen lassen, so wird Meltdown erst ab diesem Zeitpunkt zur großen Gefahr - wenn auch wahrscheinlich nur mit sehr geringeren Datenraten.
Solange zu Meltdown keine überprüfbare und vollständigen Informationen verfügbar sind, und sich niemand dieser Nebelwolke annimmt, bleibt wohl nichts anders übrig als die Angriffsvektoren zu reduzieren und eine mögliche erst noch kommende Gefahrensituation anzunehmen. Zuverlässige Tests, die zeigen können dass Meltdown nicht mehr auftreten kann, werden bis dahin auch kaum möglich sein. Insbesondere sollte man darum darauf achten, welche Systeme mit welchen anderen Systemen zusammen virtualisiert werden und welcher Binärcode auf welchen Systemen ausgeführt werden kann. Nur diese Verteidigungslinie kann im Moment mit Sicherheit gehalten werden, die verfügbaren Patches sollten ergänzend nach und nach zur zweiten Verteidigungslinie mit Bedacht genutzt werden. Mit Bedacht aus mehreren Gründen; die Patches kosten teils enorme Performance, wurden teils aufgrund von Instabilitäten bereits zurückgezogen und deren Sicherungseffekte sind nach aktueller Lage nur bedingt abgesichert oder überprüfbar. Als Patch sei die folgende Maßnahme besonders herausgestellt: Der KAISER-Patch blendet in Prozesse nur den Speicher ein, der gerade benötigt wird. Dies ist darum nützlich, da was nicht eingeblendet wird mit Meltdown auch grundsätzlich nicht angegriffen werden kann. Für bestimmte Anwendungsbereiche gibt es zudem Workarounds, beispielsweise bei der Virtualisierung mittels XEN kann ein 32 Bit Gast keinen 64 Bit Host angreifen.
Büro- oder Privat-PCs als auch einfache Server sind durch Meltdown am Wenigsten betroffen, da der Speicherzugriff zwischen Prozessen auf vielen Betriebssystemen bereits von Haus aus vorgesehen ist und lokale Admin-Angriffe keine Seltenheit sind. Spätestens seit dem Kursieren von Crypto-Trojanern sollte keine leichtfertige Ausführung von unbekannten Programmen stattfinden - und somit auch nicht so einfach ein Meltdown-Angreifer aufs System kommen. In wie fern das Antesten von Software in Virenscannern zur Verhaltensanalyse sowie das Ausführen von aktiven Inhalten wie in Browsern (JS) oder PDF-Viewern relevant ist, ist natürlich eine andere Frage.
Die größte Gefahr lauert derzeit bei der Virtualisierung, insbesondere Cloud-Dienste rücken hierzu ganz neu in den Security-Focus. Nicht zuletzt, da es aufgrund fehlender Informationen derzeit keine verlässlichen Testtools geben kann, mit denen ich mir als Betreiber oder Nutzer letzten Endes sicher sein kann alles abgedichtet zu haben.
