xexex schrieb:
Mit dem Angriff ist es aber nicht möglich den gesamten Speicher in Echtzeit zu überwachen. Ich habe nie behauptet die ganze Geschichte wäre Blödsinn, es wird aber auch bewusst vom Worstcase ausgegangen. Um dein Kennwort abzugreifen müsste eine Malware bereits im Hintergrund laufen und mit etwas Glück die Adresse der Applikation kennen in die du dein Kennwort eingibst.
Google hat ja am Beispiel gezeigt, wie sie Kennwörter im Klartext von einem Apache Server auslesen können. Es ist aber auch ein Sicherheitsrisiko, dass anscheinend der Apache Server die Kennwörter unverschlüsselt im Speicher hält. Dass es bei weitem nicht auf jede Applikation zutrifft habe ich bereits anhand von DPAPI unter Windows aufgeführt.
[...]
Im "Normalfall" haben jedoch Klartextkennwörter im RAM, aus verschiedenen Gründen nichts verloren, das ist nicht erst seit Meltdown so.
Der Wikipedia-Artikel widerspricht sich selbst und dir aber mittlerweile...
Suppose the attacker is in control of an unprivileged user-space process, which is normally prevented from reading at a protected memory address Ap by the CPU's memory protection mechanism. To circumvent such memory protection and read bit 0 at Ap, the attacker executes the following sequence of instructions:
1. Clears the cache for (attacker's address space, accessible) addresses A0u and A1u
2. Reads the value V(Ap) of a protected memory location at address Ap to a register
3. Crafts, as Axu, via a bitwise arithmetic operation, address A0u or A1u, depending on the value of bit 0 of V(Ap)
4. Reads the memory at address Axu
The CPU's memory protection mechanism will raise a memory protection fault when reading from the protected address Ap at step 2. However, since waiting for the memory protection hardware to finish its checks can cause significant slowdowns, affected CPUs will actually execute steps 2--4 speculatively, and only annul their effects when the memory protection fault gets detected some clock cycles later. Only the so-called "architectural" effects are annulled; the speculative execution of step 4 causes the memory at Axu to be loaded into the cache, and this is not undone. The attacker then reads, via a previously forked process or a memory transaction, (Anmerkung sun_set_1: richtig, hier braucht man Zusatzsoftware. Dazu später mehr) "his" A0u and A1u, timing both accesses. This timing will determine which of the two locations is now in cache, and thus reveal the value of memory bit 0 at address Ap. (Hier kennst Du mit b0 auf Ap d
Repeating the above for other bits of V(Ap) will reveal those other bits as well.
(Counter und Schleife in den Befehl, das wars. Du kannst jeden Bereich den du möchtest automatisiert auslesen)
The above depends on the implementation of the address translation mechanism in the OS and the underlying hardware architecture. The attack can reveal the content of any memory which is mapped into a user address space, even if otherwise protected.
Bei dem Wikipedia Beispiel geht es um das praktische Auslesen eines Speicherbereiches.
Ein Teil des Meltdown Bugs ist aber, dass auch Memory Mapping’s geleaked werden können. Das geht implizit auch aus dem Wikipedia Artikel hervor. Du kannst Bit 0 von Ap bestimmen, sprich den Anfang des geschützten Speichers.
Nach Schritt 2 ist dieser erstmal auf hold und die memory protection läuft durch. Sie braucht aber 2bis 3 Taktungen währenddessen Du als Angreifer prinzipiell tun und lassen kannst was Du möchtest, da Intel x86 nun ohne Überprüfung im Rahmen der speculative execution Schritt 3 und 4 ausführt. Anstelle von Speicherinhalten, liest man also einfach zunächst die Memory Mappings aus. Bye Bye ASLR.
Die Daten in Ap sind nicht verschlüsselt, da dies ja der Bereich ist der eigentlich verschlüsselt ist. Sobald die CPU hieraus aber Daten ausliest, muss das natürlich im Klartext geschehen. Wie sollten verschlüsselte Daten sonst jemals verarbeitet werden?
Det is ja dat Dilemma.
Hier auch nochmal von arstechnica
The first wind of this problem came from researchers from Graz Technical University in Austria. The information leakage they discovered was enough to undermine kernel mode Address Space Layout Randomization (kernel ASLR, or KASLR).
https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/
Wie in allen Artikeln geschrieben, war aber das der Uni Graz erstmal der kickoff des ganzen Problemes.
Was den Einwand von Dir mit der Zusatzsoftware angeht.
Bekanntermaßen muss man Code auf dem System ausführen können um die Lücke zu nutzen. Sobald ich aber ein Drive-by, worüber auch immer, generiere (Website, Applikation, USB-Stick) ist doch das alle n überhaupt kein Problem. Die Fähigkeit Code auszuführen und zB potenzielle Programme zu identifizieren, ist doch Grundvoraussetzung für das Nutzen der Lücke. Daher erschließt sich mir das Argument nicht ganz.
Man kann auch sagen, „man muss erstmal aufs System kommen“.
- Ja, ok. Das war soweit bekannt? Bzw ist bei letztlich jedem Hack so.
Es geht doch darum, dass dann alle weiteren Mechanismen wie eben ASLR die UAC, Richtlinien, bla bla nicht mehr greifen.