hikaru hat geschrieben: 30.01.2018 13:11:30
Meinem Verständnis nach muss nur IRGENDWER ausgewählten Code ausführen, der in ein Register schreibt, in das auch das Opfer schreibt.
Muss er nur das? Ich weiß es nicht. Das Spectre-Papier hält sich da sehr zurück mit allgemeingültigen Aussagen über die praktische Anwendbarkeit. Auch der Beispielcode zeigt nur, wie ein Programm sich selber aushorchen kann.
Relevante Aussagen (mMn) dazu:
Spectre attacks induce a victim to speculatively perform
operations that would not occur during correct program
execution and which leak the victim’s confidential infor-
mation via a side channel to the adversary.
Das Opfer muss also selber den Code ausführen, der ihn in die Pfanne haut. Ich schließe daraus, dass irgendeine Prüfung der Speicherzugriffsberechtigungen doch greift.
During the second phase, the processor speculatively
executes instruction(s) that transfer confidential informa-
tion from the victim context into a microarchitectural
side channel.
Der Angriffscode muss also im Kontext des Opfers ausgeführt werden.
This may be triggered by having the at-
tacker request that the victim to perform an action (e.g.,
via a syscall, socket, file, etc.).
Das Opfer muss also gut fernsteuerbar sein, also irgendwie an- oder aufrufbar sein.
Andere Teile des Textes erwecken den Eindruck, dass ich nur die Sprungvorhersage trainieren müsste, dann ein X mit einem Wert außerhalb des legalen Wertebereiches übergebe, und schon kann ich den gesamten Speicher auch außerhalb meines Prozesses auslesen. Ganz so einfach kann's nicht sein. Zumindest nicht außerhalb des eigenen Prozesses.
Weiter unten finden sich weitere interessante Informationshäppchen:
Speculative execution was only observed when the
branch destination address was executable by the vic-
tim thread, so gadgets need to be present in the mem-
ory regions executable by the victim.
Die gesamte Sprungvorhersage findet also nicht immer statt, sondern nur unter bestimmten Umständen.
Du musst also erstens geeigneten Code finden der nicht nur ausnutzbar ist sondern auch Zugriff auf möglichst viel Speicher der Opfers gewährt und dann musst du das Opfer dazu bringen, in enger Synchronisation mir dir diesen Code immer wieder auszuführen und direkt danach die Reaktionsgeschwindigkeit des Caches messen.
In ihrer "Example Implementation on Windows" beschreiben sie das dann etwas anders. Ein Prozess wird ohne jegliche Synchronisation ausgehorcht. Dazu stellen sie Laborbedingungen her. Der einzige CPU-Kern, bestehend aus zwei HT-Kernen, wird zur Hälfte komplett von den Cache-Lausch-Prozessen eingenommen. Auf dem zweiten HT-Kern läuft der Sprungvorhersage-Trainer. Und der Sprungvorsage-Trainer weiß, wenn er gerade nicht läuft, dann läuft der anzugreifende Prozess. Hier hast du also den seltenen Luxus, den Cache die ganze Zeit überwachen zu können und genau zu wissen, wann der anzugreifende Prozess läuft. Es läuft nämlich nur ein einziger gutartiger Prozess auf dem System. Und du weißt auch genau, was dieser Prozess dann tut, nämlich ein Sleep(). Dadurch kannst du dir die Synchronisation sparen. Wie sie dem anzugreifenden Prozess dann eigene Registerwerte unterschieben, ganz ohne Funktionsaufrufe, verstehe ich dann aber nicht mehr so recht ...
Aber auch hier gibt es einen Kontextwechsel, zwischen Sprungvorhersage-Trainer und anzugreifendem Prozess.
Du brauchst also Kontextwechsel und du brauchst eine enge Synchronisation. Du musst das Opfer immer wieder dazu bringen, den ausgewählten Code in seinem Kontext auszuführen, nachdem du vorher die Sprungvorhersage zu einer falschen Entscheidung trainiert hast. Sicher kann das auch IRGENDEIN Prozess für dich machen, dann musst du den aber auch noch steuern und dich mit ihm synchronisieren.
Soweit zumindest mein bisheriges Verständnis. Ich lasse mich (in diesem Fall un-)gerne eines Besseren belehren.
hikaru hat geschrieben: 30.01.2018 13:11:30
denn meinem Verständnis nach [...] hängt der gerade geschilderte Angriff davon ab, ob mehrere Threads sich eine gemeinsame Sprungvorhersage teilen, was ich insbesondere bei HT für plausibel hielte.
Das musst du nicht "halten", es ist anscheinend so:
Tests, primarily on a Haswell-based Surface Pro 3, con-
firmed that code executing in one hyper-thread of Intel
x86 processors can mistrain the branch predictor for code
running on the same CPU in a different hyper-thread.
Wobei "mistrain" noch nicht bedeutet, dass es auch ausnutzbar ist. In ihrer "Example Implementation on Windows" geben sie sich ja etwas mehr Mühe, um zum Erfolg zu kommen. Da sind wieder Kontextwechsel nötig.
hikaru hat geschrieben: 30.01.2018 13:11:30
Aber es hilft uns nicht, dass weit fähigere Leute als wir genauso wie das Schwein in's Uhrwerk schauen.
Fakt ist, dass sich eine bestimmte CPU auf eine bestimmte Weise verhält. Dieses Verhalten ist ausschlaggebend für die Risikobewertung. Wer über das Verhalten bescheid weiß und wer nicht, ändert an der Sachlage des Risikos nichts.
Wir sind aber nur Schweine, die von außen auf die Uhr schauen und merken, dass sie falsch geht. Genauer gesagt merken wir, dass zig Uhren unterschiedlicher Hersteller falsch gehen. Dass da ein Uhrwerk drin ist, wissen wir nur, weil der Hersteller es uns gesagt hat. Bei der Risikobewertung müssen wir uns auch auf den Hersteller verlassen - unter dem Vorbehalt, dass wir ihn irgendwann der Lüge überführen. Sicherlich wäre es wünschenswerter wenn wir mehr wüssten ... aber aus meiner Sicht bleiben das fromme Wünsche und Spekulationen.
hikaru hat geschrieben: 30.01.2018 13:11:30
Irgendwo habe ich gelesen, dass LPDDR4 hardwareseitig immun gegen Rowhammer sei. Ich kenne allerdings keine Details, wie das erreicht wird oder warum das nur für LPDDR4 gilt.
Also das ging ungefähr so: "Oh. DDR3 ist anfällig gegen Rowhammer? Na, dann machen wir DDR4 besser!".
Und dann passierte das hier:
https://arstechnica.com/information-tec ... rowhammer/
Und dann hieß es "Oh, Mist, na wer konnte das schon ahnen. Aber dafür machen wir jetzt LPDDR4 besser!"
Und dann passierte das hier:
https://arxiv.org/pdf/1710.00551.pdf
Unter "Rowhammer Elimination Countermeasures." und "B. Rowhammer mitigations in hardware".
hikaru hat geschrieben: 30.01.2018 13:11:30
Meltdown ist doch nur ein Spezialfall von Spectre, der sich in Angriffsvektor und Behandlung dadurch auszeichnet, dass ein Kontextwechsel nicht (nur) zwischen Prozessen auf gleicher Privilegebene passiert, sondern dass dabei die Privilegebene gewechselt wird. Oder sehe ich das falsch?
Ich werd mich hüten, dass als falsch zu bezeichnen, so abstrakt wie du es ausgedrückt hast, aber aus meiner Sicht ist Meltdown eine völlig eigenständige Sicherheitslücke, die sich aus einem Fehler in Intels out-of-order execution ergibt. Sie hat so gar nichts mit der Sprungvorhersage zu tun, ist wesentlich besser verstanden, leichter ausnutzbar und leichter patchbar.
hikaru hat geschrieben: 30.01.2018 13:11:30
Falls meine Überlegungen zu IBPB und SMP zutreffen, dann wäre allerdings innerhalb des Kernelspace' ein Spectre-Angriff von einem Tätermodul auf andere Teile des Kernels möglich.
Unabhängig davon, ob deine Überlegungen stimmen, hast du Recht:
http://nvidia.custhelp.com/app/answers/detail/a_id/4611
Nvidia hält seine Treiber durch Meltdown nicht für angreifbar. Die Anpassungen zielen auf Spectre.
Wobei sie sich bei Linux etwas schwammig ausdrücken:
The Linux driver contains updates to maintain compatibility with recent Linux updates for this security issue.
Wobei das noch nicht meine Frage beantwortet, ob das nur Nvidias Treiber betrifft oder ob sämtliche Treiber für proprietäre Althardware angepasst werden müssen.
Alle anonymen Zitate von hier:
https://spectreattack.com/spectre.pdf
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001