News Massive Sicherheitslücke in Intel-CPUs der letzten Jahre

[CeEstMoi]

... so, was fällt mir dazu ein?
wenige Plattformen überhaupt
Epyc scheint nicht in der Menge verfügbar zu sein, wie es müsste
Speichermarkt wird auch zusammen brechen (welche Firma hat da die meisten Ressourcen?)
... eine spannende Zeit

 

[Thunderbird 1400]

Also gut, wenn ich das jetzt bei Golem richtig verstanden habe (www.golem.de/news/spectre-und-meltd...schon-seit-juni-2017-bekannt-1801-131958.html), betrifft Spectre sowohl Intel als auch AMD und ARM Prozessoren, Meltdown dagegen nur Intel Prozessoren.
Golem schreibt auch von einem Android Patch, der allerdings erst am 05.01. kommen soll.

Viel wichtiger ist die Frage, was man tun kann, um sich in der Zwischenzeit zu schützen. Reicht das Meiden von allen unbekannten/ zwielichtigen Websites aus, oder ist automatisch jeder am Arsch, der irgendwo im Netz Anmeldedaten besitzt, weil Kriminelle die Accounts hacken könnten?

 

[Pinnacle Ridge]

AMD betrifft es nicht, solange man den Bug nicht selbst aktiviert!

 

[Complicated]

Schön und gut, aber das sagt nun wirklich nicht viel aus, da nicht gesagt wird, wie genau denn diese "Änderung einer Default-Einstellung" genau aussieht und ob man vielleicht auch diese Einstellung von außen manipulieren kann. Ist jetzt für mich kein Beleg dafür, dass AMD nicht ebenfalls signifikant betroffen ist.

Na dann lies halt eine Seite weiter vorne Beitrag #39 - http://www.planet3dnow.de/vbulletin...sluecke-in-Intel-CPUs-der-letzten-Jahre/page2
Wie wäre es wenn du überhaupt mal den Thread liest?

Hier eine Präsentation von der Blackhat 2016 die den Meltdown-Angriff sehr detailliert beschreibt:
https://www.blackhat.com/docs/us-16...Layout-Randomization-KASLR-With-Intel-TSX.pdf
Das heisst es ist schon über 1 Jahr bei Hackern bekannt. Das besonders alarmierende ist, dass dort gezeigt wird wie TSX Instruktionen dafür verwendet werden um den OS Exception Handler zu umgehen. Sprich das OS wird umgangen und bekommt überhaupt nichts mit. Der ganze Angriff ist dort sehr schön nachvollziehbar beschrieben.

 

[Stefan Payne]

Tjo, schaut so aus, als ob da noch der eine oder andere Patch notwendig ist...

https://twitter.com/never_released/status/948996493280731139?s=09

 

[sompe]

Gibt wohl noch ein anderes "kleines" Problemchen.
https://www.theregister.co.uk/2018/01/04/azure_vms_down_following_meltdown_patch/

 

[eratte]

Verstehe nur noch nicht, warum hier (bei P3Dnow) bloß von einem Problem der Intel Prozessoren berichtet wird, während alle Welt von "Milliarden betroffener Geräte" inkl. Smartphones und Tablets berichtet. Was stimmt denn nun?

Der Artikel wird von Nero bestimmt noch ein Update bekommen also kein Grund Panik zu verbreiten. Aber die Infos sind doch alle auch hier im Forum vorhanden man muss sie nur lesen. Zu dem verändert sich die Sachlage auch ständig mit neuen Infos.

 

[Peet007]

Also ich kann mir auch denken warum man gerade jetzt auf die Problematik aufmerksam wird. Wenn man auf HBM umsteigen will muss eben Intel seinen "Murks" bereinigen, sonst schleppt man das ewig und drei Tage mit.

Also die ganze Cache Anbindug neu und vor allem sauber entwickeln.

 

[Mitsch79]

Hier eine Präsentation von der Blackhat 2016 die den Meltdown-Angriff sehr detailliert beschreibt:
https://www.blackhat.com/docs/us-16...Layout-Randomization-KASLR-With-Intel-TSX.pdf
Das heisst es ist schon über 1 Jahr bei Hackern bekannt. Das besonders alarmierende ist, dass dort gezeigt wird wie TSX Instruktionen dafür verwendet werden um den OS Exception Handler zu umgehen. Sprich das OS wird umgangen und bekommt überhaupt nichts mit. Der ganze Angriff ist dort sehr schön nachvollziehbar beschrieben.

Ein Träumchen :/
Das sind bald 1,5 Jahre, dass der Exploit bekannt und veröffentlicht ist.
Man kann also davon ausgehen, dass die Wahrscheinlichkeit, dass er ausgenutzt wird, bei 100% liegt.

Auf jeden Fall wäre mal eine konsolidierte Stellungname aller Hersteller angebracht und eine exakte Aufstellung
aller (wirklich, also angreifbar) betroffenen CPUs. Wenn aktiv irgendein Setting geändert werden muss, dann ist die entsprechende (AMD-)CPU, nach meinem dafürhalten, weder betroffen noch angreifbar. Denn das entspräche der Argumentation, dass alle Computer unsicher und angreifbar wären, der Nutzer müsste ihn dafür nur vor die Haustür stellen und sein Passwort daneben legen.
Etwas anderes ist es, wenn das Setting über andere Angriffe geändert werden kann, aber dafür gibt es bisher keinerlei Anzeichen.

 

[eratte]

Sehr schöne Zusammenfassung Nero

 

[Peet007]

Der Artikel schafft Klarheit, vor allem das AMD CPUs nur durch Änderung der Werkseinstellungen angreifbar werden.

Bei mir läuft der Kernel 4.15.rc6 auf einem Ryzen und der Patch ist nicht aktiv. Von dem her ist man als AMD User überhaubt nicht betroffen.

 

[eratte]

Bei Spectre ist die Lage noch zu unklar als das man sagen könnte das betrifft keine AMD CPUs, Variante 1 soll alle CPUs betreffen und muss in den Anwendungen gefixed werden.

Erste Browserupdates gibt es ja schon. Im Moment kann man nur abwarten und sehen das man seine Systeme mit Updates versorgt. Ich denke da werde noch einige kommen.

 

[Complicated]

P3DNow wieder in Höchstform bei dem Update!
Das Update, das Timing und die Geduld bis die Nebelkerzen sich gelichtet haben und vor allem die Vollständigkeit. Die Qualität dieses Artikels ist vorbildlich und weit vor dem Gewurschtel anderer Publikationen einzuordnen.
Danke dafür Nero24 und auch danke an errate für die getrennt gepflegte Linksammlung in den Usernews. Die Kombination der Quellen und Erläuterungen auf den Punkt ist so nirgendwo im Internet zu finden.

 

[TAL9000]

ARM

Variant 3a
For Cortex-A15, Cortex-A57, and Cortex-A72

Da blicke ich gerade nicht durch wo der Unterschied zu Variante 3 (Meltdown) ist oder ist das doch Specter (Variante 1+2)EDIT: https://developer.arm.com/support/security-update/download-the-whitepaper zeigt mir dann im PDF denn Unterschied:

Subvariant 3a - using speculative reads of inaccessible data
Overview of the Mechanism
In much the same way as with the main Variant 3, in a small number of Arm implementations, a processor that
speculatively performs a read of a system register that is not accessible at the current exception level, will actually
access the associated system register (provided that it is a register than can be read without side-effects). This access
will return a speculative register value that can be used in subsequent speculative load instructions. If the
speculation is not correct, then the results of the speculation will be discarded, so there is no architectural revelation
of the data from the inaccessible system register. However, on such implementations, the data returned from the
inaccessible system register can be used to perform further speculation. It is this further speculation that is exploited
by the speculation-based cache timing side-channels

Da der Link mich zur ursprünglichen Seite zurückführte und das PDF klein ist, habe ich den Download gar nicht bemerkt...

Irgendwie doch froh das mein kommunikatives Zweithirn mit einem Cortex-A53 befeuert wird (Phicomm Energy M+ E551).

 

[eratte]

Steht doch im Artikel von Nero:

- Variant 1 „Spectre 1” : bounds check bypass (CVE-2017-5753)
- Variant 2 „Spectre 2” : branch target injection (CVE-2017-5715)
- Variant 3 „Meltdown” : rogue data cache load (CVE-2017-5754)

3 und 3A müssen also Meltdown sein.

In addition, Arm has included information on a related variant to 3, noted as 3a, in the table below.

Variant 3a

For Cortex-A15, Cortex-A57, and Cortex-A72:

In general, it is not believed that software mitigations for this issue are necessary. Please download the Cache Speculation Side-channels whitepaper for more details.

 

[SPINA]

Zusammen mit den meisten andern mir bekannten Sicherheitsproblemen/HW Fehlern, sind Meltdown und der Intel ME die eher schlimmeren in der letzten Zeit, wo bei ich auch sagen muss das ich nicht einmal bis her mit meinen Ryzen ein Kernel compiliert habe (SegFault-Bug).

Sollte man von gehäuften Schutzverletzungen unter hoher Last bei einem Ryzen geplagt sein, kann man sich an AMD Customer Care wenden und ein Support Ticket erstellen. Meinen Ryzen (vom Herbst 2016) betrifft dieser Hardwarebug leider ebenfalls, aber umtauschen werde ich ihn voraussichtlich trotzdem nicht. Ich konnte den Hardwarebug bisher nur mit dem kill-ryzen.sh Skript aufdecken; in freier Wildbahn habe ich ihn noch nicht wissentlich angetroffen. Dieser Hardwarebug trifft eher Rechenzentren, die CPUs für den Desktopeinsatz zweckentfremden, oder Softwareentwickler.

Man erhält jedenfalls ein Formular vom AMD Customer Care und dieses muss man ausfüllen. Ist dies geschehen und der Garantiefall von AMD anerkannt worden, erhält man einen Code für DHL Express und kann damit seinen betroffenen Ryzen einschicken. Dem Vernehmen nach erhält man zwei bis drei Wochen nach dem Öffnen des Support Tickets einen Austauschprozessor, der den Fehler nicht mehr aufweisen sollte. Das Stepping bleibt mit ZP-B1 gleich, aber es kommt eine neuere Revision der Maske zum Einsatz, bei welcher der Hardwarebug nicht mehr auftreten kann. Beim Threadripper hat AMD diese von Anfang an verwendet, daher ist dieser generell nicht betroffen. Für Epyc im ZP-B2 Stepping gilt dasselbe; dort wäre der Fehler fatal gewesen.

Von solch einem Austauschprogramm könnte sich Intel bei Meltdown eine Scheibe abschneiden, aber sie haben bekanntlich nichts zum Tausch anzubieten und wenn doch, dann würde ein solches Programm Intel angesichts des Ausmaßes im Handumdrehen ruinieren. Bei Ryzen ist der Schaden überschaubar, da der Hardwarebug nur einige Hundertausend Early Adopter betrifft; wobei umstritten ist, ob er nur unter Linux und BSD zu Tage tritt.

 

[Peet007]

Interessant wenn man langsam ein Bild von der ganzen Sache bekommt.8)

Spätestens 2016 bekanntwerden der Sicherheitslücke durch Black Hat (durch den Namen könnte man auch Rückschlüsse ziehen). AMD hatte Zen in der Entwicklung und musste darauf reagieren. Ihn fittmachen für das kommende. z. B. Speicherzugriffe dementsprechend zu unterbinden, Testen was für eine Rohleistung denn Ryzen dann hat. Für Intel mehr als genug. So gut wie nichts komunizieren beim Release.

Intel hat anscheinend su gut wie gar nichts unternommen. Einfach so weitergemacht, Ryzen war aber in der Lage Intels High End alt aussehen zu lassen. Anstatt jetzt zu reagieren um wenigstens ihre neue Plattform gegen die Angriffe fitt zu machen. Ham die nur ihre alten Sachen neu aufpoliert, um sie schnellstmöglicht an den Mann zu bringen. Jetzt sind ja "Alle" betroffen.

Die Wand an der sie jetzt stehen haben sie anscheinden nicht kommen sehen.

 

[deoroller]

Dann passt das dazu.

Linus Torvalds: Will Intel "Scheiße für immer und ewig verkaufen"?
https://www.heise.de/newsticker/mel...rkaufen-3934829.html?wt_mc=rss.ho.beitrag.rdf

 

[sompe]

Was mich bisher am meisten fasziniert ist der Kursverlauf von Intels Aktien.
Seit Bekanntgabe hatten diese nur gute 10% verloren und sind aktuell wieder am steigen. AMD hätte in dem gleichen Zeitraum wohl mindestesn 10% pro Tag verloren. ^^
Aber gut, ich bin ja schon zufrieden das diesmal nicht wie so oft bei schlechten NAchrichten für Intel die Aktien von AMD fallen und die von Intel steigen.

 

[WindHund]

So schnell tauscht keiner was aus.

Erste Tests.

https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/

Naja, wenn die Server im oberen 90% Bereich laufen und durch die Patches Leistung verloren geht, wird es unausweichlich sein Aufzurüsten da die Leistung nicht mehr reicht.

Der ARM A5 scheint auch nicht betroffen zu sein, welcher in der APU sitzt und die Schlüsselverwaltung übernimmt.

 

[Complicated]

Eine Anleitung um sein System zu überprüfen mit Powershell unter Windows 7 x64
http://www.planet3dnow.de/vbulletin...-Verifikation-Windows-7?p=5184706#post5184706

 

[RedBaron]

Sind die AMD FX und Ryzen CPUs auch von einem Performance Verlust durch die Patches
des Linuxkernel oder MS Windows betroffen?

 

[Complicated]

Nein, da die Patches, die bisher veröffentlicht wurden auf AMD Hardware gar nicht aktiv sind.
Und wenn man die Informationslage zu der Variante 1 betrachtet, wird es dafür keinen OS-Patch geben, sondern da wird die jeweilige Software das Problem angehen müssen und die Lücke stopfen, so wie es eigentlich bei den meisten Sicherheitslücken der Fall ist. Welche Performance-Auswirkungen das haben wird, werden Tests der jeweiligen spezifischen Software ergeben, so wie das derzeit bei größeren Spiele-Patches oder Treiber Updates ja auch gemacht wird.

Soweit man das derzeit beurteilen kann werden AMD User keinerlei allgemeine Performance-Penaltys erleben, die durch das OS verursacht werden. Es werden dort auch nur Variante 2 und Variante 3 angegangen.

 

[Nero24]

Soweit man das derzeit beurteilen kann werden AMD User keinerlei allgemeine Performance-Penaltys erleben, die durch das OS verursacht werden.

...solange die Entwickler sauber arbeiten und Fixes auch nur auf den betroffenen Plattformen aktivieren. Wenn nicht, und z.B. der Meltdown-Fix auf einem (nicht von dem Bug betroffenen) AMD Epyc-System aktiviert wird, kann das dramatische Folgen haben:

<blockquote class="twitter-tweet" data-lang="de"><p lang="en" dir="ltr">This is bad: performance hit from PTI on the du -s benchmark on an AMD EPYC 7601 is 49%. <a href="https://t.co/TT2aQpsb5U">https://t.co/TT2aQpsb5U</a> <a href="https://t.co/Y12B1SIUMd">https://t.co/Y12B1SIUMd</a></p>&mdash; grsecurity (@grsecurity) <a href="https://twitter.com/grsecurity/status/947439275460702208?ref_src=twsrc%5Etfw">31. Dezember 2017</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

 

[Complicated]

Meltdown-Patch (PTI) wird derzeit auf AMD Systemen nicht aktiviert durch Windows oder Linux. Siehe Check mit Powershell für Windows. Linux ist ja schon bekannt.

Eine Anleitung um sein System zu überprüfen mit Powershell unter Windows 7 x64
http://www.planet3dnow.de/vbulletin...-Verifikation-Windows-7?p=5184706#post5184706

Oh ich sehe gerade, dass du den Teil für Linux in deiner News noch nicht stehen hattest:
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTI

Update: Linus Torvalds has now ended up pulling the latest PTI fixes that also include the change to disable page table isolation for now on all AMD CPUs. The commit is in mainline for Linux 4.15 along with a few basic fixes and ensuring PAGE_TABLE_ISOLATION is enabled by default.

Kernel developer Thomas Gleixner wrote in the pull request of disabling KPTI on AMD hardware, "Not necessarily a fix, but if AMD is so confident that they are not affected, then we should not burden users with the overhead."