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

[h00bi]

Wie siehts eigentlich beim VM Host aus? Muss an vmware / xen was gepatched werden?

EDIT: https://www.computerbase.de/forum/t...uecken-in-cpus.1737683/page-160#post-20823660

 

[Iscaran]

Potentielle Performance Drop@Intel durch KPTI-Patch (Meltdown):
https://newsroom.intel.com/editoria...tial-performance-data-results-client-systems/
hier als pdf
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Blog-Benchmark-Table.pdf

EDIT: Also so ca. 10% Performance drop auf CPUs ab Skylake...bei älteren Archs dürfte es weniger sein.

Ergänzung (11. Januar 2018)

@xexex: wegen unserer obigen Diskusssion Betreffs Meltdown vs Spectre:

Danke an hans-juergen für den link:

"As far as the impact goes, Meltdown is limited to Intel and ARM processors only, with AMD CPUs unaffected. But for Intel, Meltdown is extremely nasty, because it is so easy to exploit – one of our enthusiasts compiled the exploit literally over a morning coffee, and confirmed it works on every single computer he had access to (in his case, most are Linux-based). And possibilities Meltdown opens are truly terrifying, for example how about obtaining admin password as it is being typed in another process running on the same OS? Or accessing your precious bitcoin wallet? Of course, you'll say that the exploit must first be delivered to the attacked computer and executed there – which is fair, but here's the catch: JavaScript from some web site running in your browser will do just fine too, so the delivery part is the easiest for now. By the way, keep in mind that those 3rd party ads displayed on legitimate web sites often include JavaScript too – so it's really a good idea to install ad blocker now, if you haven't already! And for those using Chrome, enabling Site Isolation feature is also a good idea."

"But here comes the major difference between Meltdown and Spectre, which significantly complicates Spectre-based exploits implementation. While Meltdown can "scan" CPU cache directly (since the sought-after value was put there from within the scope of process running the Meltdown exploit), in case of Spectre it is the victim process itself that puts this value into the CPU cache. Thus, only the victim process itself is able to perform that timing-based CPU cache "scan"."
-----------------------------

Deswegen meinte ich oben Meltdown ist ein Super-GAU - aber eben zum Glück quasi schon gefixed (mittels des KPTI-Patches den es für Linux und Windows mittlerweile schon gibt).
Spectre ist hingegen viel schwerer zu nutzen und erfordert schon "Advanced Kenntnisse".

Btw. ein Password Manager wie Keepass schützt dein Passwort nicht ! http://www.pcgameshardware.de/CPU-H...-und-Meltdown-Ein-Erklaerungsversuch-1247385/

Nur ein schwacher Trost ist dies für die überwältigende Mehrheit an Rechnern, auf denen mit Zugangsdaten hantiert wird: Egal ob direkt eingegeben, im Browser oder in einem Passwort-Manager hinterlegt - alle Daten, die auf einem PC oder auf einem Server geladen werden, können potenziell abgehört werden.

 

[engine]

Ich sehe das alles kritischer und gehe eher mit der Aussage unten konform.
Es hilft nur eine neue CPU-Architektur, bis dahin sollte aber jede CPU ab z.B. Lynnfield/Nehalem mit Microcodes versorgt werden.
Und ja, es hat wohl Forscher erfordert, diese Sicherheitslücken zu entdecken, aber es gibt auch gute Schüler, die schnell lernen.


https://de.wikipedia.org/wiki/Intel-Core-i-Serie#Prozessoren_der_Broadwell-Generation

Anbei mal die Bewertung aus dem "Veeam Community Forums Digest" von Gostev. ( für alle die halbwegs fit in Englisch sind)

... Last but not least, do know that while those patches fully address Meltdown, they only address a few currently known attacks vector that Spectre enables. Most security specialists agree that Spectre vulnerability opens a whole slew of "opportunities" for hackers, and that the solid fix can only be delivered in CPU hardware. Which in turn probably means at least two years until first such processor appears – and then a few more years until you replace the last impacted CPU. But until that happens, it sounds like we should all be looking forward to many fun years of jumping on yet another critical patch against some newly discovered Spectre-based attack. ...

... Die meisten Sicherheitsexperten sind sich einig, dass Spectre Vulnerability eine ganze Reihe von "Chancen" für Hacker eröffnet, und dass die solide Fix kann nur in CPU-Hardware ausgeliefert werden. Was wiederum wahrscheinlich bedeutet, mindestens zwei Jahre, bis der erste solche Prozessor erscheint-und dann noch ein paar Jahre, bis Sie die letzte belastete CPU zu ersetzen. Aber bis das passiert, es klingt wie sollten wir alle freuen uns auf viele lustige Jahre springen auf ein weiteres kritisches Pflaster gegen einige neu entdeckte Gespenst-basierten Angriff.

 

[xexex]

Wie siehts eigentlich beim VM Host aus? Muss an vmware / xen was gepatched werden?

Meltdown wurde im November gepatcht (ESXi), Spectre ist eigentlich irrelevant.

Btw. ein Password Manager wie Keepass schützt dein Passwort nicht !

Weil?

 

[Iscaran]

Weil ?

Weil das Passwort spätestens bei "aktiver Verwendung" des Managers irgendwann entschlüsselt im Speicher liegt. (und Meltdown ja im Hintergrund einfach "live" mitläuft).
Ansonsten frag mal bei PCGh nach warum sie das schreiben.

 

[Neronomicon]

Das Ding ist doch durch. Meld. Patch ist draußen und bei Spectre muss die Software gepatcht werden. Risiko eines Schadens geht bei Otto N. gegen Null, weil sehr kompliziert. Verbreitung wird wie immer hauptsächlich E-Mail Anhänge sein. Ganz wichtig, den Remote Zugriff deakt. Was man aber seit erscheinen von diesen hätte machen sollen. Das Ding war schon ansich ein Mega Sicherheitslücke.
Und diese Fummelei einiger mit einer VM ist auch lustig.

 

[brutzler]

Guten Tag brutzler,

der Node Ihres Servers

$serverName

wurde wie angekündigt mit den neusten Updates gegen die Angriffsszenarien Meltdown und Spectre versehen. Hierzu haben wir das Betriebssystem, das BIOS und die Firmware der Hardware auf den neusten Stand aktualisiert.
Seit den Updates kommt es leider zu vorhersagbaren Ausfällen der Hardware. Die Logdateien zeigen, dass es angeblich zu Bit Fehlern auf den CPU kommt. Dieses passiert bei allen Servern mit Intel(R) E5-2600 und E5-2600v2 CPUs. Einen generellen Hardwarefehler schließen wir bisher jedoch aus. Auf anderen CPU-Generationen kommt ist nicht zu derartigen Fehlern.

Wir arbeiten auf Hochtouren um die Ursache dafür zu finden und diese zu beseitigen. Der Hersteller der Server, HPE, ist ebenfalls involviert.

Sollten wir bis Montag, den 15.01.2018 keine Lösung gegen die ungeplanten Neustarts der Hardware gefunden haben, bieten wir Ihnen an, dass wir Ihre Server auf ein System mit einer neueren CPU-Generation von Intel (R) umziehen. Bitte wenden Sie sich dann direkt an unseren Support um ein Wechselangebot zu erhalten. Der Wechsel wird für Sie kostenlos sein. Bis dahin müssen wir um Ihre Geduld bitten. Die garantierte Mindestverfügbarkeit werden wir einhalten.

Wir bedauern den derzeitigen Zustand sehr. Wir können verstehen das dieser nicht für Sie tragbar ist. Für uns ist dieser auch nicht tragbar und wir erwägen Ersatzforderungen gegen Intel (R). Als allererstes wollen wir aber Ihren bei uns gebuchten Server wieder in einen stabilen Zustand anbieten. Dafür scheuen wir auch keine erheblichen Mehrkosten, die wir zunächst selbst tragen werden.


Mit freundlichen Grüßen

$ServerAnbieter

Eben diese Mail von meinem Server Anbieter bekommen. Läuft für Intel

 

[Iscaran]

Wir bedauern den derzeitigen Zustand sehr. Wir können verstehen das dieser nicht für Sie tragbar ist. Für uns ist dieser auch nicht tragbar und wir erwägen Ersatzforderungen gegen Intel (R). A

Autsch....na wenn da mal jetzt noch Google/Amazon etc. "Ersatzforderungen" geltend machen...nur gut dass Intel ein Riesenpolster hat ein paar Milliarden können die locker aus der Portokasse zahlen.

 

[xexex]

Weil das Passwort spätestens bei "aktiver Verwendung" des Managers irgendwann entschlüsselt im Speicher liegt.

Ich wiederhole nochmal gerne meine Zitate.

While KeePass is running, sensitive data (like the hash of the master key and entry passwords) is stored encryptedly in process memory. This means that even if you would dump the KeePass process memory to disk, you could not find any sensitive data.

Furthermore, KeePass erases all security-critical memory when it is not needed anymore, i.e. it overwrites these memory areas before releasing them.

KeePass uses the Windows DPAPI for encrypting sensitive data in memory (via CryptProtectMemory / ProtectedMemory). With DPAPI, the key for the memory encryption is stored in a secure, non-swappable memory area managed by Windows. DPAPI is available on Windows 2000 and higher. KeePass 2.x always uses DPAPI when it is available; in KeePass 1.x, this can be disabled (in the advanced options; by default using DPAPI is enabled; if it is disabled, KeePass 1.x uses the ARC4 encryption algorithm with a random key; note that this is less secure than DPAPI, mainly not because ARC4 cryptographically is not that strong, but because the key for the memory encryption is also stored in swappable process memory; similarly, KeePass 2.x falls back to encrypting the process memory using ChaCha20, if DPAPI is unavailable). On Unix-like systems, KeePass 2.x uses ChaCha20, because Mono does not provide any effective memory protection method.

For some operations, KeePass must make sensitive data available unencryptedly in process memory. For example, in order to show a password in the standard list view control provided by Windows, KeePass must supply the cell content (the password) as unencrypted string (unless hiding using asterisks is enabled). Operations that result in unencrypted data in process memory include, but are not limited to: displaying data (not asterisks) in standard controls, searching data, and replacing placeholders (during auto-type, drag&drop, copying to clipboard, ...).
https://keepass.info/help/base/security.html

und füge noch die schöne Beschreibung von Veeam dazu.

Of course, all of that only sounds easy at a conceptual level - while implementations with the real-world apps are extremely complex, and when I say "extremely" I really mean that. For example, Google engineers created a Meltdown exploit POC that, running inside a KVM guest, can read host kernel memory at a rate of over 1500 bytes/second. However, before the attack can be performed, the exploit requires initialization that takes 30 minutes!

Wie hoch schätzt du die Gefahr ein, dass gerade in dem Moment in dem KeePass das Kennwort unverschlüsselt im Speicher hält, ein Angreifer genau diesen Bereich ausliest?

(und Meltdown ja im Hintergrund einfach "live" mitläuft)

Genau diese Aussage ist eben Quatsch. Meltdown läuft nicht im Hintergrund und überwacht Änderungen am Speicher. Meltdown kann mit seinen 1500B/s den Speicher lesen und braucht knapp 6h Stunden für einen Durchlauf bei 8GB RAM. Das Kennwort wird vermutlich für 5-10 Sekunden unverschlüsselt im Speicher sein.

Die Wahrscheinlichkeit dass Meltdown genau im richtigen Moment den richtigen Speicherbereich liest ist vermutlich niedriger, wie die Wahrscheinlichkeit für einen 6er im Lotto. Dazu muss jemand ja noch die Datenmenge auswerten, du bekommst mit Meltdown Rohdaten vom Speicher und irgendwie musst du die 8GB noch übertragen oder "vor Ort" auswerten.

 

[Janami25]

Natürlich dauert es noch ewig, bis die Probleme bei Intel hardwareseitig gelöst sind. Aber es bleibt einem nichts anderes übrig zu hoffen, das man die Performance Probleme durch Software Optimierungen/Bios Updates mildern kann.
Wenn nicht, kann man es sowieso nicht ändern. Und selbst die CPU Generationen in 2 Jahren sind nicht fehlerfrei, und man wird andere Lücken finden, und Gegenmassnahmen dafür einleiten. Solange man die Sicherheitslücken Patchen kann und sich die Geschwindigkeitverluste in Grenzen halten, ist das für mich zwar etwas ärgerlich, aber erträglich.

Richtig mies finden Ich es aber, das man seit einem halben Jahr davon gewusst hat. Und jetzt erst werden Patches und Bios Updates ausgerollt, das ist wirklich eine Sauerrei. Die grossen haben alle davon gewusst, man hätte genügend Zeit gehabt - vor allem auch für ältere Geräte - Bios Updates nach und nach rauszubringen, die sich der Sache annehmen. So hätte das still und heimlich über die Bühne laufen können, ohne das die Welt von dem Aufschrei was mitbekommt.

Aber man reagiert wie immer viel zu spät, das gilt für alle. Das ist es, was mich so masslos ärgert. Und jetzt schauen die User mit älteren Geräten in die Röhre, und können nur beten das es für Sie noch Patches/Bios Updates geben wird. Wie gesagt, Zeit genug dafür war vorhanden, dann wäre das ganze auch nicht so hochgekocht.

 

[BrollyLSSJ]

@brutzler

Danke für den Text. Wir setzen bei uns in der Firma auch Gen8 Server von HPE ein (den CPU Typ nutzen wir aber bei anderen Herstellern). Ich werde daher mal vorsichtig sein, wenn wir updaten dürfen.

 

[Iscaran]

@xexex:
Danke für dein Zitat: Ich zitiere: "For some operations, KeePass must make sensitive data available unencryptedly in process memory. For example, in order to show a password in the standard list view control provided by Windows, KeePass must supply the cell content (the password) as unencrypted string (unless hiding using asterisks is enabled). Operations that result in unencrypted data in process memory include, but are not limited to: displaying data (not asterisks) in standard controls, searching data, and replacing placeholders (during auto-type, drag&drop, copying to clipboard, ...)."

Heisst also dass Keepass immer DANN WENN es ein Password auch eintipped die Daten kurzzeitig entiffert und im Speicher ablegt.
Wenn da gerade ein Meltdown läuft.....DANN KANN er ein entschlüsseltes Passwort lesen. Verstehst du jetzt ? Meltdown muss dazu NICHT den ganzen Speicher auslesen...es reicht wenn es die Veränderten Speicherbereiche mitliest...außerdem KANN man Meltdown auch noch gezielt auf Bereiche springen lassen...
Aber gut, du weisst es ja besser als andere IT-Experten (und damit meine ich NICHT mich).

Die Wahrscheinlichkeit dass Meltdown genau im richtigen Moment den richtigen Speicherbereich liest ist vermutlich niedriger, wie die Wahrscheinlichkeit für einen 6er im Lotto. Dazu muss jemand ja noch die Datenmenge auswerten, du bekommst mit Meltdown Rohdaten vom Speicher und irgendwie musst du die 8GB noch übertragen oder "vor Ort" auswerten.

Du kannst doch mit Meltdown das System einfach mal längere Zeit bzw. immer wieder mal besuchen und mitscannen....die Auswertung machst dann wenn du Zeit hast ins geschriebene Logbuch deiner Javascript-Ads zu schauen.

EDIT: Außerdem ist es Spectre der initialisierungszeit braucht....du sollst nicht Originalzitate verändern !

...Google engineers created a Spectre exploit POC that,...

Siehe https://www.computerbase.de/forum/t...uecken-in-cpus.1737683/page-162#post-20825051

 

[branhalor]

Ich sehe das alles kritischer und gehe eher mit der Aussage unten konform.
Es hilft nur eine neue CPU-Architektur, bis dahin sollte aber jede CPU ab z.B. Lynnfield mit Microcodes versorgt werden.
Und ja, es hat wohl Forscher erfordert, diese Sicherheitslücken zu entdecken, aber es gibt auch gute Schüler, die schnell lernen.

Ja, es wird ne neue CPU-Architektur benötigt.
Und ja, bis dahin muß die Lücke auf anderen Wegen geschlossen werden. Ebenfalls d'accord.

Ich hab nur wie gesagt was gegen die größtenteils einseitige Panikmache der großen Seiten/Medien und die ganzen teils unfertig getesteten Schnellschüsse im Augenblick, die dann auch noch reihenweise für andere Bugs sorgen (können). Gerade im Rahmen der gesetzlichen Garantie- und Gewährleistungsfristen werden die Hersteller schon aus Eigeninteresse alles daransetzen, Fixes zu programmieren und auszuliefern - alles andere wäre ein finanzielles Fiasko, vom Image ganz zu schweigen.
Klar - ich mit meinem knapp sechs Jahre alten Board und Ivy werde da auch das Nachsehen haben. Sofern ich mich aber auf Software- und Verhaltensebene nicht anders/schlechter verhalte als früher, wird mein Risiko nicht signifikant steigen, mir nen Meltdown oder Spectre einzufangen. Das bereitet mir wirklich keine schlaflosen Nächte.

Xexes' neuster Post bestätigt mir das einmal mehr:

Of course, all of that only sounds easy at a conceptual level - while implementations with the real-world apps are extremely complex, and when I say "extremely" I really mean that. For example, Google engineers created a Meltdown exploit POC that, running inside a KVM guest, can read host kernel memory at a rate of over 1500 bytes/second. However, before the attack can be performed, the exploit requires initialization that takes 30 minutes!

Wie hoch schätzt du die Gefahr ein, dass gerade in dem Moment in dem KeePass das Kennwort unverschlüsselt im Speicher hält, ein Angreifer genau diesen Bereich ausliest?

Und auch ja, sicher wird es irgendwo auf der Welt Hacker geben, die den Meltdown ebenfalls während des Morgenkaffees oder kurz vor dem Schlafengehen mal eben programmieren, in ein JavaScript setzen und auf die Reise schicken. Oder das sogar schon getan haben, sehr wahrscheinlich sogar. Ja. Aber dagegen helfen bereits alle herkömmlichen Maßnahmen, die jeder PC-Nutzer mit etwas gesundem Menschenverstand ohnehin schon immer berücksichtigt haben sollte: Browser-Updates, keine dubiosen Drittseiten, keine merkwürdigen E-Mail-Anhänge öffnen und sich nicht von irgendwelchen wildblinkenden Pseudo-Warnmeldungen auf russische Hackerseiten umleiten lassen... Dann noch in ein paar Tagen ein ausgereiftes, ordentlich getestetes Windows-Update, und die Welt ist wieder in Ordnung.

 

[inge70]

Spectre muss die Software gepatcht werden.

Spectre wird via Microcode und Bios-Update gepatcht werden (zumindest bei Windows). wurde ja nun mehrmals geschrieben. Meltdown ist auf Softwareebene gepatcht bzw., wird gepatcht (Microsoft und einige Andere haben es schon hinter sich).

 

[-Legend-Storm-]

wurde es für win 7 64 bit jetzt schon gepatcht ? bei den aktuellen updates wurde meine cpu er schneller bzw mit vsync 5-10% weniger auslastung pro kern als vorher ... ich dachte es wird langsamer ?

 

[inge70]

auch für Win7 sollte der meltdown-patch schon draußen sein. Lediglich bei AMD-Systemen wurde der patch ausgesetzt, da viele User Probleme hatten. Weiß nun nicht wie weit das schon behoben wurde.

Spectre geht nur per Microcode-patch und Bios-Update.

 

[Iscaran]

@branhalor:

https://www.computerbase.de/forum/t...uecken-in-cpus.1737683/page-162#post-20825051

xexex hat das Zitat ausgetauscht im original oben lautet es

...Google engineers created a Spectre exploit POC that,...

 

[branhalor]

Danke für den Hinweis

Trotzdem denke ich, daß man auch dem Meltdown, bis allseits zuverlässige Patches ausgeliefert sind, mit den üblichen "Hausmittelchen" vorbeugen kann, wenn man sich nur daran hält.

 

[Iscaran]

Trotzdem denke ich, daß man auch dem Meltdown, bis allseits zuverlässige Patches ausgeliefert sind, mit den üblichen "Hausmittelchen" vorbeugen kann, wenn man sich nur daran hält.

Ja ich verfalle als privatuser da auch nicht in Panik...schliesslich ist der Hauptschutz für Otto N erstmal der, WEN interessiert Otto N ???

Die Entscheidenden Hacker interessieren sich für Zugangspasswörter von Firmen etc. und Firmennetzwerken...und die werden oder haben schon zum Großteil die KPTI-Patches ausgerollt.

 

[xexex]

Wenn da gerade ein Meltdown läuft.....DANN KANN er ein entschlüsseltes Passwort lesen. Verstehst du jetzt ?

DU kapierst es nicht!

Meltdown kann den gesamten Arbeitsspeicher Stück für Stück mit maximal 1500B/s lesen und von mir aus auch gerne die gesamte Zeit überwachen. Für EINEN "Durchlauf" benötigt man bei einem 8GB System 6-8h. Du liest also immer brav in kleinen Blöcken von 0-99999 und fängst von neuem an.

In der Zwischenzeit legt Keepass irgendwo im Speicher ein unverschlüsseltes Kennwort ab, damit du es kopieren oder einsehen kannst für sagen wir mal 5 Sekunden und löscht den wieder.

Wie hoch ist die Wahrscheinlichkeit, dass dein laufender Meltdownscan genau in diesem Moment, genau diese Speicheradresse liest, in der KeePass das Kennwort abgelegt hat?

EDIT:
Ein Angreifer würde jetzt vermutlich intelligenter vorgehen. Er würde zunächst nach dem Kernel im Speicher suchen, Prozesstabelle extrahieren, nach bekannten Prozessen suchen, und nur diese Speicherbereiche immer vom neuen Scannen.

Trotzdem ist die Geschwindigkeit von diesem Vorgang einfach nur Krüppellahm um es effektiv als Angriff nutzen zu können und wir reden hier noch immer vom direkten Zugriff über eine VM und nicht von einem Javascript Angriff.