Avatar von conveyan
  • conveyan

122 Beiträge seit 23.10.2015

Was wirklich los ist interessiert scheinbar keinen

Folgenden Artikel will die c'T Redaktion aus folgenden Gründen nicht veröffentlichen:

Die Tatsache, dass eine Lücke sich nur schwer ausnutzen lässt, ist aus unserer Sicht kein valides Argument, um das Gefährdungspotenzial zu bewerten. Die Reaktion der betroffenen Firmen zeigt zum einen, für wie bedrohlich sie die Lücke halten – hätte die Lücke kein Potenzial, hätten die anders reagiert.

Darum geht es doch, um die realistische Bewertung. Wie sollen die betroffenen Firmen anderes reagieren, wenn die Informationen, die wir belegen können, nicht veröffentlicht werden? Wieso darf ein Leser nicht seine Gefährungslage aufgrund der Ausnutzbarkeit bewerten?

Zum anderen halten wir die Argumente der Entdecker für stichhaltig, dass sie die perfektionierte Implementierung eines Angriffs derzeit nicht veröffentlichen.

Und was ist mit den widersprüchlichen Aussagen, die sich nicht mit dem Meltdown-Paper decken, sowie den neuen Abhängigkeiten, die bislang nicht Thematisiert werden?

Und hier unser Artikel:

Meltdown - War das schon alles?

mit Meltdown soll auf jeder modernen 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 Clouddienste ist dies ein wahres Horror-Szenario.

Glücklicher Weise 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 über 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(*1). 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 (*2).

Die Autoren des Meltdown-Papers räumten auf Nachfrage(*3) 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 Eingriffen 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 unsere 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 insbesondere 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 richtigen Gefahr - wenn auch wahrscheinlich nur mit sehr geringeren Datenraten.

Solange zu Meltdown keine überprüfbare und vollständigen Informationen verfügbar sind, oder sich jemand neues 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 bis auf weiteres darauf achten, welche Systeme mit welchen anderen Systemen zusammen virtualisiert werden und welcher Binärcode auf meinen Systeme ausgeführt werden kann. Nur diese Verteidigungslinie kann im Moment mit Sicherheit gehalten werden, die verfügbaren Patches können nach und nach zur zweiten Verteidigungslinie mit Bedacht genutzt werden. Für Virtualisierungslösungen gibt es zudem Workarounds, beispielsweise kann unter XEN ein 32 Bit Gast keinen 64 Bit Host angreifen(*4). Als Patch sei die folgende Maßnahme besonders herausgestellt: Der KAISER-Patch(*5) 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.

Büro- oder Privat-PCs als auch einfache Server sind durch Meltdown am Wenigsten gefährdet, da der Speicherzugriff zwischen Prozessen auf vielen Betriebssystemen(*6)(*7)(*8) 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 Meltdown-Angreifer aufs System kommen. In wie fern das Antesten von Software in Virenscannern zur Verhaltensanalyse oder aktiven Inhalte wie in Browsern (JS) oder PDF-Viewern relevant werden, 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.

(*1) https://github.com/IAIK/meltdown
(*2) https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html
(*3) https://github.com/IAIK/meltdown/issues/9
(*4) http://xenbits.xen.org/xsa/advisory-254.html
(*5) https://de.wikipedia.org/wiki/Kernel_page-table_isolation
(*6) http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/vm_read.html
(*7) http://linuxwiki.de/proc/pid#A.2Fproc.2Fpid.2Fmem
(*8) https://msdn.microsoft.com/de-de/library/windows/desktop/ms680553(v=vs.85).aspx

Markus Schräder - CryptoMagic GmbH - https://www.cryptomagic.eu/

Bewerten
- +
Anzeige