CED999 schrieb:
Das wäre schön dann wäre alles easy, das stimmt aber leider nicht. Javascript läuft clientseitig, also bei Dir auf dem Rechner während Du gerade die Computerbase Seite liest.
Ich weiss, wie Spectre, Meltdown und Konsorten funktionieren.
Wer zur Hölle würde über einen Exploit von Javascript Spectre ausführen wollen?
Das ist eine der "unpraktischsten" Sicherheitslücken überhaupt.
Da les ich mit zig anderen Methoden 50mal schneller relevante Daten aus, als mit Spectre.
Zudem wer macht auf einer in einem professionellen Umfeld eingesetzten Server VM einen Browser mit Javascript auf, der nicht über eine Deep- Inspection Firewall gesichert bzw. gepatcht ist?
Als Einfallstor kämen dann sowieso nur Terminalserver/Admin bzw. Verwaltungs VMs in Frage...
Wie findet der Angreifer heraus, dass das genau DER Server ist, den er auf einer zufällig physikalisch "eingefangenen" Maschine kompromittiert hat?
Und wieso sollte ich eine randomisierte Attacke mit einer so ineffektiven Methode starten wollen?
Was auch echt erschreckend ist wie die "Evolution von Spectre" verläuft, mittlerweile ist schon eine Attacke
OHNE jeden Schadcode auf das Zielsystem einschleußen zu müssen möglich:
https://www.heise.de/security/meldung/NetSpectre-liest-RAM-via-Netzwerk-aus-4121831.html
Jetzt sind 15 bit die Stunde natürlich sehr langsam. Aber die Attacke kann nahezu unbegrenzte Zeit laufen. Mich erschreckt etwas wie die Puzzleteile immer mehr zusammenkommen, muss nur noch ein Abschätzung dazu kommen in welchem Bereich vom RAM die Passwörter liegen, dann ist das Fukushima perfekt.
Ja- Aber auch da hast Du im Normalfall gesteuerten Netzwerkverkehr zwischen den VMs. Wo sollen denn dann die 15Bit/Stunde hinlaufen?
Und zweitens- Weisst Du wie immens hoch der Datenumlauf sein muss, bis Du im Cache mal irgendwas brauchbares Auslesen könntest, ohne die Einsprungsadressen zu kennen (das sind immer diese proof of concept Videos, wo man sieht, dass das Offset und der Einstiegspunkt vorher schon bekannt sind)?
Und dann muss ja immernoch eine korrekte Hook, oder ein konsistenter Data- Header da sein, so dass Du überhaupt den "zerschredderten Datenmüll" von richtiger Information unterscheiden kannst.
Und es darf beim Auslesevorgang kein "flush" erfolgen, weil sonst wieder nur Datenmüll rauskommt.
Meltdown/Spectre und Co. tut sich kein Hacker der Welt an. Der kommt anderweitig x- mal effektiver, einfacher und erfolgsversprechender an die Daten, auf die er es abgesehen hat.
Das stimmt natürlich. Theoretisch sehr mächtige Angriffsmethoden sind am Anfang nicht sehr praktisch einzusetzen. Das war mit der Atombombe auch lange so, bis sie dann richtig funktioiniert hat. Bei Spectre wird ja andauernd was neues entdeckt und die Forscher beklagen sich über die Ignoranz von AMD und Intel nicht richtig dagegen anzugehen.
Die Angriffsvarianten, die hier zur Diskussion stehen sind per Design schlecht nutzbar.
Ich sehe Spectre nicth als Konkurrenz zu einer Ransomeware die im Anhang einer E-Mail verschickt wird. Es ist eher der Hack für Leute, die noch nie gehackt wurden (aber wer kann schon Javascript im Internet ausschalten).
Wie gesagt- Auch mit Javascript läuft Code im Hintergrund ab. Dies mit spezieller Signatur.
Somit würde das in Zukunft, selbst wenn es eingesetzt würde, was ich für geradezu absurd aufwendig halte, durch einfache Verhaltensüberwachung aufgespürt werden können.
Wenn hier nicht in nächster Zeit eine effiziente Art einer Ausnutzung herausgeforscht wird, dann sind diese Sicherheitslücken zwar da, aber letztenendes leblos und nutzlos in der freien Wildbahn.
Now, that all said, kernel bugs tend to be tricky to exploit, and the requirement for having local access further limits the offensive use. Now, “local access” usually means that the attacker needs to have an authenticated account and the ability to install and run code on the target computer, but it’s important to note that this condition can be achieved by, say, a malicious Javascript application running in your browser. But, since it's merely a memory read issue, attackers don't get a straight shot at privilege escalation with this, and there's going to be some luck involved to have useful-to-attackers data in active memory when these techniques are used.
Die Hürden für den erfolgreichen Einsatz sind einfach "derzeit" viel zu hoch.
LG
Zero
