AW: Sicherheitslücken Spectre & Meltdown: Ein Erklärungsversuch
Der Artikel erklärt die Problematik wirklich gut und findet in meinen Augen einen schönen Kompromiss zwischen Abstraktion und Genauigkeit. Allein der Grundton gefällt mir nicht. Schauen wir uns die Lücken mal getrennt an.
Meltdown:
Hier wurde von (im Wesentlichen) Intel ein Permission-Check ausgelassen, der den Privilege Level auch auf alternativen Pfaden prüfen müsste. Das man dieses tun muss war meiner Meinung nach auch vor über einem Dutzend Jahren schon Teil des Kanons zum CPU-Design. Auch wenn man die lkml (und damit meine ich nicht nur Linus' Post der weite Kreise zog, sondern auch ein paar andere) zu diesem Thema querliest kann man zu diesem Schluss kommen. --> Ich denke hier hat Intel (und eventuell auch die ARM-Architekten und andere) bewusst Performance über Sicherheit gesetzt. Ich kann mir nicht vorstellen dass man hier über Jahre hinweg etwas übersehen hat was meiner Meinung nach besser dokumentiert ist und gelehrt wird.
Das Privilege Level geprüft werden, ist Kanon. Sonst würden sie gar nicht funktionieren. Aber muss man sie vor der eigentlichen Berechnung prüfen oder reicht eine Prüfung vor Freigabe des Ergebnisses? Die bisherigen Sicherheitsüberlegungen setzten nur letzteres voraus: War eine spekulative Berechnung unnötig, illegitim oder ist aus irgend einem anderen Grund nicht verwertbar, gibt es einen Rollback zum vorhergehenden Systemzustand und es gibt keine Spuren, das überhaupt eine Berechnung stattgefunden hat. Dieses Verfahren galt sowohl auf Seiten der CPU- als auch Software-Entwickler als absolut sicher. Das die physischen Prozesse deutlich weniger klar sind als dieser nominellen Ablauf der Systemlogik wurde ignoriert.
Ich glaube aber nicht, dass das eine bewusste Entscheidung war – eben weil die gesamte IT-Welt nur in deterministischen Abläufen denkt und selten ein Bewusstsein für die physischen Vorgänge eine Ebene tiefer hat. Mein Tip: Die Cache-Designer haben daran gearbeitet, möglichst alle Prozesse zu beschleunigen, die Entwickler der Sprungvorhersage haben daran gearbeitet, möglichst effizient Instruktionen zu beschleunigen und alle Sicherheitsfragen wurden beim OoO-Management angesiedelt, weil dieses ja als Gate-Keeper "alle" Wege bewacht, über die Prozesse an Informationen gelangen. Dummerweise hat die Scheduler-Entwickler aber nie einen Grund, sich mit der Arbeitsweise des L3-Caches oder den Möglichkeiten der Sprungvorhersage auseinanderzusetzen...
Kannst fü deinen Post nochmal in einem Tl;Dr zusammenfassen? Die Aufmerksamkeit hat nur bis zu wir geben unser bestes gereicht [emoji16]
Das war das TL;DR
.gif "sm_B-) :-)")
Auch von meiner Seite herzlichen Dank für die top geschriebenen Background Infos. Ehrlich gesagt musste ich manche Passagen mehrfach lesen, um es halbwegs begreifen zu können.
Welche Passagen waren das? (Und wieso?) Dann kann ich sehen, ob ich die fürs Print-Heft besser hinbekomme
Uff, doch soviel, kein Wunder das es schon so spät ist. Naja nebenbei Kernel gepatcht.
Nur eins ist mir aufgefallen, auf Seite 3 schreibst du das auch Sandbox Systeme und auch Cloud Systeme nicht sicher sind,
"Sandbox-Container eines Browsers ist ebenso wirkungslos wie die Trennung virtueller Maschinen auf einem (Cloud-)Server."
ganz am Ende schreibst du aber (wie ich mir gleich zu Anfang dachte) das virtualisierte Systeme sicher sein können.
"Prinzipbedingt sind nämlich sowohl Spectre, als auch Meltdown an eine physische CPU gebunden;"
Jeder halbwegs anständige Server hat 2 oder mehr CPUs drin. Wenn jetzt VM1 auf CPU#0 läuft und VM2 auf CPU#1 dann kann zumindest eine VM nicht auf die andere zugreifen.
Was mir auch fehlt, es gibt doch auch Server CPUs die mehrere NUMA Nodes haben. Das ist dann zwar 1 Die aber eigentlich sind 2 CPUs drin. Die sharen sich ja dann den L3 Cache wenn ich mich recht entsinne. Sind solche CPUs noch Anfällig für Meltdown/Spectre? Das dürfte ja schon ein wahnsinniger Aufwand sein da überhaupt was abzureifen wenn die VM infiziert wird.
Wie schauts dann aus wenn dann noch sowas die Docker läuft? Also Container -> VM -> Hostsystem -> physische CPU.
Wenn jetzt z.B der Anwendungs-Container infiziert wird hab ich nur noch Spaghetti vor Augen um da zB. auf die Datenbank in einem anderen Container zuzugreifen, selbst wenn die am Ende auf dem selben Host laufen.
Ohne Dokumentation blickt da irgendwann auch kein Admin mehr durch ^^ und da muss dann Spectre explizit auf den Prozess angepasst werden? Ich glaube es wäre effizienter und einfacher ins Rechenzentrum einzubrechen und alles auf nen Stick zu kopieren.
Letzteres ist immer einfacher, es fällt aber gegebenenfalls auf, wenn die physische Firewall mit Dynamit durchtunnelt.
Zur eigentlichen Frage: Soweit ich es verstehe, sind Prozesse auf physisch distinkten CPUs voreinander sicher. Wenn also fest ein ganzer Prozesser einer VM zugewiesen wird, sollten Spectre-Angriffe aus anderen VMs auf diese unmöglich sein. Allerdings nutzt man Virtualisierung ja normalerweise, wenn die Gleichung 1 System = 1 CPU nicht aufgeht und ich weiß nicht, in wie weit die Sprungvorhersagen einzelner Kerne einer CPU untereinander Informationen austauschen. Zumindest AMD spricht ja gerne von intelligenten Netzwerken. Definitiv unsicher wird das Ganze, wenn die VMs von Kern zu Kern springen können. (Allerdings dürfte der Vorgang nutzlos langsam werden, wenn diese Wechsel zu selten stattfinden.)
Daran ändern auch Container nichts, vermutlich nicht einmal vollständige Verschlüsselungen. Das Perfide an Spectre ist, dass die eigentliche Attacke nur innerhalb der Ausführungseinheiten stattfindet – also da, wo Befehle und Daten unkodiert und ungeschützt vorliegen müssen, weil mit ihnen gearbeitet wird. Der Angreifer muss also außer der Zielapplikation keinen anderen Aspekt des Systems kennen – ob beispielsweise ein gängiger Webserver nativ auf dem komprimitierten Prozessor läuft oder in einem Container in einer VM in einem doppelt und dreifach überwachten Host, ist egal. Der Angriff arbeitet ohnehin nur mit einigen wenigen Zeilen Code des Ziels.
).
