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

Grazer Forscher: Alte PCs bei Prozessorlücken ein massives Problem!
Der Forscher geht davon aus, dass all die aktuellen Entdeckungen nur die Spitze des Eisbergs darstellen,
hier werden noch viele folgen.
In Hinblick auf Side-Channel-Attacken, wie sie Meltdown und Spectre darstellen,
habe man bisher gerade mal an der Oberfläche gekratzt.

https://www.derstandard.de/story/20...pcs-bei-prozessorluecken-ein-massives-problem
 
Ist ja schön für alle Besitzer eines x79 Mainboards, aber was ist mit denen davor?
 
Die werden wahrscheinlich außen vor bleiben. Ich betreibe auch noch ein i5-750 mit einem P55-Board von Asus.
 
Oha...nun schafft man es also schon in nur 2h 8GB durchzurastern:
https://www.derstandard.de/story/20...pcs-bei-prozessorluecken-ein-massives-problem
In internen Tests schaffe man es in zwei Stunden, 8 GB RAM komplett zu erfassen, dabei laufe ein Core auf Volllast. Dieses Verhalten sei übrigens auch der einzige Weg, um eine Attacke zu bemerken. Da es sich bei Meltdown und Spectre um Angriffe auf Hardwareebene handelt, hinterlassen diese auch keinerlei Spuren in den Logs eines Betriebssystems.
2h für 8GB das sind dann schon ~1200KB/s statt der 500 aus dem Artikel...
Sagte ich doch mit ein "bisschen" Optimierung stellen die 500KB/s bald keine Hürde dar...man könnte doch evtl. auch mit 2 Cores "scannen" oder mit 4 ?....

Naja - so oder so egal. Ich will eigentlich nicht mehr weiterdiskutieren ob man nun Kee Pass damit knacken kann oder nicht...
Glaubt was ihr wollt. Das Video und die infoseite der Entdecker von Meltdown/Spectre sind aufschlussreich genug. Mit allen anderen Security Advisory boards zusammen ist klar was nun weiter kommt.

Bin mal gespannt auf die Performance Tests NACHDEM mal alle Patches eingespielt sind. Insbesondere interessiert dann doch auch wieder der Quervergleich Ryzen vs CoffeeLake.

Ebenfalls interessant könnte es noch werden wenn man mal genauer rausbekommt ob und wieso AMD CPUs wirklich Meltdown safe sind....ich KÖNNTE mir vorstellen dass AMD CPUs (zumindest seit Ryzen) evtl. einen Privilege-Check machen bevor sie OoOEx oder SpecEx anwenden. EDIT: Das könnte erklären warum die OoOEx und SpecEX bei AMD "schlechter/langsamer" sind als bei Intel. EDITENDE.
Das wäre sozusagen der native Schutz gegen Meltdown wenn ich das richtig verstanden habe also zumindest gegen die Privilege Escalation von Userspace in den Kernelspace.
 
@Computerbase:

Bitte ein Spiele Test nach den Patches von Intel und AMD Prozessoren!
 
Iscaran schrieb:
Oha...nun schafft man es also schon in nur 2h 8GB durchzurastern:​
Sprich innerhalb von 2 Stunden immer prüfen ob die CPU voll ausgelastet ist, wenn nicht, findet es nicht statt?

Iscaran schrieb:
Glaubt was ihr wollt.
Ich weiß nicht wie das bei den anderen ist, aber ich für mich Teil würde es schon interessieren wie das genau ist, also z.B wie du das siehst. Ich persönlich habe da keine Ahnung nur Annahmen.

Was AMD betrifft, kann mir gut vorstellen das dort einiges betroffen ist. Natürlich wird extrem runter gespielt, noch mehr als bei Intel, weil eben AMD im Moment derbe von der Sache profitiert. Wird wohl einiges an Zeit dauern bis dort was aufgedeckt wird.
 
@Computerbase

Bitte einen "Spezial-Workload" Test. Virtualisierung mit vielen VMs und nen Kompiler-Test vielleicht (wenn ihr das irgendwie sinvoll hinbekommt).

Wäre sehr interessant. Für "0815" Anwendungen macht es ja offenbar nicht allzuviel aus. Auch nen Test mit alten CPU Generationen wäre nicht schlecht.
 
Meine Annahme ist dass Passwort-Manager bei Meltdown nichts bringen. Klar...nicht JEDE Passworteingabe wird sofort entdeckt und so...aber ich mein Hacker sind es z.T. gewohnt dass sie einige Zeit arbeit investieren müssen um an etwas ranzukommen.

Das lese ich zumindest aus dem was z.b. auf www.meltdownattack.com steht. Und aus dem PDF-Artikel über den "Bug".
 
Bleibt dann die Frage in wie fern man sich ansonsten schützen kann.
Bin z.B immer über einem VPN + Proxy unterwegs, in wie fern das vor Hackern schützt?

Hab nen uraltes Board, das wird kein Update mehr bekommen...
 
Zuletzt bearbeitet von einem Moderator: (Beitrag wiederhergestellt)
Natürlich wird extrem runter gespielt, noch mehr als bei Intel, weil eben AMD im Moment derbe von der Sache profitiert.

Glaube ich nicht....AMD CPUs wurden ja ebenfalls gegen Meltdown getestet...bislang aber negativ. Es wird also womöglich doch eine Design-Differenz sein. Insofern ist es in meinen Augen durchaus glaubhaft was AMDs statement betrifft. Die Lösung wäre ja relativ simpel und kostet nur ein wenig cache-latenz wenn man einen Privilege-Check vor das OoOEx bzw das SpecEx setzen würde...damit ist schon viel geholfen.
An die Geschichte das AMD CPUs bislang nur deswegen "safe" seien weil deren OoO-Ex und SpecEx so "schlecht" sind kann ich nicht recht glauben.

Bei Bulldozer vielleicht mit seinen 50% weniger IPC - aber nicht bei Ryzen.
 
Iscaran schrieb:
Oha...nun schafft man es also schon in nur 2h 8GB durchzurastern:

In internen Tests schaffe man es in zwei Stunden, 8 GB RAM komplett zu erfassen, dabei laufe ein Core auf Volllast.

Ich lasse mir mit AIDA64 auf dem Desktop, per OSD, unter anderem dauerhaft die CPU-Auslastung von jedem Kern anzeigen. Mir würde somit sofort auffallen wenn die CPU-Last, oder einzelne Kerne, plötzlich eine hohe Auslastung haben oder gar auf 100% laufen würden.
 
So viel wie ich jetzt rausgekommen habe ist das Hauptproblem, dass Intel einfach massive auf Geschwindigkeit gesetz und die Sicherheit über die Jahre einfach dafür weckgelassen hat.
 
kurze blöde Frage. Warum sind im News Header eigentlich Sternchen drinnen?

Meltdown & Spectre: Details und Bench*marks zu den Sicherheits*lücken in CPUs
 
AMD wäre über die Jahre hinweg deshalb immer auf der Leistung wie Intel gewesen.:D
 
inge70 schrieb:
wie hast du das ausgelesen bzw wo hast du diese Liste her? Mein Core i3 3217U hat als CPU_ID 306A9

MCExtractor + Linux* Processor Microcode Data File
Alles entpacken, insbesondere den Ordner intel-ucode.

Code:
c:\MC Extractor v1.13.0>MCE.exe intel-ucode\06-3a-09

-------[ MC Extractor v1.13.0 r51 ]-------

Welcome to Intel, AMD, VIA & Freescale Microcode Extractor

Press Enter to skip or input -? to list options


File:       06-3a-09

Option(s):

+----------------------------------------------------------------------------------------------+
|                                            Intel                                             |
+---+-------+-----------+---------+------------+---------+--------+----------+--------+--------+
| # | CPUID |  Platform | Version |    Date    | Release |  Size  | Checksum | Offset | Latest |
+---+-------+-----------+---------+------------+---------+--------+----------+--------+--------+
| 1 | 306A9 | 12 [1, 4] |    1C   | 2015-02-26 |   PRD   | 0x3000 | 2F737D45 |  0x0   |  Yes   |
+---+-------+-----------+---------+------------+---------+--------+----------+--------+--------+

(Noch) Kein Glück für dich. IMO sind die aktuellen Updates auf Version 80 ein Indiz für den Fix.

xexex schrieb:
Die Wahrscheinlichkeit dass Meltdown genau im richtigen Moment den richtigen Speicherbereich liest ist vermutlich niedriger, wie die Wahrscheinlichkeit für einen 6er im Lotto.
Ich vermute mal, das man sich dafür auf ASLR verlassen muss. Andernfalls wäre es möglich den zu durchsuchenden Bereich drastisch einzuschränken.
Kann man ASLR durch einen anderen Bug aushebeln und sollte man so etwas offen diskutieren?

Sun_set_1 schrieb:
Davon ab, fahre morgen Mittag nach TrinkGut, bis dahin steht mein Angebot bzgl Bierkiste und Windows uCode / VMWare NTKernel-Treiberupdate bei boot :)
Morgen Mittag? Also vor dem Wochenende wird das nichts, muss arbeiten ;)
Außerdem gibt es bei TrinkGut nichts von Interesse :p

HasseLadebalken schrieb:
Hier zwecks Microcode ne Lösung für's Bios aber nur für maximal EFI , UEFI ist anders wenn überhaupt selbst machbar, für Award und Phenix Bios.
BIOS Mod ist die sauberste Lösung, aber auch ziemlich riskant. Man kann schnell sein Board damit schrotten, also VORSICHT!
 
Zuletzt bearbeitet:
Ich vermute mal, das man sich dafür auf ASLR verlassen muss.

Wenn das zutrifft erklärt das vielleicht warum Meltdown hier so "gut" funktioniert. Dieser Exploit hebelt AFAIK doch ASLR aus ? EDIT. Denn genau dafür ist doch der KPTI Patch da.
 
Zuletzt bearbeitet:
SlaterTh90 schrieb:
Irgendwie passen die Aussagen alle nicht zusammen. Einerseits wird von mehr als 20% Verlust gesprochen - einige Admins haben sich auf Twitter über CPU-Last Erhöhungen von bis zu ! 50% ! beschwert - und dann sagt Microsoft wieder dass das ganze "kaum spürbar" sei und viele Benchmarks belegen das auch....

Die Leistungsdefizite die von Admins gemeldet werden, betreffen in erster Linie diverse Linux Systeme und sind auf Windows nicht direkt übertragbar. Jede Anwendung und jedes Betriebssystem verhält sich anders was die Anzahl der Syscalls anbetrifft.

Unter Windows ist Windows 10 auch weniger betroffen als Windows 7 oder 8.

vander schrieb:
Kann man ASLR durch einen anderen Bug aushebeln und sollte man so etwas offen diskutieren?

ASLR wird ausgehebelt, da die Anzahl der Möglichkeiten an welchen Adresse sich das System befindet begrenzt ist. Deshalb wurde ja auch bei dem Veeam Test von 30min "Vorbereitung" gesprochen. Das ist so ungefähr die Zeit, um Adressen abzuklappern und die Startadresse zu finden an dem der Kernel liegt.

ASLR ist ja in erster Linie gegen Buffer Overflow Angriffe entwickelt worden, dort versuchte man ja gezielt eine bestimmte Adresse anzusprechen.

Iscaran schrieb:

In internen Tests schaffe man es in zwei Stunden, 8 GB RAM komplett zu erfassen, dabei laufe ein Core auf Volllast.

Welcher Aufbau? Welche Hardware? Oder doch nur journalistische Panikmache?

Der Forschern an der Uni ist also in 6 Monaten nicht das gelungen, was der Redaktion vom derStandard gelungen sein soll?
 
Zuletzt bearbeitet:
Zurück
Oben