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

*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 :)
 
*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.
 
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 ;)
 
Ach sorry hast du ein x220 ??? Oder eines mit i5-4xxx ??? Dar Micocodepacket von MS kannst du natürlich in jedem Fall installieren.
 
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.
 
Zuletzt bearbeitet:
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
 
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. :rolleyes:

Stimmt - aber davon gibt es bestimmt leider genug ... Nichts genaues weiß man nicht - Gerade bei Haswell z.B.
 
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:

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.
 
Zuletzt bearbeitet:
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben