News Spectre V4 & (Meltdown) V3a: Details und Patches zu neuen CPU-Sicherheitslücken

[CS74ES]

Die Dinger sind einfach zu komplex, um alles komplett zu überblicken.

Exakt das ist, was mir schon lange durch den Kopf geht. Das Problem ist wahrscheinlich nicht, dass sie fahrlässig vorgehen, sondern weil keiner wirklich den Überblick hat.
Ist dann wahrscheinlich wie beim Schach, man kann einfach nicht alle möglichen Züge und deren Folgen kalkulieren.

 

[MK one]

Der Artikel ist auch nicht gerade neutral geschrieben.

Ich zitiere mal daraus:

Variante 3a betrifft ARM und Intel

Hört sich natürlich nicht so schön an wie Variante 3a betrifft ARM und Intel.

lt. Heise Artikel hat ARM die Variante 3a gemeldet , und Intel hat gesagt , diese wäre bei nur Intel schwer auszunutzen ( wenn man will wie bei AMD und Spectre V2 )
https://www.heise.de/security/meldu...ken-Spectre-NG-Updates-rollen-an-4051900.html

insofern ist die Nennung von ARM als erstes und Intel bei 3a angebracht ( sofern Intels Infos zutreffen )


Spectre V3a (Rogue System Register Read, CVE-2018-3640) wurde von ARM gemeldet. Laut Intel soll sich diese Lücke bei Intel-Prozessoren nur schwer für Angriffe nutzen lassen.

PS : was AMD und Spectre V4 betrifft , im Gegensatz zu Intel ( siehe Heise Artikel , deaktivieren von memory disambiguation kostet 2- 8 Prozent Performance ) kann memory disambiguation beibehalten werden
https://www.amd.com/en/corporate/security-updates
Based on the difficulty to exploit the vulnerability, AMD and our ecosystem partners currently recommend using the default setting that maintains support for memory disambiguation.
auch bei V4 kommt AMD somit besser weg

- Heise Artikel
Intel bringt aber auch neue CPU Microcode Updates, die wie bisher sowohl per BIOS-Update oder auch vom Betriebssystem eingespielt werden können. Die neuen Microcode-Updates sind in Beta-Versionen verfügbar und sollen im Laufe der nächsten Monate erscheinen. Die Microcode-Updates ermöglichen es Programmierern, in ihrem Code Funktionen zur Memory Disambiguation (MD) gezielt abzuschalten.

ergo muss ein Intel Nutzer , wenn er sichergehen will Memory Disambiguation deaktivieren bis ein Patch erscheint
das kostet Performance ( lt Intel ) - siehe Heise Artikel
Laut Intel mindert die Abschaltung von Memory Disambiguation die Systemperformance, und zwar um 2 bis 8 Prozent in Benchmarks wie BAPCo SYSmark 2014 SE und SPECint_rate_base_2006.

 

[Iscaran]

CVE 2018-3640 is im Grunde dieselbe Subvariante die schon damals als Meltdown CVE 2017-5754 als Variante 3a auf genau diesen 3 ARM CPU Typen anwendbar war...im Grunde also nichts weltbewegend neues. Man hat bei ARM halt nur die Lücke grundlegend analysiert und etwas erweitert auf Speculative Reads. Deswegen hat man ihr auch einen eigenen Namen verpasst da der "generalisierte" Angriffsweg über Speculative Reads auf Datenregister eben "neu" ist. Die Methode ist dennoch im wesentlichen die Alte von Januar 2018:
https://developer.arm.com/-/media/F...on=966364ce-10aa-4580-8431-7e4ed42fb90b&la=en

Variant 4 ist die eigentliche Neuheit und ist nun erstmal ein Spectre-artiger Angriff den man auch auf AMD CPUs mit einer Hitrate von 0.001% zum Laufen bringt.
Zum Vergleich Intel hat bei diesem PoC eine Hitrate von 0.1%.
https://bugs.chromium.org/p/project-zero/issues/detail?id=1528

Am Anfang ist ein PoC der auf die Anwendung von Speculative Reads testet...(daher die Hitraten). Weiter unten ist dann der eigentlich Angriffsvektor PoC (ist aber immer noch kein ganzer Exploit !!!).

"======== assisted BPF PoC ========
This is a PoC that demonstrates that this issue can potentially be used to attack the Linux kernel's BPF subsystem. This is *NOT* a full exploit against BPF; this is a PoC that requires kernel patches that permit the PoC to flush kernel memory from inside BPF and to measure access times to BPF arrays. It seems probable that these restrictions could be overcome, but my PoC doesn't do that."

"I have only tested this PoC on an Intel Skylake CPU."

Inwiefern dieser Vektor auf anderen CPUs dann auch funktioniert ist fraglich - insbesondere wenn man die stark unterschiedlichen Hitraten des Scan-PoCs betrachtet...kann mir da schon vorstellen dass es einen Unterschied macht ob ich in 1 von 1000 (0,1%) Speculative Reads Erfolg habe oder eben nur in 1 von 100000 (0,001 %). Denn die Reads müssen Erfolgen bevor die Cache daten wirklich wieder gelöscht werden. Was stark davon abhängt wie "erfolgreich" ich die Speculative Reads ausführen bzw. vorhersagen kann.

 

[MK one]

wie ich schon schrieb , AMD kommt auch bei V4 besser weg als Intel ...
@Iscaran
Danke für die Info .

 

[Iscaran]

Ja - ein Grund ist wohl der deutlich andere Ansatz der Branch Prediction und eben generell des Speculationsapparates. Stichwort "Perceptrons" und "Neurales Netz"
Siehe "Branch Prediction" Unterschiede zwischen Intel Core und z.B. Ryzen bei Agner Fog: http://www.agner.org/optimize/microarchitecture.pdf
"Branch prediction in Ryzen is based on perceptrons."

Skylake und Co verwende hier eben einen völlig anderen Ansatz. Wobei man natürlich schon einschränken muss dass beide Ansätze (mehr oder weniger) zum selben Endergebnis führen.
Aber Spectre Angriffe sind nun mal Angriffe auf den WEG und nicht auf das ZIEL ! Sozusagen.

Es wird zunehmend deutlicher dass man Spectre Attacken eben wohl schon sehr "maßschneidern" muss auf die jeweiligen Archs.

 

[Wadenbeisser]

Nur wäre es halt genauso falsch/riskant, statt dessen eine AMD-Monokultur aufzuziehen. Wobei dieses Risiko wohl kaum besteht. AMD muss ja praktisch wieder bei Null anfangen, sich im Server-Markt zu etablieren.

Es war aber auch nie davon die Rede von einem Extrem in das andere zu verfallen denn eine Ausweichmöglichkeit hat man nur dann wenn man ca. ein 50 / 50 Verhältnis besitzt.

Als Privatanwender schaut man halt nach wie vor auf P/L. Wobei ich nicht glaube, dass Ryzen da Meldown und Spectre nötig hatte, um konkurrenzfähig zu werden. Das waren sie auch vorher schon. Das sah ja auch Intel so, sonst hätten sie nicht so reagiert (plötzlich steigende Core-Anzahl usw.).

So formuliert ist das meiner Erfahrung nach falsch denn der Großteil der User besitzt überhaupt nicht das nötige Wissen um das zu entscheiden. Der Großteil ist darauf angewiesen was ihnen empfohlen wird und das driftet mit der Realität nur allso oft meilenweit auseinander.

 

[MK one]

@Iscaran
wußte gar nicht das ich nen Zweitaccount habe ...... namens Iscaran

um mich selbst zu zitieren ... ( endlich mal )

sie werden vielleicht nen theoretischen Ansatz erstellen können , aber nen lauffähigen Prototypen ? als Konkurrenz zu den etablierten Chipherstellern mit multi Milliarden Forschungsbudget ? Glaube kaum , zudem , AMD hat bereits mit "Neural Net Prediction " ne ( sehr einfache ) Simulation / Algorithmus in die CPU eingebracht , die Neuronen imitiert .

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Das ist übrigens der Grund warum Spectre V2 sehr schwer umzusetzen sein würde , falls es überhaupt jemals nen " Proof of Concept " dazu gibt . Man muss diesen Algorithmus schon sehr genau kennen um vorhersagen zu können wie er arbeiten würde , um die Daten abzugreifen .

2 Personen , ein Gedanke ...

 

[kisser]

Variant 4 ist die eigentliche Neuheit und ist nun erstmal ein Spectre-artiger Angriff den man auch auf AMD CPUs mit einer Hitrate von 0.001% zum Laufen bringt.

Da ist wohl eine 0 zuviel nach dem Komma.

Ergänzung (24. Mai 2018)

Ja - ein Grund ist wohl der deutlich andere Ansatz der Branch Prediction und eben generell des Speculationsapparates. .

Das halte ich für unwahrscheinlich. Ziel jedes predictor-Algorithmus ist es, mit höchstmöglicher Wahrscheinlichkeit das Richtige vorherzusagen. Sonst könnte man auch gleich auswürfeln, ob und ggf. welcher branch genommen wird.

 

[Iscaran]

Da ist wohl eine 0 zuviel nach dem Komma.

Echt jetzt Kisser? Das ist das einzige dass du nach 2 Tagen Recherche als Haar in der Suppe findest ?

Hast du den Link auch gelesen ? Wieviele Nullen siehst du hier bei der Hitrate ?

EDIT: Und das ist (hoffentlich) das letzte mal dass ich auf deine vorgetäuschte Unwissenheit reagiere. Geh woanders provozieren. Die Zahlen dienten als Vergleich der Größenordnung...
Anders formuliert würde mein Satz oben lauten können:
Zwischen circa 0.1% @intel und circa 0.001 % bei AMD liege CIRCA ein Faktor 100.

 

[kisser]

Echt jetzt? Aus deinem Link.

AMD desktop, normal:

$ gcc -o test test.c -Wall -DHIT_THRESHOLD=200 -std=gnu99
$ ./test
0: 0000000000000000000000000 in 1000000 cycles (hitrate: 0.002500%)
0: 000000000000000000000 in 1000000 cycles (hitrate: 0.002100%)
0: 00000000000000000000000000000000 in 939816 cycles (hitrate: 0.003405%)
0: 00000000000000000000000000000000 in 903838 cycles (hitrate: 0.003540%)
0: 00000000000000000000000000000000 in 360430 cycles (hitrate: 0.008878%)
1: 11111111111111111111111111111111 in 484242 cycles (hitrate: 0.006608%)
1: 11111111111111111111111111111111 in 331271 cycles (hitrate: 0.009660%)
0: 00000000000000000000000000000000 in 388049 cycles (hitrate: 0.008246%)
1: 11111111111111111111111111111111 in 282588 cycles (hitrate: 0.011324%)
1: 11111111111111111111111111111111 in 359558 cycles (hitrate: 0.008900%)
1: 11111111111111111111111111111111 in 359013 cycles (hitrate: 0.008913%)
0: 0000000000000000000000000000000 in 1000000 cycles (hitrate: 0.003100%)
1: 11111111111111111111111111111111 in 501067 cycles (hitrate: 0.006386%)
0: 00000000000000000000000000000000 in 312420 cycles (hitrate: 0.010243%)
1: 11111111111111111111111111111111 in 784663 cycles (hitrate: 0.004078%)
1: 11111111111111111111111111111111 in 954189 cycles (hitrate: 0.003354%)

 

[Iscaran]

Und ? Bei Intel sinds werte um +-0.1% mal mehr mal weniger...bei AMD sind 0.0002 % bis hin zu 0.01%...in der Regel Werte um 0.003 %...

Das ist zwar vielleicht ein Faktor 3 mehr als die round about 0.001% die ich plakativ verwendet habe. Aber es ging ja darum die Größenordnung klarzulegen.
Zwischen 0.3% und 0.003% sinds genauso ein Faktor 100....

Sind wir jetzt damit fertig Nullen zu zählen oder hast du noch konstruktives beizutragen ?

 

[kisser]

Deine Unkenntnis wird nur noch von deinem peinlichen Benehmen getoppt!!

Bei deinen 0,0002% mit SMP off funktioniert der POC überhaupt nicht. Der PoC bricht dann ab.
Steht auch oben im Text. Kann man auch aus dem Code herauslesen, dass nur max. 1.000.000 Zyklen gefahren werden, weil das System sich sonst bei deaktivierten Interrrupts aufhängt.

Interestingly, only on the Skylake laptop, it seems to work when
interrupts and SMP are disabled while the test is running; on the
other machines, it seems to only work when interrupts are enabled,

und

#endif
pipeline_flush();
long cycles = 0;
int hits = 0;
char results[33] = {0};
/* if we don't break the loop after some time when it doesn't
work, in NO_INTERRUPTS mode with SMP disabled, the machine will lock
up */
while (hits < 32 && cycles < 1000000) {
pipeline_flush();
int res = testfun(idx);
if (res != -1) {
pipeline_flush();
results[hits] = res + '0';
hits++;
}
cycles++;
pipeline_flush();
}
pipeline_flush();
#ifdef NO_INTERRUPTS
asm volatile("sti");
#endif
out_ += sprintf(out_, "%c: %s in %ld cycles (hitrate: %f%%)\n",
//und hier siehst du wo deine 0,0002% herkommen:
secret_read_area[idx], results, cycles, 100*hits/(double)cycles);

100*2/1000000 ist wieviel?

EOD. Du hast weder die Kenntnis noch das Benehmen, dass es wert wäre mit dir zu diskutieren.
Was konstruktives beitragen? Mach ich immer. Jetzt bist du an der Reihe.

 

[Iscaran]

Kann man auch aus dem Code herauslesen, dass nur max. 1.000.000 Zyklen gefahren werden, weil das System sich sonst bei deaktivierten Interrrupts aufhängt.

Ja das hatte ich nicht direkt erwähnt oben - schön dass du das jetzt hier nochmal verdeutlichst. Jedoch schrieb ich schon weiter oben:
"... Denn die Reads müssen Erfolgen bevor die Cache daten wirklich wieder gelöscht werden. "

Hätte noch hinzufügen müssen: "oder bevor sich das System wegen des PoCs aufhängt."
Aber ich gehe davon aus dass man den Hardlock programmiertechnisch eben in einem ECHTEN PoC bzw. Exploit umgehen kann bzw. würde. (bzw. bei SMP ON kommt es nicht zu einem Hardlock. Allerdings wirft das System wohl einen Fehler der irgendwo gelogged wird.)

Letztlich ist man in dem Fall auf 999.999 Ausleseversuche limitiert....und wenn man in der Zeit sein "Secret" nicht hittet - hat man halt nichts gewonnen. Deswegen ist die Hitrate des PoCs ja auch interessant. Denn sie Zeigt indirekt welche Datenraten man "abgreifen" kann.

Alternativ kannst dir auch einfach die Cyclezahlen im Vergleich ansehen - bei AMD dauert es oft bis zu 1.000.000 Cycles bis er das Geheime Bit gefunden hat...bei Intel sind die meisten bits in 100.000 Cycles abgehakt.

Der PoC zeigt also auch wieviel schneller der Datenleak auf der Skylake Architektur geht. Es gibt also wohl doch Unterschiede in der Arch die die Exploitbarkeit erhöhen bzw. senken. Irgendwoher wird ja AMDs Statement zu Spectre V2 mit "near zero exploitability" ja herkommen. Und auch bei V4 sehen wir einen Faktor 10-100 "weniger" Leak-Datenrate, bzw. hitrate bei Excavator vs Skylake. Schade dass Jann Horn keinen Ryzen getestet hat. Wäre interessant zu sehen wie sich der mit dem PoC verhält.

EDIT:

Was konstruktives beitragen?
Mach ich immer.

Nein leider mussten wir erst 3 sinnlose posts über die Zahl der "nullen" austauschen bis du mal mit was rübergerückt bist das Inhalt hat....der erste Post von dir diente nur dazu mit einem möglichst unerläuterten minimal-Beitrag den Post von mir zu diskreditieren ohne jedwede weitere Info zu liefern.

 

[Neronomicon]

Ich sehe als Privatanwender den ganzen Rummel gelassen entgegen. Außer wenn es durch Patches zu stärkeren Performance Einbrüchen kommt.
Der normale Dau hat auch ganz andere Probleme, als die theoretischen, nämlich wenn er wieder den nächsten E-Mail Anhang öffnet mit einer lustigen Maleware.

 

[DEFCON2]

Wir sind hier aber nicht normale Daus, für die ohnehin jede Hoffnung verloren ist. Wir müssen nur Hardware vom selben Fließband wie diese armen Daus ertragen.

 

[Oli-nux]

Hmm, habe auf meiner neuen Hardware das aktuellste Bios-Update vom März, das beinhaltet wohl nur die V1 und V2.
Somit muss ich auf ein Update für V4 warten/hoffen.

Was ich noch sagen wollte, nachdem ich noch den alten Quad 6600 in Betrieb hatte und das Windows-Update für Meltdown/Spectre, war alles sehr langsam, das kann ich mit der neuen Hardware jetzt (noch ) nicht behaupten - läuft alles sehr flüssig.

 

[inge70]

@Oli-nux,

gegen V4 gibt es derzeit noch nichts an Updates. Daher warten ALLE auf entsprechende Gegenmaßnahmen.

 

[MK one]

tja , Intel hat s nicht leicht , da flicken sie in den neuen CPU s für Ende 2018 Spectre V2 + V3 und müssen bei V4 doch wieder patchen ... ( incl 2 - 8 % Leistungsverlust , zumindest derzeit )
https://www.gamestar.de/artikel/spe...nkt-leistung-um-bis-zu-8-prozent,3330137.html

Neue CPU gegen Spectre 2 und 3 geschützt
Dazu sollten schon die Prozessoren, die für Ende 2018 erwartet werden, entsprechende Hardware-Anpassungen enthalten. Intel-CEO Brian Krzanich hatte von Schutzmauern gegen die damals bekannten Versionen Spectre 2 und 3 gesprochen, die zwischen Programmen und den verschiedenen Rechtestufen der Nutzer stehen und so ein Hindernis für Angreifer darstellen sollen.

Wie Threatpost unter Bezug auf Chip-Experten meldet, werden diese sogenannten Schutzmauern in der Hardware zwar gegen die länger bekannten Spectre-Varianten helfen, nicht aber gegen Spectre-Version 4.

da kommt mir gleich wieder der Spruch " Löchrig wie ein schweizer Käse " in den Sinn , war der aus dem C t Artikel ? ich weiß es nicht mehr ..

 

[Hill Ridge]

Dazu sollten schon die Prozessoren, die für Ende 2018 erwartet werden, entsprechende Hardware-Anpassungen enthalten.

Die angebliche Hardwareanpassung, ist ein Microcode:O

Intel verarscht da einfach wieder mal alle

 

[MK one]

...
Trotz Versprechen: Intels kommende Chips bleiben Spectre-anfällig
Trotz Versprechen: Intels kommende Chips bleiben Spectre-anfällig

Intel hat wirklich nichts dazugelernt ... , sie haben spezifisch für V2 und V3 nen kleines Pflasterchen eingearbeitet , lassen aber den schweitzer Käse ihrer Architektur weiterhin löchrig .

Intels Lösung mit einer hardwarebasierten Sicherheitsvorkehrung für seine neuen Chips wurden spezifisch für V2 und V3 entwickelt und werden sich nicht auf die neu entdeckte Variante 4 auswirken können, wie Threat Post berichtet.