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

Wer Anhänge aus unbekannten Quellen öffnet, ist noch immer selbst Schuld. Solche Anhänge tu ich meist aus Spaß eher mal auf einem Win98-Sys öffnen und schau mir genau an, was dort pasiert. Eine solche "Fake-Rechnung" hatte drin ein unkenntliches Bild, wo man zur Lesbarkeit zum Doppelklick drauf aufgefordert wurde. In Wirklichkeit war ein verschlüsselter, ausführbarer Code dahinter, der hauptsächlich bei Apple-Betriebssystemen (vermutlich iPhone) zum Installieren eines Updates aufforderte (was natürlich die Scheunentore öffnete)
 
Genaueres dazu warum AMD meint ihre Anfälligkeit für Spectre 2 wäre "near zero":
https://github.com/marcan/speculation-bugs/blob/master/README.md#amd-1

Und auch was ARM unter Variante 3a bezeichnet:
[h=3]AMD[/h]
Claims "near zero" risk for [BTI] but offers no proof. This suggests reliance on obscurity (AMD's branch predictor has not yet been reverse engineered). Assume vulnerable unless proven otherwise.
AMD CPUs are affected by [MISPREDICT] and not affected by [PRIV-LOAD].
TODO: Gentoo bug 643476 claims microcode update to disable branch prediction (entirely?) on family 17h (Zen) is available (SUSE notice). Performance impact unknown.
 
Was mir nicht gefällt, ist dieses "We / I believe" usw. aber das ist wohl eine Eigenheit. Wenn mir einer erzählt: dass er glaubt, dann ist diese Information fuer mich wertlos, weil ich fakten wissen will und nicht was irgendwer "glaubt".

Gruß,
skell.

Man kann "We believe that..." auch ganz gut als "Wir sind überzeugt, dass..." übersetzen. Vor allem bei Amerikanern ist da der Unterschied zwischen "Glauben" und "Überzeugt sein" viel kleiner als bei uns Deutschen.
 
Erinnert mich an eine jahrhunderte alte Definiton von "glauben". Bsp: Man steht in der Prärie an einer Eisenbahnschiene und sieht in der ferne dunkle Rauchwolken. Obwohl man den zugehörigen Zug nicht sieht, ist überzeugt davon, dass es ein Zug ist, der gleich vorbeikommen wird.
 
Dass jemand (oder mehrere jemands, das ändert ja nicht) Überzeugt ist, ist aber genau so wenig stichhaltig.

(Und ja, die Verwendung dieser Wortbausteine hat dort eine andere Bedeutung als die hier 1:1 übersetzte Version, ...)

Sie sagt aber nicht: We are not vulnearable.
Sondern sie sagt etwas in der Richtung: We strongly believe (that) we are not.... was gleichbedeutend ist mit: vielleicht sind wirs doch.

Ich als Moderator würde da aber bei solchem "wischiwaschi" sowas von nachhaken - auch wenn ich ebenfalls denke, dass Sie als CEO (und damit weit weg von tiefer fachlicher Einsicht) in dem Interview eine recht gute Figur macht und informiert wirkt. - Vor allem bei den Fragen ala: "Haben Sie das extra so designed?" hätte sie der Suggestion ja folgen koennen und das bejaen, was sie aber nicht getan hat, weil Sie weiss, dass das Design von vielen Faktoren abhängt und es eher eine Folge von Designentscheidungen war, die AMD offenbar weniger anfällig machen.

Gruß,
skell.
 
In diesem Kontext kann man das übersetzten mit "Wir sind der Ansicht" - das muss auch so formuliert werden von Führungskräften bei Aktiengesellschaften, da niemand irgendetwas mit 100% Sicherheit Wissen kann. Es sind Ansichten von Unternehmen, während Sicherheitsforscher, Analysten und Konkurrenten völlig andere Ansichten haben können. Keiner weiß welche anderen Exploit noch auf der selben Basis auftauchen werden, so wie das eigentlich bei allen Lücken ist.

--- Update ---

https://www.heise.de/newsticker/mel...ffen-wie-kann-ich-mich-schuetzen-3938146.html
Die CPU-Sicherheitslücken Meltdown und Spectre
Google-Name Kurzbezeichung CVE-Nummer Betroffene Prozessoren
Intel AMD ARM¹ IBM POWER
Spectre, Variante 1 Bounds Check Bypass CVE-2017-5753X
X
X
X
Spectre, Variante 2 Branch Target Injection CVE-2017-5715X

XX
Meltdown Rogue Data Cache Load CVE-2017-5754X



¹ betroffen sind Cortex-A8, -A9, -A15, -A17, -A57, -A72, -A73, -A57, -R7, -R8, nicht der Cortex-A53 im Raspi

<tbody>
</tbody>
 
Cool, dann sind mein Samsung S7 und Tab S2 beide nicht betroffen (beide A53 wie beim Raspberry Pi).
 
Nun, Intel hätte nicht warten müssen, das Feature deaktivieren wie AMD beim Phenom und gut ist, alles andere ist ein wirtschaftlicher Vorteil.
Das Frontend von einer CPU mit Milliarden Transistoren kann man eben nicht so einfach patchen sonst bräuchten wir keine Softwareupdates...

Und ja das würde mal den Finanzwuzzis in den Unternehmen zeigen das die Produktvalidierung kein Budgetposten sein darf, an dem man sparen kann. Vorallem da es bekannt war das es möglich ist das sich OoO Prozessoren fehlerhaftes verhalten bei nicht aktivem Vorbeugen ermöglichen.
100% signed.

Reine Spekulation.

Ich als Moderator würde da aber bei solchem "wischiwaschi" sowas von nachhaken - auch wenn ich ebenfalls denke, dass Sie als CEO (und damit weit weg von tiefer fachlicher Einsicht) in dem Interview eine recht gute Figur macht und informiert wirkt.
Du meinst diese Lisa Su?

Zitat: "She graduated with her PhD in electrical engineering[4][9] from MIT in 1994. [...] During her time at IBM,[4] Su played a "critical role"[5] in developing the "recipe"[2] to make copper connections work with semiconductor chips instead of aluminum, "solving the problem of preventing copper impurities from contaminating the devices during production". [...] Su joined Freescale Semiconductor in June 2007[10][18] as chief technology officer (CTO), heading the company's research and development[3][9] until August 2009. [...] As of 2016 she has published over 40 technical articles,[9] and she also co-wrote a book chapter on next-generation consumer electronics."

Was meinst du, warum es bei AMD wieder aufwärts geht? :D

Vor allem bei den Fragen ala: "Haben Sie das extra so designed?" hätte sie der Suggestion ja folgen koennen und das bejaen, was sie aber nicht getan hat, weil Sie weiss, dass das Design von vielen Faktoren abhängt und es eher eine Folge von Designentscheidungen war, die AMD offenbar weniger anfällig machen.
Das darf sie niemals mit "ja" beantworten, weil wenn in Zukunft jemand jemals wegen irgendwas in Verbindung mit Kerndesign gegen AMD (=USA) klagt könnte derjenige diese Aussage verwenden.
 
Reine Spekulation.
Ja. Dennoch fundiert und interessant als These. Mal sehen ob jemand bei ersten SMT Tests nach den Patches mit CPUs dies betätigen kann. SMT sollte ja dann bei CPUs die am meisten Performance verlieren auch am meisten wieder bringen.
 
Cool, dann sind mein Samsung S7 und Tab S2 beide nicht betroffen (beide A53 wie beim Raspberry Pi).

Das S7 hat doch eine kombinierte CPU nach dem Big-Little-Prinzip, also zur Hälfte die zur Entwicklungszeit für die Geräteklasse leistungsstärksten und zur anderen Hälfte sehr energieeffiziente Kerne.
Nur die 'kleinen Kerne' werden wohl Cortex-A53 Varianten sein.

Mich widert die allgemeine Informationslage und die gezielte Dessinformation seitens des hoffentlich bald inhaftierten Intel CEOs und des ehemaligen NSA System Intruders mit Job im Weißen Haus massiv an.
 
Das S7 hat doch eine kombinierte CPU nach dem Big-Little-Prinzip, also zur Hälfte die zur Entwicklungszeit für die Geräteklasse leistungsstärksten und zur anderen Hälfte sehr energieeffiziente Kerne.
Nur die 'kleinen Kerne' werden wohl Cortex-A53 Varianten sein.
Das S6 hat A57 und A53.
Das S7
 
Intel scheint seine Microcode Updates zu Spectre 2 zurück gezogen zu haben wegen Problemen bei vielen Systemen. Infos darüber gibt es bei Lenovo:
https://www.theregister.co.uk/2018/...ctre_fixes_make_broadwells_haswells_unstable/
https://support.lenovo.com/de/de/solutions/len-18282
The following guidance is specific to Lenovo Personal Computing (PCSD) offerings.
Withdrawn CPU Microcode Updates: Intel provides to Lenovo the CPU microcode updates required to address Variant 2, which Lenovo then incorporates into BIOS/UEFI firmware. Intel recently notified Lenovo of quality issues in two of these microcode updates, and concerns about one more. These are marked in the product tables with “Earlier update X withdrawn by Intel” and a footnote reference to one of the following:
*1 – (Kaby Lake U/Y, U23e, H/S/X) Symptom: Intermittent system hang during system sleep (S3) cycling. If you have already applied the firmware update and experience hangs during sleep/wake, please flash back to the previous BIOS/UEFI level, or disable sleep (S3) mode on your system; and then apply the improved update when it becomes available. If you have not already applied the update, please wait until the improved firmware level is available.
*2 – (Broadwell E) Symptom: Intermittent blue screen during system restart. If you have already applied the update, Intel suggests continuing to use the firmware level until an improved one is available. If you have not applied the update, please wait until the improved firmware level is available.
*3 – (Broadwell E, H, U/Y; Haswell standard, Core Extreme, ULT) Symptom: Intel has received reports of unexpected page faults, which they are currently investigating. Out of an abundance of caution, Intel requested Lenovo to stop distributing this firmware.
 
Auf Golem heute ein recht ausführlicher Artikel zu dem Thema: https://www.golem.de/news/updates-wie-man-spectre-und-meltdown-loswird-1801-132125.html

Zum Performance-Verlust (Seite 3):
Bis zu 30 Prozent langsamer sollten die Chips künftig rechnen. Erst Benchmarks zeigen: So dramatisch wird es für die meisten Anwender nicht. Allerdings gilt für Windows-Nutzer, dass die Auswirkungen der Patches auf die Performance steigen, je älter der Chip und die verwendete Windows-Version ist.

Wer also einen Haswell-Prozessor unter Windows 7 nutzt, der soll nach Angaben von Microsofts Windows-Chef Terry Myerson durchaus "spürbare" Performanceverluste haben, wohingegen die Auswirkungen im normalen Einsatz bei Core-i-Chips der aktuellen Serien im Zusammenspiel mit Windows 10 im Alltagsbetrieb nicht spürbar sein sollen. Der Performanceverlust soll in diesem Fall "im einstelligen Prozentbereich" liegen.
(...)
Intel selbst hat ebenfalls Benchmarks durchgeführt. So soll der Performance-Verlust bei CPUs der achten und siebten Core-i-Generation bei Office-Benchmarks wie SYSMark2014SE bei rund sechs Prozent liegen, bei CPUs der sechsten Generation mit acht Prozent schon etwas höher.
Verdammt! Das sieht also nicht gut aus für meinen i7-4790K in meinem Gaming Rechner mit Windows 7 :] Pfff...für Intel ist sechste Generation schon alter Kram, alles darunter wird nichtmal genannt. Bislang gab es eigentlich nichtmal für i-Prozessoren der vierten oder fünften Generation irgendeinen Grund, sie zu ersetzen. Und wenn ich das jetzt so lese, kann ich mich ja mal auf schätzungsweise 20% Performance-Verlust oder mehr einstellen :]

das heißt, es muss ein neuer Rechner her. Ist denn inzwischen bekannt, inwieweit die neuen AMD Zen Prozessoren (die ja imho im April kommen sollen), von den drei Sicherheitslücken betroffen sind oder nicht?
 
Zuletzt bearbeitet:
Allerdings gilt für Windows-Nutzer, dass die Auswirkungen der Patches auf die Performance steigen, je älter der Chip und die verwendete Windows-Version ist.
Wobei Intel zumindest den Zusammenhang mit dem Alter des Betriebssystems nicht bestätigen kann:

Intel hat derweil Benchmarkwerte (PDF) der zu erwartenden Leistungseinbußen je nach CPU-Generation und Betriebssystem veröffentlicht. Die gemessenen Werte widersprechen Microsofts Behauptung, dass Windows 7 und 8 mehr unter den Gegenmaßnahmen leiden würden als Windows 10 – allerdings ist Skylake (2015) die älteste von Intel in den Benchmarks berücksichtigte CPU-Generation.
https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/#update15

MS hört wohl nicht auf, einem Win7 madig machen zu wollen *noahnung*

Gruß,
Ritschie
 
Hmm ok, immerhin scheint die Spiele-Performance deutlich weniger betroffen zu sein, als Office-/ Datenbank-Performance, falls die Intel Benchmarks repräsentativ sind.
 
Auf Golem heute ein recht ausführlicher Artikel zu dem Thema: https://www.golem.de/news/updates-wie-man-spectre-und-meltdown-loswird-1801-132125.html

Zum Performance-Verlust (Seite 3):

Verdammt! Das sieht also nicht gut aus für meinen i7-4790K in meinem Gaming Rechner mit Windows 7 :] Pfff...für Intel ist sechste Generation schon alter Kram, alles darunter wird nichtmal genannt. Bislang gab es eigentlich nichtmal für i-Prozessoren der vierten oder fünften Generation irgendeinen Grund, sie zu ersetzen. Und wenn ich das jetzt so lese, kann ich mich ja mal auf schätzungsweise 20% Performance-Verlust oder mehr einstellen :]

das heißt, es muss ein neuer Rechner her. Ist denn inzwischen bekannt, inwieweit die neuen AMD Zen Prozessoren (die ja imho im April kommen sollen), von den drei Sicherheitslücken betroffen sind oder nicht?

Das dürfte meinem gerade gebraucht erworbenen Dell Venue 11 Pro 7140 mit Intel Core M-5Y10a Broadwell von 2014 auch nicht so gut gefallen. Die Dinger sind zwar flott, aber sooo üppig sind die Reserven auch nicht.

Wobei die Formulierung da oben auch extra so gewählt sein könnte um die Leute in Richtung aktuellerer Geräte und Windows 10 zu treiben, oder?



Zu meiner eigentlichen Frage: Was passiert eigentlich wenn man mit installiertem KB4056894 die Virensoftware wechselt? Der Patch wird ja ohne kompatible Virenlösung nicht angeboten. Dann aktualisiert man den Scanner, patcht Windows und es ist gut. Aber wenn man die Virensoftware entfernt? Ist ein Wechsel auf eine andere Lösung sicher?
 
Ein Anbieter von AV-Software, der jetzt noch mit dem Patch nicht kompatibel wäre, kann ohnehin zumachen.
 
Sind AMD ältere CPUs wie der Brisbane betroffen?
 
Thanks

Gibt wohl noch keine Lösung, aber wohl auch kein erhöhtes Sicherheitsrisiko
 
Hier das ist evtl. noch recht interessant in dem Kontext:
https://medium.com/@mattklein123/meltdown-spectre-explained-6bc8634cc0c2
Und davon abgeleitet der Link zur Side-Channel Mitigation Analyse von Intel via IBRS und STIBP und IBPB.
Interessant das Statement von Matt Klein dass auf Skylake und neueren Architekturen das IBRS wohl zusätzlich zum Retpoline aktiviert werden muss da auf diesen Archs Retpoline umgangen werden kann (was wiederum mehr Performance kosten würde als auf den älteren... Der versierte leser mag sich selbst die Passage durchlesen und meine Ansicht ggf. korrigieren.

Er schätzt zudem den Impact der Meltdown-Patches in syscall anfälligen Operation auf 5-30%. Was, da ja Intel-only, schon echt ne Hausnummer ist !
EDIT: Sorry die Schätzung mit den 5-30% stammt von hier: https://lwn.net/Articles/742702/
The answer here is kernel page-table isolation, making the kernel-space data completely invisible to user space so that it cannot be used in speculative execution. This is the only one of the three issues that is addressed by page-table isolation; it alone imposes a performance cost of 5-30% or so.

--- Update ---

Btw. @Complicated:
Dieser Poster hier beschreibt eine Interessante Idee die sich meines erachtens nach mit dem Ars-Technica Artikel zur "Resistenz" der AMD Architekturen vs. Spectre 2 deckt:
https://lwn.net/Articles/742904/
To be vulnerable to branch predictor abuse, you need to be able to train the predictor. If you (correctly) index your predictor using all of the bits of the VA, as opposed to the low order bits, you remove the most obvious route of attack.

Wenn ich das richtig übersetzte sagt er dass man den predictor nicht (effektiv) trainieren kann wenn man vollständige Adresspräzision verwendet ?

Weiter schreibt er dann:
https://lwn.net/Articles/743093/
Nah, it's VA+ASID/PCID. It's actually very simple to have a branch predictor that is safe against variant 2. You just need to have your index completely disambiguate against other live contexts. The only problem with this is it's more bits to compare, but as compared to not having any branch prediction within one of the contexts, or flushing the predictor
Und weiter https://lwn.net/Articles/742968/
ndeed, but as I said elsewhere in the thread, you can mitigate branch predictor abuse if you correctly index your predictor based upon the full address space (including ASID/PCID/etc.). The hardware fix for variant 2 isn't actually as bad as people claim.

Übrigens seine Qualifikation beschreibt er so: https://lwn.net/Articles/743094/
I co-lead the mitigation team within Red Hat for some time on this issue.
 
Zuletzt bearbeitet:
Ja so wie ich es schon vor 4 Tagen in dem Thread von errate ausgeführt hatte. Das deckt sich.
Wenn die Adresse komplett gefüllt ist kann man halt auch nichts mehr aus der Prediction an die eigene Adresse anhängen. Intel speichert in der prediction halt nur Teilbereiche der Adresse. Das kann Performancegründe haben, weil dadurch die Instruktionen in kleinere Happen unterteilt sind und eher ein Hit im Cache stattfindet. Wenn der gesamte Teil der prediction genommen werden muss ist die Hitrate halt geringer bei Abweichungen. Daher wird Intel wohl auch in jedem Fall größere Performanceeinbußen haben durch die Patches.

Das flattening ist ein Problem für alle Sidechannel-Angriffe, da werden noch einige Exploit in diesem Stil kommen vermute ich. Bisher sind wohl auch keine 100% Lösungen für Intel vorhanden ausser dem kompletten ausschalten der branch prediction mit enormen Performanceverlusten. Und eben Hardwareänderungen. Nur man muss sich mal überlegen dass dies zwischen 2-4 Jahre dauern kann bis es diese Änderungen in Hardware zu kaufen gibt. Und das ausgerechnet jetzt wo man vor der Einführung von EUV steht, das sowieso als schwieriger Fertigungsprozess gilt. Ausgerechnet jetzt soll man das alles schnell schnell machen.

--- Update ---


Ja und hier weiss man nicht ob der eine überhaupt ausgelesene werden kann, da er ja schon komplett ist und mit +m größer als eine gültige Adresse wird. Ich denke da kommt das "near" her, weil man das derzeit noch genau anschaut ob der eine irgendwie dennoch zufällig erwischt werden kann indem m keine Größe hat. Eben mit m=NULL => m+Speicher=m. Hier ist die Frage ob der Inhalt dann in die neue Speicheradresse transferiert wird und mit den "m"-Rechten Zugriff darauf erfolgt oder ob daraus einfach keine Änderung erfolgt. Ich denke das zweite sollte der Fall sein, da es sonst ein hirnrissiges Konzept wäre, wenn man Inhalte aus dem Speicher einfach durch 1:1 kopieren auf eine vom Hacker kontrollierte Variable preisgeben würde.
 
Es gibt schon ein paar Benches für AMD und Intel unter Linux 4.15 mit aktuellen Patches.

Kurz und knapp: AMD CPUs juckt es gar nicht (ausgenommen Threadripper, Infinity Fabric Problem?) und werden sogar geringfügig schneller, Intel hat dagegen teils ordentliche Probleme.
 
Zurück
Oben Unten