Re: Meltdown - VMs sicher nach Hypervisor-patch?

Hallo Olli,

Danke fuer die Ausfuehrungen. Mein Wissen ist "gesundes Halbwissen", ich
kenne z.B. die Ringstruktur, die Grundlagen von Caching etc, aber nicht
genug, um alles im Detail erklaeren zu koennen. Auch ist mein Wissen auf
"Pentium-Stand", wenn es danach revolutionaere Aenderung gegeben haben
sollte, dann habe ich die verschlafen.

Mit Spectre habe ich mich noch nicht im Detail auseinandergesetzt - habe
nur im Prinzip verstanden, dass dagegen bis jetzt wirklich kein Kraut
gewachsen ist, weswegen ich (oder meine Bosse;-) auch kaum sagen koennen,
wir haben das im Griff.

Danke fuer die Erklaerung, es ist das erste Mal, dass ich Spectre
verstanden habe.

Nebenbei, die Erklaerung von Meltdown in der Wikipedia ist ganz nett,
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability),

und sagt zur Virtualisierung:

Virtual machine – Meltdown attack cannot be used to break out of a
virtual machine, i.e., in fully virtualized machines guest user space can
still read from guest kernel space, but not from host kernel space.[56]
The bug enables reading memory from address space represented by the same
page table, meaning the bug does not work between virtual tables. That is,
Guest-to-Host page tables are unaffected, only Guest-to-Guest or
Host-to-Host, and of course Host-to-Guest since the host can already
access the guest pages. This means different VMs on the same fully
virtualized hypervisor cannot access each other's data, but different
users on the same guest instance can access each other's data.[57]

Okay, das heisst, ich muss doch jede VM patchen, und brauch mich um
VMware-Patching "meltdown-maessig" gar nicht kuemmern.

Wenn ich das von anderswo richtig verstehe, weil VMware die GDT (Global
Descriptor Table) austauscht und so ie Adress-Raeume von unterschiedlichen
VMs sauber trennt.

Wenn ich hier richtig geraten habe;-)

Es gruesst
Peter

On Wed, 10 Jan 2018, Oliver Fromme wrote:

> Hallo Peter,
>
> Peter Ross wrote:
> > Ganz grob gedacht und gefragt: Wenn der Hypervisor in Sachen Hardware (und
> > sicher auch CPU-Caching) das letzte Wort hat, kann Meltdown noch innerhalb
> > der VM ausgenutzt werden?
>
> Meltdown nicht – aber Spectre.
>
> Grob gesagt: Der Meltdown-Bug (CVE-2017-5754) erlaubt es einem
> Angreifer, die Trennung zwischen den Ringen [1] zu überwinden.
> So kann ein normaler Benutzerprozess (Ring 3) auf den Adressraum
> des Kernels oder des Hypervisors zugreifen. Vom Meltdown-Bug
> sind alle (neueren) Intel-CPUs betroffen sowie einige (wenige)
> ARM-Versionen, nicht aber AMD oder andere. Der Bug lässt sich
> durch Work-arounds im Betriebssystem fixen, die aber einen gewissen
> Performanceverlust bedeuten. Außerdem hat Intel angekündigt,
> Microcode-Updates für betroffene Prozessoren herauszubringen,
> die im Zusammenspiel mit (weiteren) Betriebssystem-Patches den
> Performanceverlust wieder ausgleichen sollen.
>
> [1] https://de.wikipedia.org/wiki/Ring_%28CPU%29/x86-Prozessor-Systeme
>
> Das Spectre-Problem dagegen erlaubt das Überwinden von Zugriffs-
> beschränkungen des eigenen Adressraums (Variante 1, CVE-2017-5753)
> und der Trennung des Adressraums zwischen verschiedenen Prozessen
> oder VMs (Variante 2, CVE-2017-5715). Das bedeutet, dass ein
> Angreifer den Speicher „benachbarter“ Prozesse bzw. VMs auslesen
> kann. Spectre missbraucht ein grundlegendes Problem bestimmter
> Prozessor-Optimierungen (Out-of-order Execution und Speculative
> Execution), daher betrifft es alle Prozessoren, die diese Features
> besitzen: Intel, AMD, ARM, MIPS, Sparc, ... Dieses Problem zu
> beheben, ist daher auch um einiges schwieriger. Für Variante 2
> gibt es zumindest inzwischen einen vorläufigen Patch für den
> Compiler LLVM:
>
> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180101/513630.html
>
> Den aktuellen Stand bei FreeBSD findet man hier:
>
> https://lists.freebsd.org/pipermail/freebsd-security/2018-January/009719.html
>
> Falls es jemanden interessiert, wie so ein Spectre-Angriff in
> einem Programm grundsätzlich funktioniert:
>
> 1. Der Angreifer liest ein Byte an einer bestimmten Adresse aus,
> zu der er eigentlich keine Zugriffsberechtigung hat. Der
> Zugriff wird daher fehlschlagen, d.h. zu einem Memory-Fault
> führen.
>
> 2. Da ein Speicherzugriff immer etwas länger dauert, wartet der
> Prozessor das Ergebnis nicht ab, sondern führt bereits die
> nachfolgenden Anweisungen „spekulativ“ aus, bevor der Memory-
> Fault ausgelöst wird.
>
> 3. Die folgende Anweisung maskiert ein Bit des (vermeintlich)
> gelesenen Bytes heraus und greift in Abhängigkeit davon auf
> zwei verschiedene Adressen (nennen wir sie A0 und A1) zu, d.h.
> wenn das Bit 0 ist, wird auf A0 zugegriffen, und wenn es 1
> ist, wird auf A1 zugegriffen. Wo A0 und A1 liegen, spielt
> keine Rolle, sie sollten nur in unterschiedlichen Cache-Lines
> liegen. Ihr Inhalt ist auch egal und interessiert nicht.
>
> 4. Der Memory-Fault, der nun irgendwann zuschlägt, führt dazu,
> dass der Prozessor das Byte aus Schritt 1. natürlich nicht
> herausrückt, und die spekulativ ausgeführten Schritte (3.),
> die auf dem Inhalt dieses Bytes basieren, werden auch wieder
> verworfen.
>
> 5. Das Programm muss natürlich dafür sorgen, dass es trotzdem
> weiterläuft, z.B. durch einen Trap-Handler (SIGSEGV), oder
> es lässt den Thread/Prozess einfach sterben und setzt den
> Ablauf in einem Schwester-Prozess fort.
>
> 6. Obwohl der Prozessor die spekulativen Schritte verworfen hat,
> haben sie einen Seiteneffekt: Der Inhalt von A0 *oder* A1
> wurde in den Cache geholt und befindet sich noch dort.
>
> 7. Das Programm muss jetzt also nur einen kleinen Timing-Test
> machen, indem es misst, wie lange ein Zugriff auf A0 und A1
> dauert. Je nachdem, welches der beiden schneller ist, weiß
> das Programm, welche Adresse bereits vorher in den Cache
> geladen wurde, und somit, welchen Wert das fragliche Bit
> hatte.
>
> 8. Obige Schritte können beliebig oft wiederholt werden, um die
> Bits (und somit Bytes) zu erhalten, die einen interessieren,
> und auf die man eigentlich keine Zugriffsberechtigung hat.
> Das klingt jetzt nach eine Riesenaufwand für jedes einzelne
> Bit, aber in der Praxis (mit dem PoC-Code) kann man auf einer
> halbwegs schnellen CPU mehrere hundert KByte/s lesen, was
> für typische Angriffsszenarien völlig ausreichend ist.
>
> Gruß
> Olli
>
>
>
> --
> Oliver Fromme, München -- FreeBSD + DragonFly BSD
>
> ``We are all but compressed light'' - Albert Einstein
>

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 11 Jan 2018 - 01:24:41 CET