Kann die Spectre-Sicherheitslücke in einer virtuellen Maschine liegen?

Ist es möglich, dass eine virtuelle Maschine wie VirtualBox die Sicherheitslücke "spectre" aufweist? Ich denke, dass die VM möglicherweise nicht in der richtigen Reihenfolge ausgeführt wird, aber meiner Meinung nach ist es nicht möglich, in den Cache zu schauen, um das Ergebnis zu lesen.

Gibt es eine Erklärung, wie es möglich ist, den Cache einer virtuellen CPU zu lesen?

Ja, ein wenig Forschung hätte bestätigt, dass VMWare Patches für Spectre und Meltdown veröffentlicht hat. Das Gastbetriebssystem muss zusätzlich zum eigentlichen Hypervisor (beide Typen)

— gepatcht werden

Kommt auf den Virtualisierungsgrad an, würde ich sagen. Wenn Sie eine virtuelle CPU simulieren, sind Sie wahrscheinlich sicher. Aber das ist nicht das, was moderne VMs tun.

— Bergi

Gibt es eine Erklärung, wie es möglich ist, den Cache einer virtuellen CPU zu lesen?

@ JMS Details sind in der Canonical Post, die ich in meiner Antwort verlinkt:

Spectre works on a different level ... In this attack, the attacker tricks the speculative execution to predictively execute instructions erroneously. In a nutshell, the predictor is coerced to predict a specific branch result that results in asking for an out-of-bound memory access that the victim process would not normally have requested resulting in incorrect speculative execution. Then by the side-channel, retrieves the value of this memory. In this way memory belonging to the victim process is leaked to the malicious process.

— Mokubai

@jms Virtualisierung ist nur schnell, weil die physische CPU so wenig wie möglich abstrahiert wird und die Isolierung und Abstraktion auf CPU-Hardware beruht. Dinge wie qemukönnen Emulationen ausführen, die sicherer wären, da es sich nicht um eine Hardware- CPU handelt, aber sie ist viel langsamer und unterscheidet sich von der Virtualisierung.

— Mokubai

Ja Spectre kann die Grenzen von Host / Gast, Gast / Host und Gast / Gast überschreiten, da dies ein Fehler auf CPU-Ebene ist, der bedeutet, dass potenziell vertrauliche Informationen über alles hinweg übertragen werden können, was auf einem CPU-Kern ausgeführt wird.

In den meisten Nachrichten im Internet wird davon gesprochen, dass die Cloud-Anbieter am stärksten davon betroffen sind, da es sich um massive Cluster von Systemen handelt, die virtualisiert sind und möglicherweise missbraucht werden, um vertrauliche Informationen zu verlieren.

Die meisten großen Anbieter hätten jetzt, so gut sie können, gegen die Fehler geflickt werden müssen, aber dies wird ein Problem sein, das uns noch einige Zeit beschäftigen wird.

Security.SE hat diesbezüglich ein kanonisches Q & A und erwähnt VMs:

Ich verwende eine virtuelle Maschine / Container. Inwieweit bin ich anfällig?

Nach Steffen Ullrichs Antwort

Meltdown-Angriffe kreuzen keine VMs, sondern leiten nur Kernel-Speicher an lokale Prozesse ab.

Spectre kann über mehrere VMs hinweg arbeiten.

Auch von Steffen aus arbeiten Meltdown und Spectre mit Containern, da Container auf den Host-Kernel angewiesen sind.

VMs verwenden die tatsächliche CPU in Ihrem System, wobei einige privilegierte Anweisungen abgefangen und umgeleitet werden können. Es verwendet dieselben Caches und Anweisungen wie der Host. Es ist im Wesentlichen nur eine weitere Schicht innerhalb der physischen CPU in Ihrem System.

Die Virtualisierung ist nur schnell, weil die physische CPU so wenig wie möglich abstrahiert wird und die CPU-Hardware für die Isolierung sorgt. Dinge wie qemu können Emulationen ausführen, die sicherer wären, da es sich nicht um eine Hardware-CPU handelt, aber sie ist viel langsamer und unterscheidet sich von der Virtualisierung.

Nochmals aus dem kanonischen Eintrag von Security.se :

Spectre arbeitet auf einer anderen Ebene und erlaubt keinen Zugriff auf Kernel-Space-Daten aus dem User-Space. Bei diesem Angriff täuscht der Angreifer die spekulative Ausführung vor, um Anweisungen fälschlicherweise vorhersagend auszuführen. Kurz gesagt, der Prädiktor wird gezwungen, ein bestimmtes Verzweigungsergebnis vorherzusagen (wenn -> wahr), das dazu führt, dass ein Speicherzugriff außerhalb der Grenzen angefordert wird, den der Opferprozess normalerweise nicht angefordert hätte, was zu einer inkorrekten spekulativen Ausführung führt. Ruft dann über den Seitenkanal den Wert dieses Speichers ab. Auf diese Weise wird der zum Opferprozess gehörende Speicher an den böswilligen Prozess übertragen.

Da die VM in der tatsächlichen CPU-Hardware ausgeführt wird und nur eine bestimmte Schleife ausgeführt werden muss, um die spekulative Ausführungsengine zu "trainieren". Dann kann es das genaue Timing verwenden, um die Caches auf bestimmte Zugriffsmuster zu überwachen, die auf den Host- oder Gastprozess (oder einen anderen VM-Prozess) hinweisen, den es ausnutzen möchte.

Auf diese Weise ist eine Maschine in alle Richtungen nutzbar. Von Host zu VM, von VM zu Host und von VM zu VM.

Ja, das ist keineswegs einfach und schwierig, da sich der VM-CPU-Kern nach Belieben des Hosts ändern und der Host auch gerne Aufgaben auf verschiedenen Kernen planen könnte, aber über einen langen Zeitraum genug Informationen könnte durchgesickert sein, um einen geheimen Schlüssel für ein wichtiges System oder Konto preiszugeben. Bei genügend Zeit und einer entsprechend vertraulichen Software ist möglicherweise alles offen.

Wenn Sie eine "sichere" VM wünschen, müssen Sie sicherstellen, dass die Kerne isoliert sind. Die einzige wirkliche Möglichkeit, diesen Angriff zu blockieren, besteht darin, den Host und die VMs zu "zwingen", nur bestimmte Kerne zu verwenden, damit sie niemals auf derselben Hardware ausgeführt werden haben so viele VMs auf einem bestimmten Host. Sie könnten niemals mehr VMs ausführen, als Kerne zur Verfügung stehen. Dies würde ich auf Servern mit geringer Auslastung erwarten, da viele Systeme 90% ihrer Lebensdauer im Leerlauf verbringen.

— Mokubai
quelle

Ich denke, Sie interpretierten die Frage als "Wenn die Host-CPU betroffen ist, ist auch die VM betroffen?" Wie ich die Frage verstehe, wird die Frage gestellt: "Wenn die Host-CPU nicht betroffen ist, kann die VM trotzdem betroffen sein?" Könnten Sie das klären?

— AndreKR

@AndreKR: Derzeit sind alle außer Betrieb befindlichen Ausführungs-CPUs von Spectre betroffen. Nur mit Software-Workarounds können Sie ein System sicherer machen (und das müsste die VM berücksichtigen, obwohl ein Hypervisor die Gäste voneinander isolieren kann, wenn die CPU die Funktionen bereitstellt, z. B. Intels IBRS-Zeug). Auf einer in Auftrag gegebenen CPU ohne spekulative Ausführung können jedoch zwischen zwei beliebigen Softwareteilen keinerlei Spectre-Schwachstellen bestehen. Das Wesen von Spectre ist es, eine spekulative Ausführung von etwas zu provozieren, das geheime Daten in einen mikroarchitektonischen Zustand versetzt. In-Order-CPUs nicht.

— Peter Cordes

Das Interessanteste ist nicht die spekulative Hinrichtung. Das Interessanteste ist, wie ein Prozess herausfinden kann, was sich im Cache befindet - sogar in einer VM.

@jms Die verfügbaren Seitenkanalangriffe werden durch die spekulative Ausführung erleichtert und nützlich gemacht . Der Prozess ist möglicherweise nicht in der Lage, Cache-Zeilen direkt zu lesen, aber die spekulative Ausführung kann zu Informationslecks führen, indem Berechnungen durchgeführt werden, die Werte in den Cache stellen, die durch Timing-Angriffe erkannt oder abgeleitet werden können. Abschnitt 4 des Spectre White Papers hat eine gute Erklärung: spectreattack.com/spectre.pdf

— Mokubai

gem5

Wenn Sie Schwachstellen ausschließlich mit Emulation untersuchen / reproduzieren möchten, ohne die Host-CPU zu verwenden, ist QEMU meines Erachtens nicht detailliert genug, um sie zu beobachten, da es die CPU-Pipeline nicht simuliert.

Mit gem5 wird jedoch die Systemleistung in Forschung und Entwicklung geschätzt und es werden genügend CPU-Interna simuliert, damit Sie Spectre in einer vollständig sauberen und kontrollierten Umgebung beobachten können.

Eine coole x86_64-Demo mit Visualisierung wurde veröffentlicht unter: http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html

Der Nachteil von gem5 ist, dass es viel langsamer als QEMU ist und die Simulation detaillierter ist.

— Ciro Santilli ist ein Schauspieler
quelle