News Meltdown & Spectre: Details und Bench­marks zu den Sicherheits­lücken in CPUs

The_Void schrieb:
gratuliere, das ist ja super. für mein 970er kommt wohl nix mehr. habe ein ticket bei MSI eröffnet, mal sehen, ob wer antwortet.
der microcode wird zu spät geladen, was die vmware lösung unfunktional macht.
BmwM3Michi schrieb:
mal sehen ob ich fürs MSI Z87-G45-Gaming noch was bekomme! Ist ja jetzt 4 Jahre alt.
http://www.pcgameshardware.de/Mainboard-Hardware-154107/News/Spectre-BIOS-Updates-1247555/

Moin :)

Leute, jetzt bleibt doch mal ruhig und brecht nicht in diese hektische Panik aus!
Ich hab die Threads und Links hier nur quergelesen und bin nach nicht mal fünf Minuten zu dem Ergebnis gekommen, daß die Gefahr für einen vernünftig mit seinem PC agierenden Otto-Normalverbraucher gegen Null geht.

Ich zitiere hier u.a. mal Iscaran:
Spectre zu nutzen als Exploit trotz ungepatchter Hardware ist also alles andere als Trivial und erfordert Soft- UND Hardware-maßgeschneiderte Exploits.
oder hier:
Das ist eine sehr schöne Aufschlüsselung der Problematik inklusive der existierenden und denkbaren Mitigations.
https://github.com/marcan/speculatio...ster/README.md

Spectre v1: [MISPREDICT] Branch mis-prediction leaks subsequent data

•JITs/interpreters: Easy. Sandbox escape (same-context leak). Shared memory/threads make it easier.
•Same-CPU cross-process: Medium. Attacker needs to trigger the vulnerable code in the vulnerable process, then get a signal from the cache directly (e.g. by timing accesses to memory which has colliding cache tags on the same CPU core or sharing a level of cache). This includes attacks on the kernel and on hypervisors.
•Remote/service: Hard. Attacker needs some way of triggering the vulnerable code, then getting a timing signal back from the relevant cache lines. Probably not practical in most circumstances.

Spectre v2: [BTI] Branch Target Injection
•JIT: Tricky, but probably possible with careful instruction massaging?
•Same-cpu cross-process: Possible. Includes attacks on the kernel/hypervisor.
•Remote/server: Not possible.

Meltdown v1: [PRIV-LOAD] Privileged data reads from unprivileged code
•JIT: Possible. Combined with [MISPREDICT], can read arbitrary kernel memory.
•Same-cpu cross-privilege: Easy. Combine with [MISPREDICT] to avoid actual page faults (not required).
•Remote/service: Same as [MISPREDICT] on affected systems. Probably not practical.

Meltdown v2: [PRIV-REG] Privileged register reads from unprivileged code

•JIT: Not possible.
•Same-cpu cross-privilege: Easy, but limited impact.
•Remote/service: Not possible.


M-V2 ist exploit technisch eher irrelevant.

Jetzt laßt doch bitte alle mal die Kirche im Dorf und wartet, bis M$, Intel, AMD und die Board-Hersteller vernünftig und in Ruhe Patches bereitgestellt haben.
Denen mit Anfragen die Bude einzurennen, wird es auch nicht beschleunigen, und ich bin mir annähernd zu 100% sicher, daß 99,99999% der Privatnutzer-PC's auch in den nächsten 20 Jahren nicht Opfer einer Meltdown- oder Spectre-Attacke würden, wie schon auch nicht den 20 Jahren zuvor nicht.


Ich finde es nur echt schade, daß von keiner "offiziellen" Stelle - computerbase, heise, etc. - mal ne kleine, rationale Entwarnung auf "Seite 1" kommt.
Ja, für Dauer-Online-User und -Server mag das Risiko größer sein. Und hätte ich ne Firma mit hochsensiblen Daten oder beispielsweise behördliche Rechenzentren, Energiewerke und dergleichen, würde ich die Lücken lieber heute als morgen geschlossen sehen. Klar.

Aber für den normalen 08/15-User, der seine Vernunft mit einschaltet, reicht es, den Browser zu aktualisieren, sich von dubiosen Drittseiten fernzuhalten (sollte man eigentlich eh immer) und ansonsten geduldig die nächsten Tage und Wochen abzuwarten.

DFFVB Beitrag anzeigen
Danke @xexes/iscarian, dass ihr mit der Diskussion das Niveau hier angehoben habt! GErade die Zusammenfassung der Exploits under Wahrscheinlichkeit sollte Beruhigung genug für die meisten sein, durchzuatmen und nicht verrückt machen zu lassen.
Ich schließe mich dem Dank an euch zwei an :cheerlead:


Echt Wahnsinn... Über 3200 comments allein hier auf cb zu nem Thema, dessen Eintrittswahrscheinlichkeit um Längen geringer ist als ein Sechser im Lotto... :rolleyes: (ich weiß: Bin hiermit comment 3201 ;))
 
Zuletzt bearbeitet:
Hi,

seit gestern gibt es für meinen i7 7700HQ ein CPU Microcode Update als Bios-Update. Bin beim überlegen ob ich es machen soll - wegen Performance Einbrüchen. Gibt es schon welche Infos wie die CPU "laufen" nach den Microcode Updates?

Danke
 
@branhalor:

Hier ist eine Super-minimalisierte aber sehr korrekte Übersicht INKLUSIVE Gefährdungseinschätzung und einer Kurzübersicht wie die Patches aussehen und für welche Variante man was braucht:
https://www.kb.cert.org/vuls/id/584653

Spectre_vs_Meltdown.png

EDIT:@xexex:

Difficulty of successful attackSpectre:
High - Requires tailoring to the software environment of the victim process
Meltdown:
Low - Kernel memory access exploit code is mostly universal


Aber man sieht auch das gegen Meltdown der Patch relativ leicht zu applizieren ist bzw. schon ausgerollt ist (siehe Link oben).

Spectre ist hier trickier da man je nach Variante eben verschiedene Mitigation Level braucht.
 
Zuletzt bearbeitet:
Peaky schrieb:
Es werden im Geräte-Manager unter den ausgeblendeten Geräten keine Nicht-PnP-Treiber aufgelistet. Wie lässt sich das bewerkstelligen?

Das muss man erst "freischalten".
Du musst auf einer Konsole zunächst

"set devmgr_show_nonpresent_devices=1" eingeben (ohne Anführungszeichen, dann mit Enter bestätigen)

und danach von dieser Konsole den Gerätemenager aufrufen

"devmgmt.msc" (ohne Anführungszeichen, dann mit Enter bestätigen)

Dann wie gewohnt die ausgeblendeten Geräte anzeigen lassen.
 
Iscaran schrieb:
@branhalor:

Hier ist eine Super-minimalisierte aber sehr korrekte Übersicht INKLUSIVE Gefährdungseinschätzung und einer Kurzübersicht wie die Patches aussehen und für welche Variante man was braucht:
https://www.kb.cert.org/vuls/id/584653
Danke Dir :)

Wichtig erscheint mir vor allem folgender Absatz von der verlinkten Seite:
Multi-user and multi-tenant systems (including virtualized and cloud environments) likely face the greatest risk. Systems used to browse arbitrary web sites are also at risk. Single-user systems that do not readily provide a way for attackers to execute code locally face significantly lower risk.

=> Amazon, ebay, Google & Co haben damit verständlicherweise ein großes Interesse daran, daß die Lücke geschlossen wird, vor allem, nachdem sie jetzt so öffentlich breit getreten wurde.
Jeder Home-PC-Nutzer kann sich eigentlich erstmal zurücklehnen und abwarten, bis stabilere, sicherere und performantere Patches bereitsgestellt sind. Und als Zocker freut man sich, wenn die CPU bis dahin die gewohnte Leistung bringt.

Also, wie immer im Leben: Die Gefahr richtig einschätzen und dann Ruhe bewahren. Alles andere ist blinder Aktionismus und führt schlimmstenfalls nur zu noch mehr Problemen, Bugs, Abstürzen etc., weil die bisherigen Schnellschuß-Lösungen nicht für jede Plattform und jeden Anwendungsfall 100% ausgereift sind.
 
Sofern die Updates in Windows gemacht werden, kann ich mich da eh nicht wehren. Von daher, es kommt sowieso...
 
Ich bin am Überlegen, was ich jetzt mache. Meine Hardware wollte ich in diesem Jahr ablösen, da mir mein alter i5-2380P nicht mehr reicht.

Aber jetzt mehrere hundert Euro für eine CPU mit bestätigten Sicherheitslücken und notwendigen Fixes mit nicht genau kalkulierbaren Auswirkungen ausgeben?
 
Capet schrieb:
Aber jetzt mehrere hundert Euro für eine CPU mit bestätigten Sicherheitslücken und notwendigen Fixes mit nicht genau kalkulierbaren Auswirkungen ausgeben?

Nimm halt eine AMD, da sparst du gleich doppelt ;-)
 
@umax1980:
Jein, Automatische Updates kann man deaktivieren und manuell nachholen, sobald die Kinderkrankheiten beseitigt sind. Meine Strategie jedenfalls...

@Capet:
Das Risiko für Dich als Home-PC-Nutzer geht gegen Null. Ich will im Herbst wahrscheinlich selbst auch endlich mal aufrüsten, und ob die CPU jetzt gegen Spectre und Meltdown geschützt ist oder nicht, ist mir echt wurscht - ich stelle meinen PC ja nicht als 24/7-Online-Daten- und Rechenzentrum für Amazon, Google und Facebook zur Verfügung ;)

Dazumal die ganzen Software-Patches in den nächsten Wochen zunehmend ausgereift und optimiert sein werden.

Also: Mach Deine Planung davon unabhängig. Dein PC ist als Angriffsziel so uninteressant wie meiner und die von nahezu allen anderen hier, solange der Browser gepatcht ist und sie wie gesagt nicht 24/7 online sind und mit irgendwelchen sensiblen Daten auf dubiosen Drittseiten agieren.

:)


EDIT:
Außerdem, überlegt euch doch mal, wer was von diesem ganzen Panik-Hype hier hat...
Auf Heise gibt's fast kein anderes Thema mehr, auch die comments hier auf cb gehen in die Tausende. Aufrufe und Klicks ohne Ende, hintendran u.a. maßgeschneidert die Werbung für Schutz- und Sicherheitssoftware...
Möchte nicht wissen, wieviel Umsatz das Bekanntwerden der Lücken den großen Antiviren-, Pishing-Abwehr-, Backdoor-Blockier- & Co.-Programmen in den letzten Tagen beschert hat... Daß die nicht gegen die Hardware-Lücke schützen, wissen die wenigsten, daher wird erstmal alles gekauft und getan und gemacht, was nur annähernd danach aussieht, als würde es einen davor schützen können.

Mit den nächsten Generationen haben Intel und AMD die Lücken dann auch hardwareseitig geschlossen - und prompt rennen alle zum nächsten PC-Händler ihres Vertrauens, um sich nen neuen PC mit "sicherer" CPU zu kaufen oder um die alte wenigstens aufzurüsten...
Wenn's ganz blöd kommt und sich nicht genug Leute ne neue CPU gekauft haben, unterstützt dann das große Frühjahrs- oder Herbst-Update von Win10 ab 2019 nur noch Prozessoren ab der aktuellen Generation... und siehe da: Schon stimmt auch der Absatz bei den CPU's wieder... :rolleyes:

Ich will hier keine Verschwörungstheorien malen.
Aber heutzutage geschieht gerade in der medialen Nachrichtenwelt nichts mehr ohne Grund... Neutrale und wertfreie Berichterstattung gibt's nicht - irgendwer hat immer etwas davon, die Nachrichten so zu formulieren, wie er es tut.

Und wer's nicht glaubt, erinnert sich mal an den Abgasskandal und die Software-Manipulationen der einstmals so hochgelobten, renommierten, innovativen und "öko-fortschrittlichen" deutschen Automobilisten ;)

Es gibt keine Zufälle.
 
Zuletzt bearbeitet:
kisser schrieb:
Das muss man erst "freischalten".
Du musst auf einer Konsole zunächst
Der Geräte-Manager erscheint, aber auch nach dem Einblenden der Geräte leider immer noch ohne Anzeige derselben.
Vielleicht liegt es an meiner Windows-Edition (Home)? Gibt es vielleicht eine andere Methode?
 
Peaky schrieb:
Vielleicht liegt es an meiner Windows-Edition (Home)? Gibt es vielleicht eine andere Methode?

Das sollte auf allen Versionen funktionieren. Vielleicht vertippt beim setzen der Variable?

set_devmgr_show_nonpresent_devices=1

Achso, da fällt mir ein, dass die Konsole evtl. mit Administratorrechten laufen muss.

Also cmd.exe suchen, rechtsklick -> "als administrator ausführen"
 
kisser schrieb:

Richtig, lesen bildet. Vielleicht fängst Du damit an, deine eigenen Links vor dem Posten zu lesen? :)

Control Sets
http://sourcedaddy.com/windows-7/control-sets.html

The Windows Boot Loader reads control set information from the registry key HKEY_LOCAL_MACHINE\SYSTEM, which is stored in the file %SystemRoot%\System32 \Config\System, so that the kernel can determine which device drivers need to be loaded during startup. Typically, several control sets exist, with the actual number depending on how often system configuration settings change.

Die MS Seite sagt "before it transfers control to the Kernel" heißt auf Deutsch bevor es die Kontrolle an den Kernel übergibt.
Wo soll der Kernel herkommen? War auf einmal da? It's magic? Ne, der wird parallel geladen. (ntoskernel / ntldr)
Dann sagt es , die Treiber liegen im Memory und werden dann vom Kernel geladen (These drivers are in memory when the kernel gets control)
Der Kernel ist zu diesem Zeitpunkt aber logischer Weise bereits da, wie sollte er sich die Treiber sonst aus dem Speicher laden..
Damit ein Microcode Update funktioniert, muss der Kernel aber schon mit dem neuen Ucode geladen/gebootet werden, das heißt er muss den Treiber bei Initialisierung in den Kernel laden und nicht parallel. Das ist ein großer Unterschied.

Das macht Linux so, aber nicht Windows!
Technisch geht das was ihr meint natürlich. Ja es kann ein Treiber über den OS Load mit Microcode gebootet werden.
Nur MS sieht das für Windows nicht vor. Hier wird der OSLoader zum intialisieren (0x0) von Disk-Treibern genutzt.

https://social.technet.microsoft.co...he-windows-7-boot-process-sbsl.aspx#OS_Loader

Sub phase 1 - PreSMSS: Kernel Initialization
The PreSMSS subphase begins when the kernel is invoked. During this subphase, the kernel initializes data structures and components. It also starts the PnP manager, which initializes the BOOT_START drivers that were loaded during the OSLoader phase. [1]

Der Kernel intialisiert boot_start, er ist also bereits da!

Weiterführend von MS

Boot Transition: The OSLoader Phase
What Happens in This Phase
During the OSLoader phase, the Windows loader binary (Winload.exe) loads essential system drivers that are required to read minimal data from the disk and initializes the system to the point where the Windows kernel can begin execution. When the kernel starts to run, the loader loads into memory the system registry hive and additional drivers that are marked as BOOT_START.

Dein Link:
Drivers are also services. Therefore, during kernel initialization, the Windows Boot Loader and Ntoskrnl use the information stored in the HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\Servicename registry subkeys to determine both the drivers and services to load. In the Servicename subkeys, the Start entry specifies when to start the service. For example, the Windows Boot Loader loads all drivers for which Start is 0, such as device drivers for hard disk controllers. After execution is transferred to the kernel, the kernel loads drivers and services for which Start is 1.

Auch hier wieder, der Kernel holt sich die Treiber erst ab, nachdem er geladen wurde. Für ein ucode Update müsste dies aber vorher gesehen.

Und deswegen wird der Patch immer sagen ich bin nicht aktiviert. Da zum Zeitpunkt der Kernel-Initialisierung eben noch kein neuer ucode geladen wurde. Das macht Windows einfach zu spät. Man selbst könnte Treiber in boot_start einpflegen, bringt aber nichts, da der Kernel beim laden von boot_start bereits initialisiert wurde bzw der Kernel boot_start initalisiert (It (the kernel) also starts the PnP manager, which initializes the BOOT_START drivers. Auf deutsch: Boot_Start drivers liegen im Memory, werden vom Kernel aber erst nach seinem eigenen Start geladen, nicht davor) . Huhn und Ei.
 
Zuletzt bearbeitet:
@xexex

Wenn ihr es hinbekommt den neuen Ucode per Usereingriff bei Start in den NT Kernel zu laden, schickt mir Eure Adresse und Bier-Sorte per PN, bekommt jeder ne Kiste.

Ich gehe die Wette mit!

SERVICE_BOOT_START
0x00000000
A device driver started by the system loader. This value is valid only for driver services.

Aber wie gesagt, selbst wenn er das akzeptiert. Der Kernel müsste sich den Treiber bei seiner eigenen Intalisierung unloaden und nicht erst danach. Und das sieht die MS Routine für den NT Kernel nicht vor. Die lädt die Treiber in den Speicher und lässt sich den Kernel diese dort abholen.
 
Zuletzt bearbeitet:
ich lade mir auch keine halbgaren patches auf die Rechner. Erst mal abwarten. Ich wette die performanceeinbuße bei älteren CPUs + ssds ist noch viel höher. Warum soll ich mir die Rechner um 30 % oder mehr verkrüppeln, wenn es unwahrscheinlich ist je von diesem Angriff betroffen zu sein. Abwarten und Tee trinken. Bin das erste mal richtig froh kein win10 zu haben, wo mir das update dann automatisch aufgedrückt wird.
 
Die Frage, die ich mir stelle, ist, ob es überhaupt so dringend notwendig ist, sich das neue BIOS gegen Spectre zu laden, wenn das Risiko einer Attacke als so gering eingeschätzt wird bzw. es sehr aufwendig ist.

Denn wer würde sich bei mir als Privatperson die Arbeit machen. Ich verfüge weder über viel Geld, noch bin ich prominent oder so.

Muss ich in ein paar Wochen noch mal abwägen, wenn es mehr Tests gibt und vor allem die BIOS-Updates überhaupt mal verfügbar sind. :p
 
Zuletzt bearbeitet:
ich lade mir auch keine halbgaren patches auf die Rechner. Erst mal abwarten.

Genau so werde ich auch verfahren. Warum diese panik aktuell? Wie hier oft erwähnt dürfte die Lücke den meisten 0815 Nutzern egal sein. Vor allen wenn man sein OS/Browser ect immer aktuell hält.

Sicherlich sollte die Lücke auch bei 0815 Usern geschlossen werden. Aber lieber paar Wochen/Monate warten bis die Upates wirklich Reif sind bzw besser getestet sind als wenn man jetzt irgendwelche Updates installiert die nur so halb gestet wurden. Es häufen sich ja schon die ersten user Meldungen das welche nach ein Bios Update auf einmal Probleme mit ihren PC haben oder die Perfomance absackung durchaus spürbar ist auch unter Windows selber.

Daher:
Ich werde so weiter fahren wie vorher erst mal und lasse mich wegen eines 20? jahren alten sicherheitsfehler nicht verrückt machen^^
 
Zurück
Oben