News Weitere CPU-Lücken ret2spec und SpectreRSB entdeckt
- Ersteller Nero24
- Erstellt am
-
- Schlagworte
- ret2spec spectre spectrersb
★ Themenstarter ★
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.058
- Renomée
- 10.440
Nach Bekanntwerden der Sicherheitslücken in modernen Prozessor-Designs – Meltdown und Spectre – Anfang des Jahres, sowie der bisher nicht vollständig veröffentlichten, von der Presse Spectre-NG genannten Schwachstellen, sind nun weitere Lücken öffentlich geworden, die Ähnlichkeiten zu den bisherigen Schwachstellen aufweisen, im Detail aber dennoch anderes sind.
(…)
» Artikel lesen
(…)
» Artikel lesen
Hi Nero,
ich glaube AMD ist gegenüber dem Intel-PoC geschützt. Denn die Unterschiede im RSB zwischen Intel und AMD Arch sind nicht gerade klein !
Die Autoren von ret2spec schreiben ja selbst:
"According to a recent study [37], most Intel CPUs use the cyclic behavior described in variant (c), while AMD’s use variant (a) and stop prediction upon RSB underflows."
Wenn AMD aber die Prediction einstellt bei "underflow" kann der Angriff nicht ablaufen da der Schritt A1 nicht "ausgeführt" werden kann.
AMD hat denke ich bestätigt dass es wohl prinzipiell denkbar ist einen Angriff zu schreiben für den AMD-eigenen RSB - aber das muss erstmal gezeigt werden.
"As is" ist ret2spec damit denke ich nur auf Intel anwendbar.
ARM dürfte auch deutlich von Intel verschieden sein was die Funktionalität des RSB betrifft, Power IBM erst recht.
Die Autoren schreiben ja selbst:
AMD / ARM:
"Although we have not tested our attacks against ARM and AMD architectures, they acknowledged the general problem."
Ich lese das so - prinzipiell ist ein Angriff auch auf unseren RSB denkbar - aber sicherlich NICHT mit der hier beschriebenen Methode.
Ganz analog schreiben die SpectreRSB Autoren:
"Although we did not demonstrate attacks on AMD and ARM processors, they also use RSBs to predict return addresses."
Da AMD und ARM ebenfalls grundsätzlich RSBs benutzen ist es denkbar dass man einen Angriff auf diese RSB-Architekturen auch finden KANN. Was AMD und ARM ja auch grundsätzlich "bestätigen"....
Bei SpectreRSB werden 4 Quellen (S1 - S4) für den Angriff genannt. Bei S1 führen die Autoren aus das man versucht entweder direkt einen RSB-Underfill (underflow) zu erzeugen, oder diesen "indirekt" erzeugt indem man den RSB "Overflowed" was dann dazu führt dass der RSB-quasi geleert ist bzw. identisch "präpariert" ist wie beim Underflow.
Der Clou kommt aber noch:
"In an underfill, there is no value available on the RSB to guide speculation. Different CPUs handle this situation differently. For example, the Intel CPUs that we checked switch over to the branch predictor if the RSB is empty, which can be used to trigger attacks through the branch predictor [25]. However, AMD appears not to follow this strategy."
Intel CPUs wechseln dann einfach auf den Branch Predictor Table wenn der RSB "leer" ist (underflow bzw. overflow getriggerted underflow). AMD jedoch tut dies nicht.
(Womit dieser Angriffsvektor nicht funktioniert !)
Der Vektor über S2 scheint wohl allgemeiner zu funktioniert - bin mir aber nicht sicher.
Für den Vektor S3 muss wirklich JEDE Mikroarchitektur getrennt untersucht werden und entsprechend angepasste "PoCs" benutzt werden.
"Speculative pollution of the RSB: speculatively executed calls push a value on the stack, although the details are specific to the architecture."
S4 funktioniert nur wenn die "Rechte-Prüfung" des Prozesses nicht "stattfindet" und so ein unkonrollierter Wechsel z.B. in den Kernel-Ring "erlaubt" ist.
(Stichwort Meltdown). Das dürfte @AMD auch nicht gehen. Weswegen die Autoren auch den Speziellen Fall des Intel SGX im Kontext wohl erwähnen.
"RSB use across execution contexts: on a context switch the RSB values left over from an executing thread are reused by the next thread. Once we switch to a new thread, if the thread executes a return, then it will misspeculate to an address provided by the original thread. The same is true with a switch over to the Operating System (provided RSB refilling is not implemented), or to an SGX context."
Ich bin mir nicht 100% sicher aber es könnte sogar sein dass eine zwingende Vorraussetzung für das funktionieren dieser SpectreRSB-Attacke die Rechteausweitung ist die bei Meltdown im Vordergrund steht und die so in dieser Form @AMD NICHT funktioniert.
In Kapitel 4 vom SpectreRSB-Paper steht:
"On an unpatched machine, this attack (Anm. SpectreRSB) enables the attacker to read kernel memory via the Meltdown bug."
Bei den einzelnen Angriffsbeispielen sind auch interessante Randnotizen: Bei Attack 2a z.B.:
"This attack requires a machine without SMEP enabled. We demonstrated the attack with SMEP disabled."
SMEP ist ein CPU feature AFAIK - jedoch haben alle AMD CPUs mindestens seit Bulldozer SMEP und SMAP aktiv ? Und bei Intel ist es ab Broadwell (?) auch mit an Bord.
Besonders kritisch ist aber Attack3: Attack results:This attack successfully works on fully patched machines. The attack bypasses all software and
microcode patches:it bypasses Retpoline since no indirect jumps are used. It bypasses the microcode patches since they do not appear to limit speculation through the
RSB. It bypasses RSB refilling (which is only implemented on Skylake+, but not on the Xeon processors) since no mode switches to the kernel are triggered dur
ing the attack. Thus, SGX is vulnerable to SpectreRSB even on fully patched machines.
Allerdings entzieht sich meiner Kenntnis ob Attacke3 über den AMD-RSB überhaupt so anwendbar ist...(da ja scheinbar als Grundvorraussetzung der Meltdown-Bug präsent sein muss ?). Bin mir da aber nicht sicher.
Allerdings schreiben die Autoren selbst:
"Hardware Solutions: It is almost certain that future generations of CPUs will be designed to mitigate Meltdown and Spectre class attacks. To protect against Meltdown,it is possible to move the permission checks earlier in the pipeline, preventing the temporary load of the secret data. It is likely that AMD and ARM already implement this defense."
Und da sie weiter oben was davon schreiben dass der "Meltdown-Bug" zwingende Vorraussetzung für die Angriffe mit SpectreRSB ist - Hat Intel hier also die A-Karte ?
Außerdem scheinen viele der Spectre-NG Lücken darauf aufzubauen dass man @Intel keine Kontext-Prüfung durchführt (Meltdown).
KPTI war also nur ein Tropfen auf den heissen Stein und schliesst den direkten Meltdown-Vektor, aber alle Vektoren die sich aus Spectre V1/Spectre V2 ergeben und dann auf "Meltdown" checken funktionieren @Intel nach wie vor.
Ich will damit nicht sagen AMD ist von dem allen völlig unbetroffen - aber wie mir scheint ist den Forschern nun klar geworden dass WENN man eine Attacken auf den RSB machen will man eben schon die Unterschiede zumindest von Architektur-Familien berücksichtigen muss, da die jeweiligen Implementationen des RSB und wie dieser befüllt, geleert und ausgelesen wird sich doch zum Teil erheblich unterscheiden.
Man wird also wenn dann "speziell angepasste" PoCs entwickeln müssen die @Bulldozer bzw. funktionieren. Die bisherigen Exploits gehen nur @Intel Core2 nach meinem Verständnis.
ich glaube AMD ist gegenüber dem Intel-PoC geschützt. Denn die Unterschiede im RSB zwischen Intel und AMD Arch sind nicht gerade klein !
Die Autoren von ret2spec schreiben ja selbst:
"According to a recent study [37], most Intel CPUs use the cyclic behavior described in variant (c), while AMD’s use variant (a) and stop prediction upon RSB underflows."
Wenn AMD aber die Prediction einstellt bei "underflow" kann der Angriff nicht ablaufen da der Schritt A1 nicht "ausgeführt" werden kann.
AMD hat denke ich bestätigt dass es wohl prinzipiell denkbar ist einen Angriff zu schreiben für den AMD-eigenen RSB - aber das muss erstmal gezeigt werden.
"As is" ist ret2spec damit denke ich nur auf Intel anwendbar.
ARM dürfte auch deutlich von Intel verschieden sein was die Funktionalität des RSB betrifft, Power IBM erst recht.
Die Autoren schreiben ja selbst:
AMD / ARM:
"Although we have not tested our attacks against ARM and AMD architectures, they acknowledged the general problem."
Ich lese das so - prinzipiell ist ein Angriff auch auf unseren RSB denkbar - aber sicherlich NICHT mit der hier beschriebenen Methode.
Ganz analog schreiben die SpectreRSB Autoren:
"Although we did not demonstrate attacks on AMD and ARM processors, they also use RSBs to predict return addresses."
Da AMD und ARM ebenfalls grundsätzlich RSBs benutzen ist es denkbar dass man einen Angriff auf diese RSB-Architekturen auch finden KANN. Was AMD und ARM ja auch grundsätzlich "bestätigen"....
Bei SpectreRSB werden 4 Quellen (S1 - S4) für den Angriff genannt. Bei S1 führen die Autoren aus das man versucht entweder direkt einen RSB-Underfill (underflow) zu erzeugen, oder diesen "indirekt" erzeugt indem man den RSB "Overflowed" was dann dazu führt dass der RSB-quasi geleert ist bzw. identisch "präpariert" ist wie beim Underflow.
Der Clou kommt aber noch:
"In an underfill, there is no value available on the RSB to guide speculation. Different CPUs handle this situation differently. For example, the Intel CPUs that we checked switch over to the branch predictor if the RSB is empty, which can be used to trigger attacks through the branch predictor [25]. However, AMD appears not to follow this strategy."
Intel CPUs wechseln dann einfach auf den Branch Predictor Table wenn der RSB "leer" ist (underflow bzw. overflow getriggerted underflow). AMD jedoch tut dies nicht.
(Womit dieser Angriffsvektor nicht funktioniert !)
Der Vektor über S2 scheint wohl allgemeiner zu funktioniert - bin mir aber nicht sicher.
Für den Vektor S3 muss wirklich JEDE Mikroarchitektur getrennt untersucht werden und entsprechend angepasste "PoCs" benutzt werden.
"Speculative pollution of the RSB: speculatively executed calls push a value on the stack, although the details are specific to the architecture."
S4 funktioniert nur wenn die "Rechte-Prüfung" des Prozesses nicht "stattfindet" und so ein unkonrollierter Wechsel z.B. in den Kernel-Ring "erlaubt" ist.
(Stichwort Meltdown). Das dürfte @AMD auch nicht gehen. Weswegen die Autoren auch den Speziellen Fall des Intel SGX im Kontext wohl erwähnen.
"RSB use across execution contexts: on a context switch the RSB values left over from an executing thread are reused by the next thread. Once we switch to a new thread, if the thread executes a return, then it will misspeculate to an address provided by the original thread. The same is true with a switch over to the Operating System (provided RSB refilling is not implemented), or to an SGX context."
Ich bin mir nicht 100% sicher aber es könnte sogar sein dass eine zwingende Vorraussetzung für das funktionieren dieser SpectreRSB-Attacke die Rechteausweitung ist die bei Meltdown im Vordergrund steht und die so in dieser Form @AMD NICHT funktioniert.
In Kapitel 4 vom SpectreRSB-Paper steht:
"On an unpatched machine, this attack (Anm. SpectreRSB) enables the attacker to read kernel memory via the Meltdown bug."
Bei den einzelnen Angriffsbeispielen sind auch interessante Randnotizen: Bei Attack 2a z.B.:
"This attack requires a machine without SMEP enabled. We demonstrated the attack with SMEP disabled."
SMEP ist ein CPU feature AFAIK - jedoch haben alle AMD CPUs mindestens seit Bulldozer SMEP und SMAP aktiv ? Und bei Intel ist es ab Broadwell (?) auch mit an Bord.
Besonders kritisch ist aber Attack3: Attack results:This attack successfully works on fully patched machines. The attack bypasses all software and
microcode patches:it bypasses Retpoline since no indirect jumps are used. It bypasses the microcode patches since they do not appear to limit speculation through the
RSB. It bypasses RSB refilling (which is only implemented on Skylake+, but not on the Xeon processors) since no mode switches to the kernel are triggered dur
ing the attack. Thus, SGX is vulnerable to SpectreRSB even on fully patched machines.
Allerdings entzieht sich meiner Kenntnis ob Attacke3 über den AMD-RSB überhaupt so anwendbar ist...(da ja scheinbar als Grundvorraussetzung der Meltdown-Bug präsent sein muss ?). Bin mir da aber nicht sicher.
Allerdings schreiben die Autoren selbst:
"Hardware Solutions: It is almost certain that future generations of CPUs will be designed to mitigate Meltdown and Spectre class attacks. To protect against Meltdown,it is possible to move the permission checks earlier in the pipeline, preventing the temporary load of the secret data. It is likely that AMD and ARM already implement this defense."
Und da sie weiter oben was davon schreiben dass der "Meltdown-Bug" zwingende Vorraussetzung für die Angriffe mit SpectreRSB ist - Hat Intel hier also die A-Karte ?
Außerdem scheinen viele der Spectre-NG Lücken darauf aufzubauen dass man @Intel keine Kontext-Prüfung durchführt (Meltdown).
KPTI war also nur ein Tropfen auf den heissen Stein und schliesst den direkten Meltdown-Vektor, aber alle Vektoren die sich aus Spectre V1/Spectre V2 ergeben und dann auf "Meltdown" checken funktionieren @Intel nach wie vor.
Ich will damit nicht sagen AMD ist von dem allen völlig unbetroffen - aber wie mir scheint ist den Forschern nun klar geworden dass WENN man eine Attacken auf den RSB machen will man eben schon die Unterschiede zumindest von Architektur-Familien berücksichtigen muss, da die jeweiligen Implementationen des RSB und wie dieser befüllt, geleert und ausgelesen wird sich doch zum Teil erheblich unterscheiden.
Man wird also wenn dann "speziell angepasste" PoCs entwickeln müssen die @Bulldozer bzw. funktionieren. Die bisherigen Exploits gehen nur @Intel Core2 nach meinem Verständnis.
Zuletzt bearbeitet:
★ Themenstarter ★
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.058
- Renomée
- 10.440
@Iscaran:
wow, sehr ausführliche Analyse und Zusammenfassung!
Allerdings fürchte ich, dass AMD dies sehr deutlich kommuniziert hätte, falls man gänzlich nicht betroffen wäre davon; so wie sie es damals bei Meltdown gemacht haben:
https://www.planet3dnow.de/cms/3575...ecke-in-intel-cpus-update-amd-arm-bugfixes-2/
"Zero AMD vulnerability due to AMD architecture differences."
Das ist bisher aber nicht geschehen, obwohl die Bugs wenn ich das richtig lese schon im April an die Hersteller gemeldet wurden.
wow, sehr ausführliche Analyse und Zusammenfassung!
Allerdings fürchte ich, dass AMD dies sehr deutlich kommuniziert hätte, falls man gänzlich nicht betroffen wäre davon; so wie sie es damals bei Meltdown gemacht haben:
https://www.planet3dnow.de/cms/3575...ecke-in-intel-cpus-update-amd-arm-bugfixes-2/
"Zero AMD vulnerability due to AMD architecture differences."
Das ist bisher aber nicht geschehen, obwohl die Bugs wenn ich das richtig lese schon im April an die Hersteller gemeldet wurden.
Wie gesagt. Ich glaube schon dass AMD sich bewusst ist dass ein wie auch immer gearteter Angriff auf den AMD-eigenen RSB grundsätzlich NICHT auszuschliessen ist.
Aber ein Mit-Grund für die "Einfachheit" vor allem auch des Angriffs gegen SGX erscheint mir das fehlen der Kontext-Prüfung vor der Spekulation (Meltdown).
Allein dadurch sind die Spectre Angriffe @AMD scheinbar allesamt deutlich erschwert bzw. aber an den Kontext des Angreifenden Prozesses gebunden.
Womit wir FAST bei Bugs der Sorte "wenn ich Admin bin kann ich alles machen" sind. User-User Prozess angriffe sind "langweilig" - weil ich damit weder aus einer VM ausbrechen kann noch irgendwelche Prozesse angreifen kann die ich nicht selbst geschrieben habe.
Oder übersehe ich da etwas Grundlegendes ?
Aber ein Mit-Grund für die "Einfachheit" vor allem auch des Angriffs gegen SGX erscheint mir das fehlen der Kontext-Prüfung vor der Spekulation (Meltdown).
Allein dadurch sind die Spectre Angriffe @AMD scheinbar allesamt deutlich erschwert bzw. aber an den Kontext des Angreifenden Prozesses gebunden.
Womit wir FAST bei Bugs der Sorte "wenn ich Admin bin kann ich alles machen" sind. User-User Prozess angriffe sind "langweilig" - weil ich damit weder aus einer VM ausbrechen kann noch irgendwelche Prozesse angreifen kann die ich nicht selbst geschrieben habe.
Oder übersehe ich da etwas Grundlegendes ?
Zuletzt bearbeitet:
Complicated
Grand Admiral Special
Das ist auch der Grund warum Intel Retpoline nicht voll umfänglich für die beste Lösung hält. Schon Länger ist das bekannt:
https://stackoverflow.com/questions/48089426/what-is-a-retpoline-and-how-does-it-work
Ah - unter dem Aspekt erklärt sich das natürlich. Wohingen bei AMD es wohl reicht mit Retpoline zu sichern, da der Fallback nicht stattfindet.
Poor intel. Deswegen schiebt sich auch die neue Server Generation nach hinten - wetten ?! Die müssen erst ihren BTB/RSB redesignen um ihn Spectre "safer" zu machen....
Btw. ich hab mir mal folgende Kurzübersicht zusammengestellt mit den Spectre/Meltdown assozierten Lücken und deren Bezeichnungen um in dem wirrwarr noch die Übersicht zu bewahren - irgendwann wollte ich das noch ergänzen um die jeweiligen Mitigations....und auch die Betroffene CPU-Liste noch genauer ausführen....
Es gibt also bislang:
Spectre V1 = Bounds Check Bypass (BCB) = Variant 1 = CVE-2017-5753
alle CPUs mit Spekulativer Ausführung
Intel, AMD, ARM,...
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5753
Spectre V2 = Branch Target Injection (BTI) = Variant 2 = CVE-2017-5715
alle CPUs mit Spekulativer Ausführung
Intel, AMD, ARM,...
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715
Meltdown = Rogue Data Cache Load (RDCL) = Variant 3 = CVE-2017-5754
Intel, ARM (nur Variante 3a siehe auch CVE-2018-3640)
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5754
-----------------------------------------------------
ab hier folgend die sog. Spectre-NG Lücken
-----------------------------------------------------
Meltdown 3a = Rogue System Register Read (RSRR) = Variant 3a = Spectre-NG 1 = CVE-2018-3640
alle Intel ab Core, einge ARM CPUs (A15, A57, A72)
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3640
(eigentlich schon mit Meltdown "released" - damals noch als die ARM only Variante von Meltdown, hat später aber einen eigenen CVE Eintrag erhalten da man das auch wieder zurück auf Intel übertragen und verallgemeinern konnte)
Spectre V4 = Speculative Store Bypass (SSB) = Spectre-NG 2 = CVE-2018-3639
Intel, AMD, ABM, ARM,...
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3639
Lazy FP State Restore (Lazy FP) = Spectre-NG 3 = CVE-2018-3665
Intel, einige ARM (A15, A57, A72)
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3665
Spectre v1.1 / v1.2 = Bounds Check Bypass Store (BCBS) = Spectre-NG 4 = CVE-2018-3693
Intel, ARM, AMD nur v1.1
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3693
Spectre V5 = ret2spec
https://christian-rossow.de/publications/ret2spec-ccs2018.pdf
Spectre V6 = SpectreRSB
https://arxiv.org/pdf/1807.07940.pdf
------------------------------------------------------------------------
Unklar ob folgende Lücken in der Spectre-NG Reihe zählen
------------------------------------------------------------------------
SGXpectre = CVE-2017-5691 (Zuordnung nicht 100% sicher)
SGXPectre-Artikel https://arxiv.org/pdf/1802.09085.pdf
keine CVE-Nummer genannt.
Intel
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5691
------------------------------------------------------------------------
Weitere Interessante Side-Channel/Branch Predictor Attacken:
Meltdownprime / Spectreprime
https://arxiv.org/pdf/1802.03802.pdf
Total Meltdown = CVE-2018-1038
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1038
Fehler im Meltdown Patch für Win7SP1x64 und Win Server 2008x64
Branchscope = CVE-2018-9056
Intel, ARM,
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-9056
NetSpectre
https://arxiv.org/pdf/1802.03802.pdf
Angriff über Netzwerkpakete unter Ausnutzung von Spectre V1
Betrifft Alle Spectre V1, ABER sehr langsam
Mitigations gegen Spectre V1 sollten aber wirksam sein
------------------------------------------------------------------------
Hier ebenfalls als Zusammenstellung der meisten dieser Lücken zu finden:
https://www.us-cert.gov/ncas/alerts/TA18-141A
https://www.heise.de/security/meldung/NetSpectre-liest-RAM-via-Netzwerk-aus-4121831.html
Poor intel. Deswegen schiebt sich auch die neue Server Generation nach hinten - wetten ?! Die müssen erst ihren BTB/RSB redesignen um ihn Spectre "safer" zu machen....
Btw. ich hab mir mal folgende Kurzübersicht zusammengestellt mit den Spectre/Meltdown assozierten Lücken und deren Bezeichnungen um in dem wirrwarr noch die Übersicht zu bewahren - irgendwann wollte ich das noch ergänzen um die jeweiligen Mitigations....und auch die Betroffene CPU-Liste noch genauer ausführen....
Es gibt also bislang:
Spectre V1 = Bounds Check Bypass (BCB) = Variant 1 = CVE-2017-5753
alle CPUs mit Spekulativer Ausführung
Intel, AMD, ARM,...
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5753
Spectre V2 = Branch Target Injection (BTI) = Variant 2 = CVE-2017-5715
alle CPUs mit Spekulativer Ausführung
Intel, AMD, ARM,...
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715
Meltdown = Rogue Data Cache Load (RDCL) = Variant 3 = CVE-2017-5754
Intel, ARM (nur Variante 3a siehe auch CVE-2018-3640)
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5754
-----------------------------------------------------
ab hier folgend die sog. Spectre-NG Lücken
-----------------------------------------------------
Meltdown 3a = Rogue System Register Read (RSRR) = Variant 3a = Spectre-NG 1 = CVE-2018-3640
alle Intel ab Core, einge ARM CPUs (A15, A57, A72)
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3640
(eigentlich schon mit Meltdown "released" - damals noch als die ARM only Variante von Meltdown, hat später aber einen eigenen CVE Eintrag erhalten da man das auch wieder zurück auf Intel übertragen und verallgemeinern konnte)
Spectre V4 = Speculative Store Bypass (SSB) = Spectre-NG 2 = CVE-2018-3639
Intel, AMD, ABM, ARM,...
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3639
Lazy FP State Restore (Lazy FP) = Spectre-NG 3 = CVE-2018-3665
Intel, einige ARM (A15, A57, A72)
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3665
Spectre v1.1 / v1.2 = Bounds Check Bypass Store (BCBS) = Spectre-NG 4 = CVE-2018-3693
Intel, ARM, AMD nur v1.1
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3693
Spectre V5 = ret2spec
https://christian-rossow.de/publications/ret2spec-ccs2018.pdf
Spectre V6 = SpectreRSB
https://arxiv.org/pdf/1807.07940.pdf
------------------------------------------------------------------------
Unklar ob folgende Lücken in der Spectre-NG Reihe zählen
------------------------------------------------------------------------
SGXpectre = CVE-2017-5691 (Zuordnung nicht 100% sicher)
SGXPectre-Artikel https://arxiv.org/pdf/1802.09085.pdf
keine CVE-Nummer genannt.
Intel
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5691
------------------------------------------------------------------------
Weitere Interessante Side-Channel/Branch Predictor Attacken:
Meltdownprime / Spectreprime
https://arxiv.org/pdf/1802.03802.pdf
Total Meltdown = CVE-2018-1038
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1038
Fehler im Meltdown Patch für Win7SP1x64 und Win Server 2008x64
Branchscope = CVE-2018-9056
Intel, ARM,
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-9056
NetSpectre
https://arxiv.org/pdf/1802.03802.pdf
Angriff über Netzwerkpakete unter Ausnutzung von Spectre V1
Betrifft Alle Spectre V1, ABER sehr langsam
Mitigations gegen Spectre V1 sollten aber wirksam sein
------------------------------------------------------------------------
Hier ebenfalls als Zusammenstellung der meisten dieser Lücken zu finden:
https://www.us-cert.gov/ncas/alerts/TA18-141A
https://www.heise.de/security/meldung/NetSpectre-liest-RAM-via-Netzwerk-aus-4121831.html
Zuletzt bearbeitet:
Complicated
Grand Admiral Special
Tatsächlich würde ich AMD bei Spectre 2 raus nehmen. Immer noch kein PoC.
Dazu auch Lisa Su aktuell auf CNBC:
Dazu auch Lisa Su aktuell auf CNBC:
Wie es aussieht hat AMD bei der Zen Entwicklung das Problem in den Griff bekommen, bekannt war es ja. Und auch noch eine höhere IPC erreicht.
Die ganze Speicherverwaltung und Piplineaufbau total anders aufgebaut. Ist halt nicht so taktfreudig. Die Arbeit hat Intel noch vor sich, Hardware und Softwareseitig alles abzudichten.
Die ganze Speicherverwaltung und Piplineaufbau total anders aufgebaut. Ist halt nicht so taktfreudig. Die Arbeit hat Intel noch vor sich, Hardware und Softwareseitig alles abzudichten.
Unbekannter Krieger
Grand Admiral Special
noch eine:
https://borncity.com/blog/2018/07/28/netspectre-zugriff-auf-den-arbeitsspeicher-per-netzwerk/
für sich genommen unbedeutend, doch ein erster verhängnisvoller Schritt in eine katastrophale Richtung
https://borncity.com/blog/2018/07/28/netspectre-zugriff-auf-den-arbeitsspeicher-per-netzwerk/
für sich genommen unbedeutend, doch ein erster verhängnisvoller Schritt in eine katastrophale Richtung
@unbekannter Krieger: Hab NetSpectre mal in die Liste oben reineditiert 
. Das ist schon übel, da man ja eben bei Netzwerkzugang im Prinzip beliebig lange Zeit davor sitzen kann, da ist dann auch die stark reduzierte Geschwindigkeit nicht so tragisch. Sobald man dann die kritischen Infos (z.B. Admin Passwort) nach ein paar Tagen der "Beobachtung" hat, kann man ja den Angriffsvektor wechseln.
. Das ist schon übel, da man ja eben bei Netzwerkzugang im Prinzip beliebig lange Zeit davor sitzen kann, da ist dann auch die stark reduzierte Geschwindigkeit nicht so tragisch. Sobald man dann die kritischen Infos (z.B. Admin Passwort) nach ein paar Tagen der "Beobachtung" hat, kann man ja den Angriffsvektor wechseln.
Complicated
Grand Admiral Special
https://www.heise.de/security/meldung/NetSpectre-liest-RAM-via-Netzwerk-aus-4121831.html
Der Exploit konnte in einem ungenutzten Netzwerk funktionieren, da man anhand der Latenzen mit einer 88% Trefferquote beim auslesen einzelner Bits 0 oder 1 unterscheiden konnte. Sobald es Latenzschwankungen im Netzwerk gibt, wie es in einer produktiven Umgebung unvermeidbar ist, greift der Exploit nicht mehr. Zugriffe die Nachts erfolgen werden durch ein DDOs Protection System noch schneller entlarvt, da ungewöhnliche Aktivitäten stattfinden.
Aus dem Paper:https://misc0110.net/web/files/netspectre.pdf
Also Wenn DDoS Protection und Netzwerkverkehr ausreichen, dann ist das keine wirklich ernst zu nehmende Lücke. Zunächst mal.
Der Exploit konnte in einem ungenutzten Netzwerk funktionieren, da man anhand der Latenzen mit einer 88% Trefferquote beim auslesen einzelner Bits 0 oder 1 unterscheiden konnte. Sobald es Latenzschwankungen im Netzwerk gibt, wie es in einer produktiven Umgebung unvermeidbar ist, greift der Exploit nicht mehr. Zugriffe die Nachts erfolgen werden durch ein DDOs Protection System noch schneller entlarvt, da ungewöhnliche Aktivitäten stattfinden.
Ähnliche Themen
