Sicherheitslücken in CPUs von Intel/AMD/anderen (Microcode+App+OS fixes notwendig)

[bender79]

Hallo,

da rollt vermutlich schon das nächste Intel Überraschungspaket (nach den ganzen Management Engine vulnerabilities) an:

https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/

Bleibt spannend!
grüße


//edit moronoxyd: Titel noch weiter angepasst. Betrifft nicht nur Intel.

 

[Volvo-Berti]

*hochhol*
nach dem Umstieg auf Windows muss ich dieses Thema mal aufwecken, sorry. Mein X220 hat den i5-4290 drauf, das ist ein Sandy Bridge, so weit ich das gefunden habe. nun gibts ja für diverse CPU auch Updates für den Microcode von MS https://support.microsoft.com/de-de/help/4589212/intel-microcode-updates
alerdings bin ich nicht sicher, ob ich das brauche und ob da irgendwas von in den Updates von Win 10 Version 20H2 drin ist. ich bitte daher um Aufklärung, danke schön

 

[mcb]

*hochhol*
nach dem Umstieg auf Windows muss ich dieses Thema mal aufwecken, sorry. Mein X220 hat den i5-4290 drauf, das ist ein Sandy Bridge, so weit ich das gefunden habe. nun gibts ja für diverse CPU auch Updates für den Microcode von MS https://support.microsoft.com/de-de/help/4589212/intel-microcode-updates
alerdings bin ich nicht sicher, ob ich das brauche und ob da irgendwas von in den Updates von Win 10 Version 20H2 drin ist. ich bitte daher um Aufklärung, danke schön

Ansich brauchst du ein Biosupdate inklusive Microcodeupdates ... alt. Microcodepatches von Microsoft. Ich weiß aber nicht ob es die für so eine alte CPU von Intel gab/gibt.

 

[Volvo-Berti]

hm, in dem Link werden auch Sandys genannt. Mir ist aber nicht klar, ob meine Sandy dabei ist. Bios gibts schon ewig kein neues mehr.

noch ein Grund, mal was neueres auf AMD-basis zu kaufen

 

[mcb]

Ach sorry hast du ein x220 ??? Oder eines mit i5-4xxx ??? Dar Micocodepacket von MS kannst du natürlich in jedem Fall installieren.

 

[Volvo-Berti]

Ach sorry hast du ein x220 ??? Oder eines mit i5-4xxx ??? Dar Micocodepacket von MS kannst du natürlich in jedem Fall installieren.

wieso oder? das Eine schließt das Andere doch nicht aus. ich habe ein X220 mit einem i5 4290-RM8, so wie es in meiner Signatur steht. So stehts auf der Unterseite des X220.

 

[martina]

Die 4290 ist die Modellnummer Deines X220, nicht die CPU-Bezeichnung. Du hast da einen i5-2520M drin
ThinkPad X220 4290-RM8
i5-2520M(2.5GHz) 4GB RAM 320GB 7200rpm HD 12.5in 1366x768 LCD Intel HD Graphics Intel 802.11agn wireless WWAN option Bluetooth 1Gb Ethernet UltraNav Secure Chip X220 UltraBase+CDRW/DVDRW Camera 6c Li-Ion Win7 Pro 32

 

[Volvo-Berti]

was natürlich teilweise unsinnig ist, denn CDRW/DVDRW ist nicht drin

 

[Mornsgrans]

denn CDRW/DVDRW ist nicht drin

In der ab Werk gelieferten Ultrabase schon.

X220 UltraBase+CDRW/DVDRW

 

[mcb]

https://www.heise.de/news/Prozessor...ows-Linux-oeffentlich-verfuegbar-5069159.html

Prozessorlücke Spectre Exploit für Windows & Linux öffentlich verfügbar | heise online

:thumbup:

 

[hikaru]

https://www.heise.de/news/Prozessor...ows-Linux-oeffentlich-verfuegbar-5069159.html

Prozessorlücke Spectre Exploit für Windows & Linux öffentlich verfügbar | heise online

:thumbup:

Du darfst ruhig dazu schreiben, dass der Exploit laut Artikel nur auf ungepatchten Systemen funktioniert. Und die allermeisten Betreiber solcher Systeme hätten es auch nicht besser verdient.

 

[mcb]

Du darfst ruhig dazu schreiben, dass der Exploit laut Artikel nur auf ungepatchten Systemen funktioniert. Und die allermeisten Betreiber solcher Systeme hätten es auch nicht besser verdient.

Stimmt - aber davon gibt es bestimmt leider genug ... Nichts genaues weiß man nicht - Gerade bei Haswell z.B.

 

[mcb]

Oh yeah !

"Lord of the Ring(s): Side Channel Attacks on theCPU On-Chip Ring Interconnect Are Practical"

https://arxiv.org/pdf/2103.03443.pdf

 

[Megalodon]

Risiken wie Spectre sind nun auch bei AMD angekommen

Man könnte jetzt sagen, dass es ja nur eine Frage der zeit war....

Auf der andere Seite, ist der Leistungsverlust durch Deaktivierung von PSF mit etwa 0,5% zu vernachlässigen...

Dennoch bin ich gespannt, wie es weiter geht und was sonst noch so kommt

 

[mcb]

Oh no :

Intel Releases New CPU Microcode Due To New Security Vulnerabilities (June 2021) - Phoronix
https://www.phoronix.com/scan.php?page=news_item&px=Intel-June-2021-Security

:facepalm:

 

[Schwartz]

Eine Sicherheitslücke a la Spectre gibt's nun auch im Apple M1 bzw. ARM, genannt PACMAN. "Speculative Execution" ist mal wieder derjenige welcher. Geschwindigkeit um jeden Preis?

MIT Finds Apple M1 Vulnerability, Demos PACMAN Attack (Update)

Chomping away at Arm chip security

www.tomshardware.com

 

[xxxx]

Sicherheitslücken …
… dass es diese gibt, ist nicht das Problem. Sicherheitslücken sind so unvermeidbar wie der zweite Hauptsatz der Thermodynamik (Entropie) unausweichlich ist. Sehr umgangssprachlich: "Shit happens."

Die zentrale Frage ist hingegen, wie mit Sicherheitslücken umgegangen wird, im allerweitesten Sinn:
1.) Ob das Design der (Soft- oder Hardware-)Architektur so angelegt ist, dass Sicherheitslücken leicht begegnet werden kann, also einerseits, ob die Architektur
- eine möglichst geringe Angriffsoberfläche ("attack surface") aufweist
- vermeidbare Komplexität auch wirklich vermeidet ("KISS"-Prinzip)
2.) Ob der Code gut zugänglich ist und eine entsprechende Infrastuktur existiert, über die eine Sicherheitslücke zeitnah adressiert werden kann:
- ob genügend helle Köpfe schnell genug draufschauen können, und
- ob es möglich (und, bei proprietärer Software, erwünscht) ist, einen Patch schnell und effizient auf den entsprechenden Architekturen zu integrieren (IoT-Anwendungen sind in dieser Hinsicht ein absoluter Alptraum)

In all diesen Punkten hat sich Intel in der Vergangenheit nicht mit Ruhm bekleckert, teilweise sogar aktiv bereits verfügbare Lösungen hinausgezögert oder behindert.

Ein anderes Feld, in dem sich diese Problematik seit Jahren zeigt, sind z.B. die überkomplexen UEFI-Implementierungen. Viele Nutzer wissen gar nicht, dass UEFI gewartet werden kann (und muss). Die UEFI-Hersteller ihrerseits lassen mitunter jahrelang Lücken im Code einfach offenstehen, ohne dafür Patches bereitzustellen.

Dem gegenüber steht z.B. der Umgang mit Sicherheitslücken in der coreboot-Community, wo eine gut überschaubare, sauber strukturierte Codebasis von vielen Entwicklern aktiv gepflegt wird.
Natürlich schützt auch hier die überschaubare Komplexität nicht vor (sehr seltenen) Sicherheitslücken.
Aber: die überschaubare Komplexität der Codebasis erleichtert es nicht nur, Sicherheitslücken zu stopfen, sondern auch, sie überhaupt zu finden.
Arthur Heymans, der z.B. eine Sicherheitslücke am 7. April gefunden hat, liefert auch gleich einen Lösungsvorschlag, wie sie gestopft werden kann. Die Community diskutiert deren Implikationen, es wird eine verwandte Schwachstelle gefunden und Patches in die Distributionen eingepflegt. Hier ist die ursprüngliche Nachricht (und Reaktionen darauf) in der coreboot mailinglist:

[coreboot] Security notice: SMM can be hijacked by the OS on APs

www.mail-archive.com

Ich finde das vorbildlich, und würde mir wünschen, dass ein solcher Umgang mit Sicherheitslücken auch in anderen Bereichen zum Standard wird.

EDIT: Ich habe in einem anderen Thread (Was hat es mit UEFI/Secure Boot auf sich? (allgemeine Frage)) das Thema UEFI nochmals aufgegriffen und etwas vertieft. Als kleine Ergänzung zum hier Gesagten.