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

[PolarSun]

Quelle?

Braucht es nicht wirklich, oder?

Liegt es nicht auf der Hand, daß immer mehr Malware versucht, bekannte Lücken auch auszunutzen? Wie jeder selbst leicht herausfinden kann, ist der Quellcode für die Proof-of-concept-Exploits schließlich seit einem Monat bei Github verfügbar.

Eine Statistik dazu von AV-Test.

Eine andere Frage ist inwieweit es Stand heute tatsächlich schon Angriffe gab/gibt. Soweit mir bekannt ist, gibt es da noch keine wirklich konkreten Anhaltspunkte dafür. Doch das ist freilich nur eine Frage der Zeit, worauf der an der Entdeckung der Lücke beteiligte Sicherheitsforscher Anders Fogh auch hinweist.

 

[frkazid]

Hier haste eine von mehreren

http://www.tomshardware.co.uk/meltdown-spectre-malware-found-fortinet,news-57826.html

edit: ups, tab wohl doch schon etwas länger offen...

 

[kisser]

Braucht es nicht wirklich, oder?

Doch.

Liegt es nicht auf der Hand, daß immer mehr Malware versucht, bekannte Lücken auch auszunutzen?

Ja, aber zwischen "Versuch" und "Gelingen" ist doch noch ein Unterschied.

Wie jeder selbst leicht herausfinden kann, ist der Quellcode für die Proof-of-concept-Exploits schließlich seit einem Monat bei Github verfügbar.

Ein PoC ist kein Exploit, sondern lediglich eine Machbarkeitsstudie. Und für diese gelten ganz bestimmte Voraussetzungen, unter anderem ist das System exakt bekannt.
https://www.aitiraum.de/news/meltdown-war-das-schon-alles

Glücklicherweise zeichnet sich gerade ab, dass Meltdown nicht das bislang angenommene Schadenspotential hat. Anders als im Meltdown-Paper beschrieben, ergeben alle bisher öffentlichtlich zugänglichen Beispiele (POCs) und überprüfbaren Informationen das folgende Bild: Damit per Meltdown erfolgreich Daten ausgelesen werden können, müssen sich diese an bekannter Speicheradresse (eine 32 bzw. 64 Bit Zahl) im CPU Cache befinden. Da dies aus dem Stand eine fast unlösbare Herausforderung ist, sind alle bislang verfügbaren Beispielangriffe auf die Mitwirkung des angegriffenen Programms angewiesen - auch das Beispielprogramm der Macher des Meltdown-Papers. Derzeit gibt es keine nachprüfbaren Veröffentlichungen oder bekannt gewordene Angriffe, die belegen dass sich tatsächlich Speicher ausserhalb des CPU Caches auslesen läßt, um dieses Problem zu umgehen. Selbst Tests von Google kommen zu dem Ergebnis, dass eine CPU-Cache Abhängigkeit besteht.

Die Autoren des Meltdown-Papers räumten auf Nachfrage diesen Sachverhalt bedingt ein, ohne allerdings wirklich Licht ins Dunkel zu bringen. Es wurden neue und bislang unbekannte Abhängigkeiten eingeräumt und mit Videos belegt, welche allerdings nach unserem Verständnis dem Meltdown-Paper widersprechen. Nach unseren eigenen Tests, Beobachtungen und Bewertungen der Aussagen erhärtet sich für uns die Theorie, dass Meltdown mindestens auf der überwiegend verbreiteten Hardware diesen besagten CPU-Cache Einschränkungen unterliegt, und auf der restlichen Hardware erst nach aufwendigen Anpassungen pro Hardware funktionieren kann.

Ergänzung (11. Februar 2018)

Hier haste eine von mehreren

http://www.tomshardware.co.uk/meltdown-spectre-malware-found-fortinet,news-57826.html

Alt und in dieser Form unsinnig, weil da auch der PoC Code und jede Abwandlung davon erfasst wird.
Das wurde hier an anderer Stelle im Forum schon diskutiert.

 

[PolarSun]

Ja, aber zwischen "Versuch" und "Gelingen" ist doch noch ein Unterschied.

Ein PoC ist kein Exploit, sondern lediglich eine Machbarkeitsstudie. Und für diese gelten ganz bestimmte Voraussetzungen, unter anderem ist das System exakt bekannt.

Eine Machbarkeitsstudie, klar, das ist schon richtig, wobei das schlicht die deutsche Übersetzung ist. Rein technisch gesehen ist ein PoC in diesem Fall natürlich ein Exploit, denn gerade das mögliche Ausnutzen der Sicherheitslücke wird schließlich nachgewiesen, was wiederum exakt der Definition für einen Exploit entspricht.

Falls ich Dich richtig verstehe, zielte Deine Nachfrage wohl eher auf den Nachweis/eine Quelle für konkrete Angriffe (oder zumindest Hinweise darauf). Diese gibt es meines Wissens nach - wie oben bereits geschrieben - bis dato nicht. Das wurde hier aber zuvor auch nicht behauptet - die bloße Existenz eines Exploits einerseits und die Ausführung echter Angriffe auf die Anwender andererseits sind zunächst zwei unterschiedliche Dinge.

Kurzum: Es gibt einen Exploit. Es gibt aktuell jedoch noch keine Anzeichen dafür, daß die Lücke von Schadcode mißbraucht wurde/wird.

 

[DFFVB]

@PolarSun: Sorry, das ist Mist was Du da erzählst... ein Exploit funktioniert in freier Wildbahn, ein POC ist etwas aus dem Labor unter Laborbedingungen....

 

[PolarSun]

@PolarSun: Sorry, das ist Mist was Du da erzählst... ein Exploit funktioniert in freier Wildbahn, ein POC ist etwas aus dem Labor unter Laborbedingungen....

Ich hatte mir gedacht, daß es nur ein Mißverständnis ist - darum ja die Erläuterung und nochmals zur Klarstellung, damit wir nicht aneinander vorbei reden:

Ein Exploit trägt diese Bezeichnung unabhängig davon ob er durch eine bestimmte Malware für konkrete Angriffe genutzt wird. (Das ist einfach die Terminologie.) Der PoC demonstriert es gibt so einen Exploit.

Wenn ein Sicherheitsforscher also sagt, er hat einen Exploit gefunden/entwickelt und könne dies mit einem PoC nachweisen, heißt das nicht zwangsläufig, daß auch bereits tatsächlich Schadcode in freier Wildbahn unterwegs ist, der die Lücke ausnutzt.

Häufig liegt beides zeitlich nah beieinander, weil Malware-Macher freilich interessiert daran sind, Sicherheitslücken möglichst schnell auszunutzen, die Erfolgsquote hängt schließlich auch maßgeblich von der Zahl der anfälligen Geräte ab. Das ist aber bei weitem nicht immer so, wie auch in diesem Fall.

Wer sich also Code auf Github anschaut (bezeichnenderweise unter dem Namen "meltdown-exploit" veröffentlicht!) und dort etwas von einem entsprechenden Exploit liest, braucht keine Panikattacken bekommen. Das heißt nicht Nutzer würden aktuell bereits Opfer von Schadcode für diese Schwachstelle. Es heißt nur: Wie haben Code, der demonstriert, daß und wie diese Lücke ausgenutzt werden kann. Und so etwas nennt man einfach Exploit.

 

[I'm unknown]

Wer sich also Code auf Github anschaut (bezeichnenderweise unter dem Namen "meltdown-exploit" veröffentlicht!) und dort etwas von einem entsprechenden Exploit liest, braucht keine Panikattacken bekommen. Das heißt nicht Nutzer würden aktuell bereits Opfer von Schadcode für diese Schwachstelle. Es heißt nur: Wie haben Code, der demonstriert, daß und wie diese Lücke ausgenutzt werden kann. Und so etwas nennt man einfach Exploit.

Stimmt, Nutzer mit Patch bekommen hier keine Schnappatmung. Einen Grund den Patch zu deaktivieren gibt es nur in wenigen Fällen, die Rechner sollten dann allerdings wie alle Rechner mit bekannten Lücken gesondert behandelt werden.

Nur weil keine bekannten Infektionen vorliegen ist das noch lange keine gerechtfertigte Annahme es gäbe keine!

 

[kisser]

Ich hatte mir gedacht, daß es nur ein Mißverständnis ist - darum ja die Erläuterung und nochmals zur Klarstellung, damit wir nicht aneinander vorbei reden:

Die Begriffe PoC und Exploit sind nicht immer ganz trennscharf.

https://de.wikipedia.org/wiki/Proof_of_Concept

Derselbe Begriff wird auch im Bereich der Computersicherheit verwendet. In diesem Umfeld wird als Proof of Concept angesehen, wenn eine Sicherheitslücke durch den Entdecker ausgenutzt wird, ohne dass eine Schadfunktion ausgelöst wird. Es wird dadurch bewiesen, dass ein Sicherheitsproblem besteht, so dass der Softwarehersteller dieses nicht beziehungsweise nicht weiter bestreiten kann.

https://de.wikipedia.org/wiki/Exploit

Dies hier beschreibt einen PoC:

Ein Exploit wird oft auch nur zum Aufzeigen einer Sicherheitslücke entwickelt und dokumentiert. Damit soll erreicht werden, dass Softwarehersteller eine Sicherheitslücke schneller erkennen und schließen können. Oft bezeichnet man die reine Beschreibung eines Exploits bereits als Exploit.

Hier geht es um Schadsoftware:

Zero-Day-Exploit nennt man einen Exploit, der eingesetzt wird, bevor es einen Patch als Gegenmaßnahme gibt. Entwickler haben dadurch keine Zeit („null Tage“ englisch zero day), die Software so zu verbessern, dass der Exploit unwirksam wird, um so deren Nutzer zu schützen. Entdeckt eine Person eine Sicherheitslücke und meldet sie nicht dem Software-Hersteller, sondern entwickelt stattdessen einen Exploit, um diese auszunutzen, so wird die Schwachstelle der Software oft erst lange nach dem ersten Angriff bekannt.

 

[PolarSun]

Die Begriffe PoC und Exploit sind nicht immer ganz trennscharf.

https://de.wikipedia.org/wiki/Proof_of_Concept

https://de.wikipedia.org/wiki/Exploit

Dies hier beschreibt einen PoC:

Hier geht es um Schadsoftware:

Ja, danke, durch Deine Zitate ist es noch einmal klarer. Möglicherweise haben einige nur die Definition eines Zero-Day-Exploits im Hinterkopf, auch wenn es um einen "regulären" Exploit geht (der ja nicht auf diesen Spezialfall beschränkt ist).

Was die Deaktivierung des Meltdown-Patches angeht: Naja, wenn es sich lohnen würde, um zumindest darüber nachzudenken. Abgesehen von ein paar Unterdisziplinen synthetischer Benchmarks muß man sich hinsichtlich Meltdown fast schon Mühe geben, überhaupt etwas messen zu können.

Unter Linux unterschieden sich die Meßwerte stärker zwischen einzelnen Distributionen und Kernelversionen als zwischen gepatchten und ungepatchten Systemen. Windows ist jetzt nicht so mein Gebiet, aber auch dort würde ich zunächst kein anderes Bild erwarten. Wer jetzt keine ganz speziellen Anforderungen hat, würde quasi schon Lebenszeit verschwenden, die Entfernung der Patches nur zu erwägen.

 

[Iscaran]

Tja - und schon wird Spectre 1 wieder gefährlicher und wird uns noch länger beschäftigen als uns lieb ist.
https://www.heise.de/security/meldu...piler-Fix-weitgehend-wirkungslos-3970815.html

Und zum Thema "Gefährlichkeit" weil "schwer" anzupassen...das hat sich dann auch bald erledigt.
https://www.heise.de/security/meldu...tware-automatisiert-CPU-Angriffe-3970686.html

 

[xexex]

Tja - und schon wird Spectre 1 wieder gefährlicher und wird uns noch länger beschäftigen als uns lieb ist.
https://www.heise.de/security/meldu...piler-Fix-weitgehend-wirkungslos-3970815.html

Das ist ein Clickbait Artikel von Heise und wie üblich nicht ernst zu nehmen. Man beachte bitteschön die Schlagzeile!

Meltdown & Spectre: Microsofts Compiler-Fix weitgehend wirkungslos

Beachte den Inhalt des Artikels

Sein Urteil: Mit der Option /Qspectre entdeckt der Compiler durchaus Code, der genau der Beschreibung entspricht, wie sie Kocher und seine Kollegen in ihrem Paper verwendet haben, und fügt CPU-Instruktionen ein, die den Code vor entsprechenden Angriffen schützen. Schon kleine Änderungen am Code hebeln aber die Erkennung aus, was dazu führt, dass Angreifer ihn nach wie vor missbrauchen könnten.

Dann liest man was Microsoft zu ihrem Compiler Switch erklärt.

In order to help developers mitigate this new issue, the MSVC compiler has been updated with support for the /Qspectre switch which will automatically insert one of these speculation barriers when the compiler detects instances of variant 1. In this case the compiler detects that a range-checked integer is used as an index to load a value that is used to compute the address of a subsequent load. If you compile the example above with and without /Qspectre, you will see the following code generation difference on x86:
...
It is important to note that there are limits to the analysis that MSVC and compilers in general can perform when attempting to identify instances of variant 1. As such, there is no guarantee that all possible instances of variant 1 will be instrumented under /Qspectre.
https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations-in-msvc/

Wo ist den der "Fix" wirkungslos? Er funktioniert genau wie er sollte, falls der Compiler so eine Situation entdeckt. Nichts anderes erklärt Microsoft in ihrer Dokumentation zu diesem Switch.

Wer glaubt nachdem er den Switch gesetzt hat wäre seine Applikation sicher, sollte an seinen Englischkenntnissen arbeiten.

 

[Arcturus128]

Heise war mal seriös, jetzt nur noch Clickbait. Super.

 

[Iscaran]

@xexex:

Wenn der Compiler wirklich nur 10% der Fälle "Patched" wofür LFENCE gedacht ist, würde ich nicht von Patch reden.

Wenn schon kleinste Änderungen am Code den Compiler in die Irre führen können ist es kein Patch...dann ist es noch nicht mal ein "ernstzunehmendes" Hemmnis.

Sorry. Da wird Microsoft schon nochmal nachbessern dürfen - oder aber diese Compiler Methode funktioniert nicht.

Bin mal gespannt inwiefern andere Compiler hier besser sind.

 

[kisser]

Da werden auch andere Compiler nichts grundlegendes daran ändern, weil bestimmte Sachen (wie eine Sprungbedingung) eben erst zur Laufzeit des Code feststehen.

Es steht doch im Artikel drin:

So sei jeder Ansatz, der von einem Compiler verlangt, zuverlässig kritische Code-Passagen zu identifizieren, zum Scheitern verurteilt. Jede Anstrengung in dieser Richtung müsse eine Abwägung zwischen Performance und Sicherheit treffen: Wer vollkommenen Schutz will, riskiert viele unnötige LFENCE-Schranken und damit einen hohen Leistungsverlust; wer Wert legt auf Performance, muss mit unentdeckten Schlupflöchern leben.

Man müsste vor jeden bedingten Sprung ein LFENCE setzen, also generell die spekulative Ausführung solcher Sprünge unterbinden.

 

[wertzuiop123]

Gibt es eigentlich irgendwelche News von Intel, wie weit sie sind?

Nur "Sie arbeiten weiter dran" oder? https://newsroom.intel.com/news/security-issue-update-progress-continues-firmware-updates/

Scheinen wohl noch nicht soweit zu sein, um Asus und anderen Herstellern die neuen überarbeiteten Updates weiterzugeben? ASUS hat irgendwie immer noch den Stand von 05.01 (https://www.asus.com/News/V5urzYAT6myCC1o2)

 

[I'm unknown]

Nur "Sie arbeiten weiter dran" oder?

Vermutlich, evtl. sogar etwas intensiver als das letzte halbe Jahr .

 

[Ekki-LM1]

Hallo liebe CPU-Experten,

sorry, wenn es in den vorherigen Beiträgen schon erwähnt wurde, hatte schon die Threadsuche benutzt, aber nichts gefunden.
Es wäre sehr nett, wenn mir jemand kurz mal eine Frage beantworten könnte:

Wie ich aus dem Thread rauslese, kann es durch die Windows-Updates (ab Jan.2018), die ja auch den Kernel betreffen, zu teils deutlichen Performance-Einbußen kommen.
Können damit auch Datenverluste einhergehen ?

als Bsp.: ich nutze Win7 mit Intel CPU Core i5-2400 ("Sandy Bridge")
Zur Datensicherung verwende ich Robocopy per Batchscript: damit werden regelmäßig komplexe Verzeichnisstrukturen abgeglichen u. mitunter große Dateimengen kopiert.

Kann es dabei (oder anderen Prozessen) zu Datenverlust kommen, wenn die neuen Win7-Updates installiert sind ?

Oder bedeutet der hier diskutierte "Performance-Verlust", daß sämtliche CPU-Prozesse einfach nur langsamer ablaufen, ohne dabei Dateien zu beschädigen ?

Vielen Dank schonmal, wer das kurz beantworten könnte

 

[Hancock]

Datenverluste sollten nicht auftreten, allerdings kann natürlich dadurch ein Bug entstehen, der das provoziert. Solch ein Bug ist bisher nicht bekannt, also sollte es zu keinem Datenverlust kommen.

 

[Ekki-LM1]

ok, Danke Hancock, das wollte ich wissen

 

[Mcr-King]

Naja stimmt nicht bei meiner Frau kam es grade durch den Pachte von Windoof zum Datenverlust musste dass Backupladen und alles wieder herstellen soviel dazu. 👎

Aber wahrscheinlich wieder eine dieser seltenen konfigs gewesen, trotzdem nervig gewesen und intel ist dadurch nicht beliebter bei mir geworden.