Meltdown - look closely


Stand: V4, 08.01.2017

Was bisher geschah

Am 28.07.2017 beschreibt Anders Fogh auf seinem Blog, dass man über das Messen von Cache-Timings den Speicher des Linux-Kernels auslesen kann(*1). Er vermutet einen Zusammenhang mit der spekulativen Ausführung von Befehlen in der CPU. Zu einem unbekannten Zeitpunkt behandeln auch Forscher vom Google Project Zero diesen Sachverhalt, und versuchen sich an einem Proof of Concept, von dessem Erfolg am 03.01.2017 berichtet wird und den Sachverhalt mit Einschränkungen bestätigt(*2). Zwischenzeitlich werden von unbekannten Personen zahlreiche Hersteller zu unterschiedlichsten Zeitpunkten über diese neue Lücke informiert. Während diese Hersteller mit der Lösung des Problems beschäftigt sind, entsteht die Webseite https://meltdownattack.com/, auf der zu Meltdown als auch Spectre entsprechende Papers und Logos zu erhalten sind – und es bricht die branchenweite Panik aus.

Das Horrorszenario

Insbesondere wenn man sich das besagte Paper zu Meltdown im Bezug auf Linux ansieht, so kann man durchaus sehr schockiert sein: Es wird beschrieben, wie man den gesamten Kernelmemory auslesen kann, und über einen speziellen Adressbereich des Kernels sogar den gesamten gesamten physikalischen Speicher. Es wird weiter ausgeführt, dass man darüber somit den Speicher jeden Prozesses auslesen kann. Das hört sich aus der IT-Security Sicht wie ein absolutes Horrorszenario an: Denn auch wenn es sich nur um einen rein lesende Zugriffe handelt, so kann dies beispielsweise im Falle von Passwörtern oder kryptografischen Schlüsseln den Effekt haben, dass man Verschlüsselung brechen 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 wären damit alle Dämme gebrochen.

Das ausbleibende Massaker

Auch eine Woche nach diesen Veröffentlichungen werden weder funktionierende Programme noch Leaks bekannt, was für die Einfachheit der Lücke, des vorliegende Informationsumfangs und -qualität sowie in Kombination mit der vorgeblichen Tragweite ungewöhnlich ist. Beim aufmerksamen Lesen der Veröffentlichung von Googles würde eine Bemerkung zum L1D Cache auffallen, die bereits auf eine unbekannte Einschränkungen lässt, dies scheint allerdings kaum aufzufallen. Es erscheinen auf Github erste funktionierenden Angriffsprogramme, die allerdings nicht beliebigen Speicher sondern lediglich bestimmte unkritische Informationen im Kernel auslesen können. Insbesondere das Kernelsymbol „linux_proc_banner“, dass zur Verarbeitung der Ausgabe der Linux Versionsinformationen über /proc/version unkritische Informationen beinhaltet, wird von vielen erfolgreich ausgelesen. Erst nach Tagen erhärtet sich auf Github unter Entwicklern der Verdacht: Irgend etwas muss anders sein, als dies das Meltdown-Paper beschreibt.

Aktuelle Beobachtungen

Dem Google Project Zero Bericht ist, im Gegensatz zum Meltdown-Paper, zu entnehmen, dass es für Meltdown eine Abhängigkeit zum Vorliegen der Daten im Prozessor Cache gibt. Diese Abhängigkeit hat möglicherweise auch schon im Juli 2017 Anders Fogh verwirrt, so dass er in seinem Blog von Effekten des prefetch CPU-Befehls schreibt, die das Google Project Zero in ihrem Bericht nur ohne Erfolg versuchten.

Diese Rolle des Vorliegen der Daten im Prozessor Cache wäre im Bezug auf die Tragweite von Meltdown enorm: Es wäre hierdurch keinesfalls so, dass, wie das bislang angenommen wird, beliebiger Speicher ausgelesen kann, sondern nur der Speicher der kurz zuvor auf der gleichen CPU verarbeitet worden ist und noch während des Angriffs auf dieser im besagten Cache verfügbar ist. Dies würde dazu führen, dass das zufällige vorliegen für nicht Kernelspeicherbereiche im Cache nicht nur noch unwahrscheinlich ist, sondern dass auch das gezielte Herbeiführen des Vorliegens, wie bei den bereits funktionierenden Angriffsprogrammen, für nicht Kernelspeicheradressen nochmals schwieriger werden würde: Hierzu müsste der Kernel oder der angreifende Prozesse eine Veranlassung haben, entsprechende Speicherstellen eines unbeteiligten Prozesses über die virtuelle Adresse direkt anzusprechen.

*1 https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/
*2 https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html
*3 https://web.archive.org/web/20111007150424/http://www.systems.ethz.ch/education/past-courses/fs09/aos/lectures/wk3-print.pdf
11.01.2018 - Markus Schräder - CryptoMagic GmbH