Solche Kernel-Patches in Desktop-Systemen notwendig?

[M.P.]

Dass eine virtuelle Maschine nicht in die Daten einer anderen VM schauen kann, ist natürlich wichtig, aber auf einem Desktop-System?
Da kann sich maximal ein Prozess die Daten eines anderen Prozesses anschauen.

[Vanger]

M.P. schrieb:
--------------------------------------------------------------------------------
> Dass eine virtuelle Maschine nicht in die Daten einer anderen VM schauen
> kann, ist natürlich wichtig, aber auf einem Desktop-System?
> Da kann sich maximal ein Prozess die Daten eines anderen Prozesses
> anschauen.

Jein. Theoretisch sind diese Lücken auch auf Desktop-Systemen ausnutzbar. Ein häufig zitierte Lücke betrifft das auslesen des Passwortspeichers eines Webbrowsers mittels JavaScript. Das wurde behoben indem man JavaScript die Möglichkeit genommen hat die für den Exploit notwendige sehr genaue Zeitmessung durchzuführen. Die praktische Ausnutzbarkeit ist und bleibt auf dem Desktop daher beschränkt. Da kann man sich tatsächlich darauf verlassen was die Prozessorhersteller und Kernel-Entwickler entscheiden: einige Mitigations sind auch jetzt noch per Default ausgeschaltet weil die Reduktion der praktischen Angriffsfläche nicht die Leistungseinbußen rechtfertigt. In virtualisierten Umgebungen kann diese Abwägung aber fundamental anders aussehen - weshalb VMware da natürlich ein gesteigertes Interesse dran hat.

[silentcreek]

M.P. schrieb:
--------------------------------------------------------------------------------
> Dass eine virtuelle Maschine nicht in die Daten einer anderen VM schauen
> kann, ist natürlich wichtig, aber auf einem Desktop-System?
> Da kann sich maximal ein Prozess die Daten eines anderen Prozesses
> anschauen.

Im Zweifel ist "ein Prozess" dein Browser, der JavaScript oder WebAssembly ausführt, und "die Daten" sind Passwörter oder Schlüssel im Arbeitsspeicher. Hier ist beispielsweise ein solcher Angriff beschrieben: https://download.vusec.net/papers/spring_woot22.pdf

Jetzt ist natürlich die Frage, wie häufig solche Angriffe tatsächlich in freier Wildbahn vorkommen. Insofern kann man, praktisch betrachtet, durchaus dafür plädieren, die Schutzmaßnahmen zu deaktivieren.

Aber da sich die Schutzmaßahmen im Desktopalltag bei mir nur sehr selten bemerkbar machen und man ja auch nie weiß, ob wie sich die Exploits da weiterentwickeln, lasse ich sie aktiviert. (Ich habe schon bemerkt, dass das Kernel kompilieren, was ich ab und zu mache, etwas länger dauert, aber ansonsten habe ich das nur in synthetischen Benchmarks messen können.)

[silentcreek]

Vanger schrieb:
--------------------------------------------------------------------------------
> Ein häufig zitierte Lücke betrifft das auslesen des Passwortspeichers eines
> Webbrowsers mittels JavaScript. Das wurde behoben indem man JavaScript die
> Möglichkeit genommen hat die für den Exploit notwendige sehr genaue
> Zeitmessung durchzuführen.
Das oben von mir verlinkte Paper beschreibt einen Angriff, der selbst mit diesen ungenaueren Timern (und anderen Schutzmaßnahmen), erfolgreich ist. Damit allein ist es also nicht getan.

Trotzdem glaube ich, dass du mit dem nächsten Satz noch immer recht hast:
> Die praktische Ausnutzbarkeit ist und bleibt auf dem Desktop daher beschränkt.

Wie lange das so "bleibt", wissen aber wohl nur diejenigen, die da hartnäckig versuchen, diese Lücken zu finden und auszunutzen.

[M.P.]

Hmm die ganzen Beispiele führen ja keinen Betriebssystem Code aus. Müsste da nicht eher der Code des Browsers selber gehärtet werden?

[Vanger]

M.P. schrieb:
--------------------------------------------------------------------------------
> Hmm die ganzen Beispiele führen ja keinen Betriebssystem Code aus. Müsste
> da nicht eher der Code des Browsers selber gehärtet werden?

Nein. Das ist ja gerade das perfide an dieser Familie von Sicherheitslücken.

Anwendungen - wie ein Browser - können versuchen die Angriffsfläche zu verkleinern indem sie es Exploits erschweren die Lücke auszunutzen, prinzipiell lösen können die Anwendungen das aber nicht. So haben erste JavaScript-basierte Exploits in Browsern auf einer äußerst genauen Zeitmessung basiert, weshalb Browser die Genauigkeit der Zeitmessung begrenzt und damit den Exploit unbrauchbar gemacht haben. Das stopft die Lücke aber ja nicht - weshalb es inzwischen auch Exploits gibt die nun auch mit der deutlich ungenaueren Zeitmessung funktionieren.

Die Sicherheitslücken stecken weder in der Anwendung noch im Kernel, sondern in der Hardware. Auch die Kernel Mitigations versuchen letztendlich nur die Angriffsfläche kleiner zu machen, die Lücke wirklich schließen können nur die CPU-Hersteller - und das z.T. nur in der physischen Hardware, nicht mal mittels Firmware. Letzteres tun die CPU-Hersteller aber auch nur teilweise - was durchaus auch wünschenswert ist: Dem aktuellen Forschungsstand nach lässt sich das nur dann vollständig lösen, wenn man auf einen Gutteil der Leistungssteigerung der letzten Jahre und Jahrzehnte verzichtet. Das möchte kaum einer...



1 mal bearbeitet, zuletzt am 12.09.22 22:01 durch Vanger.