News Intel/ARM/AMD: Sicherheitslücken Meltdown & Spectre V1, V2 etc. (Links in Post 1)

Wenn man nix zu tun hat dann hilft MS einem das es sich ändert ;) Danke
 
Lol..klar. Das Snappin war nicht aufrufbar.
 
Das schaut eher nach UBuntu 14.04 hat Probleme mit AMDs Microcode Update aus als umgekehrt...
Das sollte man schon präzisieren...
 
Zuletzt bearbeitet:
@eratte:

Vielleicht sollte man die Linkliste auf Seite 1 mal ein wenig besser sortieren um die Übersichtlichkeit und Zuordnung zu den jeweiligen Lücken klarer herauszuarbeiten...
ich hab hier mal eine ultra-kurz Übersicht nur zu den Benennungen und Varianten erstellt. Eigentlich müsste man jetzt nur noch die Linkliste durchgehen und jeweils zuordnen zu welcher Kategorie sie zählt:
http://www.planet3dnow.de/vbulletin...RSB-entdeckt?p=5208618&viewfull=1#post5208618

Ich finde sonst verliert sich auf S1 zuviel info in einer stark durcheinandergewürfelten Linkliste.
 
Ein Kleines Update meiner privaten Namensgebungs-Wirrwarr-Übersichtsliste

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, IBM, 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

Foreshadow V1 = L1TF-SGX = CVE-2018-3615
Intel
Meltdown verwandte Lücke, scheint nur Intel zu betreffen siehe:
https://www.redhat.com/en/blog/deeper-look-l1-terminal-fault-aka-foreshadow
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3615
https://software.intel.com/security-software-guidance/software-guidance/l1-terminal-fault
Mitigation durch kleine Softwareanpassung auf OS Ebene (deaktivieren der EPT), kostet keine Performance

Foreshadow V2 = L1TF-OS/SMM = CVE-2018-3620
Intel
Meltdown verwandte Lücke, scheint nur Intel zu betreffen siehe:
https://www.redhat.com/en/blog/deeper-look-l1-terminal-fault-aka-foreshadow
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3620
https://software.intel.com/security-software-guidance/software-guidance/l1-terminal-fault
Mitigation durch KPTI für Meltdown

Foreshadow V3 = L1TF-VMM = CVE-2018-3646
Intel
Meltdown verwandte Lücke, scheint nur Intel zu betreffen siehe:
https://www.redhat.com/en/blog/deeper-look-l1-terminal-fault-aka-foreshadow
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3646
https://software.intel.com/security-software-guidance/software-guidance/l1-terminal-fault
Mitigation durch Flushen des L1 Caches bei jedem VM-Zugriff ABER NUR wenn KEIN Hyperthreading aktiv ist ! (nur flushen kostet ca 5-15% Performance, deaktivieren von HT z.T. noch mehr)
https://access.redhat.com/security/vulnerabilities/L1TF

------------------------------------
Spectre-NG-Varianten via Return Stack Buffer (RSB)
------------------------------------

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 zu Spectre-NG 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 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
DDoS-Detection reduziert mögliche Übertragungsrate zusätzlich ggf. bis zur Unmöglichkeit des Angriffs
------------------------------------------------------------------------
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:
Theoretisch oder nicht. Betroffen sind sie. Sonst würde AMD auch nicht soviel Mitigations für Spectre V2 mit-Auflegen.

Aber ja ich denke auch dass Spectre V2 in der Art wie er bislang benutzt wird nicht wirklich funzt. Ich denke aber dass AMD selbst wohl schon einige Szenarien durchdacht hat die eventuell hier zu Wegen führen könnten. Deswegen auch die Mitigations von AMD vs V2
 
Theoretisch oder nicht. Betroffen sind sie ...
... nicht.

Sonst würde AMD auch nicht soviel Mitigations für Spectre V2 mit-Auflegen.
Das macht AMD nur, weil die Unwissenden danach schreien: "Intel hat sowas, das wollen wir auch von AMD haben."

... Ich denke aber dass AMD selbst wohl schon einige Szenarien durchdacht hat die eventuell hier zu Wegen führen könnten.
Ah ja? Wie soll Spectre V2 denn auf AMD-Prozessoren gehen?
Quelle bitte.

Deswegen auch die Mitigations von AMD vs V2
Nein. S. o.
 
Theoretisch oder nicht. Betroffen sind sie.
Betroffen wovon? Von vorsorglichen Patches? Wenn nach wie vor kein PoC da ist werden sie dafür auch zukünftig nicht verwundbar sein.
 
Leute, ich verweise hier schlicht auf AMD selbst:
https://www.amd.com/en/corporate/security-updates

Man hat nicht ohne Grund "irgendwas" gepatched bzw. unterstützt den Retpoline ansatz. Auch wenn dazu bislang nichts bekannt ist, werden einige schlaue Leute, vor allem solche die die AMD Arch kennen evtl. durchaus wissen warum man bestimmte Features nachrüstet etc.

Und ja bislang gibt es meines Wissens nach keinen PoC für V2 der auf AMD funzt bis auf Spectre v1, das geht meines Wissens. (EDIT: Und auch der speculative store bypass geht AFAIK @AMD wenn auch mit einer niedrigeren Hitrate (sprich Geschwindigkeit))

Was ich meine ist dass AMD hier wohl eher auf ein noch "unbekannten" Spectre-Subtyp hin ihre Architekturen "hardened". Auch das wird man nicht ohne Grund machen.

Denkt doch mal nach ! Sonst hätten sie rein-Marketing technisch auf JEDEN Fall mit dem Slogan geworben "AMD CPUs waren, sind und werden immer safe sein" !

Spätestens nachdem sie monatelang die Lücken analysiert haben und festgestellt haben dass es nicht geht, hätte man das gemacht. Hat man aber nicht ! Allein das zeigt mir dass bestimmte Varianten der Exploits eben die Jungs von AMD durchaus auf ihre Arch als Anwendbar betrachten.
 
Zuletzt bearbeitet:
Theoretisch oder nicht. Betroffen sind sie
Diesen Blödsinn höre ich immer und immer wieder aus der Intel Ecke, die den Müll von Intel relativieren müssen.
Aber belegen konnte diese Behauptungen noch niemand.
Also, Zeig mir die Proof of Concept, dass das auch auf AMD genauso wie auf Intel funktioniert!

Ohne dem ist das einfach nur im dunkeln stockern und einfach nur Nebelkerzen, weil Intel gerade total im Klo ist, kann/darf AMD nicht besser sein...

Man hat nicht ohne Grund "irgendwas" gepatched bzw. unterstützt den Retpoline ansatz.
Weil:
a) das von den ganzen DAU Admins gefordert wurde
b) Vorsicht besser ist als Nachsicht?

Fakt ist, dass bisher niemand belegen konnte, dass es auch bei AMD der Fall ist.

Ich hab bisher nur Behauptungen gesehen, die Unterstellen, dass AMD genauso schlimm sein MUSS und es keine Möglichkeit gibt, dass sie sicherer sein konnten...
 
Zuletzt bearbeitet:
Leute, ich verweise hier schlicht auf AMD selbst:
https://www.amd.com/en/corporate/security-updates
https://www.amd.com/en/corporate/speculative-execution-previous-updates#paragraph-313481
Variant Two Branch Target Injection Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.
https://www.amd.com/en/corporate/speculative-execution-previous-updates#paragraph-337801
GPZ Variant 2 (Branch Target Injection or Spectre) is applicable to AMD processors.
While we believe that AMD’s processor architectures make it difficult to exploit Variant 2, we continue to work closely with the industry on this threat. We have defined additional steps through a combination of processor microcode updates and OS patches that we will make available to AMD customers and partners to further mitigate the threat.
AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week. We expect to make updates available for our previous generation products over the coming weeks. These software updates will be provided by system providers and OS vendors; please check with your supplier for the latest information on the available option for your configuration and requirements.
Linux vendors have begun to roll out OS patches for AMD systems, and we are working closely with Microsoft on the timing for distributing their patches. We are also engaging closely with the Linux community on development of “return trampoline” (Retpoline) software mitigations.
Man hat nicht ohne Grund "irgendwas" gepatched bzw. unterstützt den Retpoline ansatz.
Den Grund habe ich in meinem letzten Beitrag genannt.

... bislang gibt es meines Wissens nach keinen PoC für V2 der auf AMD funzt ...
Na also. Warum dann das ganze Theater hier?

bis auf Spectre v1, ...
Warum lenkst du ab? Mein Einwand bezieht sich ausschließlich auf Spectre v2.

... AMD hier wohl eher auf ein noch "unbekannten" Spectre-Subtyp hin ihre Architekturen "hardened". ...
Quelle?
Oder wieder nur reine Spekulation von dir?

... Sonst hätten sie rein-Marketing technisch auf JEDEN Fall mit dem Slogan geworben "AMD CPUs waren, sind und werden immer safe sein" ! ...
Das kann AMD nicht, da sie ja z. B. von Variante 1 betroffen sind.
 
Zurück
Oben Unten