Neue Side-Channel-Attacke betrifft alle Intel-CPUs mit Hyper-Threading (Update)

HWL News Bot

HWL News Bot

News
Thread Starter
Mitglied seit
06.03.2017
Beiträge
113.881
intel.jpg
Auf Spectre und Meltdown sowie die dazugehörigen Next-Gen-Ableger der besagten Side-Channel-Attacken folgt nun ZombieLoad. Der mögliche Angriffsvektor ist bei ZombieLoad ähnlich wie bei den anderen Lücken und betrifft alle Intel-Prozessoren ab 2011. Die achte und neunte Generation der Core-Prozessoren hingegen ist schon wieder per Hardware-Mitigation abgesichert.Das Microarchitectural Data Sampling (MDS) ist eine sogenannte spekulative Ausführung einer Side-Channel-Attacke, die es Angreifern möglich macht...

... weiterlesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Es betrifft also nur intels kleiner ix-7xxx mit ht?
Wie unterscheidet sich die neue Lücke von den bisherigen?

Klingt recht eingegrenzt.
Da stellt sich die Frage ob Intel die Lücke schon vor den 8xxx gekannt hat und Leistung höher bewertet hat als die Sicherheit der Kunden...
 
Dauert wahrscheinlich nicht mehr lange bis Intel empfiehlt HT ab zu schalten. /:
 
drakrochma schrieb:
Es betrifft also nur intels kleiner ix-7xxx mit ht?
Wie unterscheidet sich die neue Lücke von den bisherigen?

Klingt recht eingegrenzt.
Da stellt sich die Frage ob Intel die Lücke schon vor den 8xxx gekannt hat und Leistung höher bewertet hat als die Sicherheit der Kunden...
Zum Vergrößern anklicken....

Auf RIDL and Fallout: MDS attacks steht folgendes im FAQ:

"Our attacks affect all modern Intel CPUs in servers, desktops and laptops. This includes the latest 9th-generation processors, despite their in-silicon mitigations for Meltdown. Ironically, 9th-generation CPUs are more vulnerable to some of our attacks compared to older generation hardware."

Einige Attacken scheinen also auch die 8000er und 9000er Prozessoren zu betreffen.
 
Zitat aus der News:
Neben der Tatsache, dass die 8. und 9. Generation der Core-Prozessoren bereits in Hardware abgesichert sein soll, wäre das Schließen der Lücke per Microcode-Update auch für weitere Modelle möglich.
Zum Vergrößern anklicken....

Müsste das dann nicht angepasst werden?
Laut deinem Link sind die 9er dann ja nicht sicher, sondern noch unsicherer...
 
ZombieLoad? Hört sich nach einem Pornostreifen für ganze spezielle an.
 
google deaktiviert in chrome os bereits ht.

ein microcode update steht bereit, das 5-9% leistung kosten soll.

bye bye 9900K(elvin) cpu
 
Holzmann schrieb:
Laut denen hat Intel jetzt offiziell empfohlen HT zu deaktivieren
Zum Vergrößern anklicken....

Die schreiben dick und fett:
Intel Recommends Disabling Hyper Threading

Und dann im Fließtext steht:
Intel has also been publicly reluctant to agree with the disabling of HT when others have called for it with the discovery of some previous CPU flaws, but in its paper, the company stated that disabling HT altogether may be warranted as protection against MDS attacks.

Das passt nicht zusammen. Auf der Page von Intel steht gar nix von HT, kein Plan wo das her stammt... Oder gibts noch einen Link zu irgend einem Intel Paper? Nach einer Empfehlung klingt der Satz mir aber auch nicht...



PS: offenbar sind die Microcode Updates schon verfügbar und werden auch von Microsoft mit dem heutigen Patchday verteilt. Linux weis ich grad nicht, wenn dann dauerts aber auch nicht (mehr) lange.
Ansonsten ist vllt noch interessant was heise dazu schreibt -> die sagen, es braucht die neue Rev. von den 9000er CPUs für den Schutz. Den 9900k gibts wohl in zwei Versionen.
 
Zuletzt bearbeitet:
Das könnte Intel solangsam richtig in Bredouille bringen, insbesondere im Datacenter-Market. Hoffentlich rollt Intel schnell entsprechende Microcodes aus, deaktiviertes HT wäre schlimmer für die meisten Anwendungen als ein Patch der 6-9 % Leistung kostet.
 
Phantastisch. So schnell generiert man einen Bedarf an schnelleren CPUs... Wer alle Updates der letzten Monate installiert und auch noch HT abschaltet bekommt locker ein 30% langsameres System. Yeah.
Da diese Lücke eh nur große Ziele betrifft interessiert es mich weiterhin nicht, mein Win 7 bleibt auf dem Stand von 2014 :)
 
sch4kal schrieb:
Das könnte Intel solangsam richtig in Bredouille bringen, insbesondere im Datacenter-Market. Hoffentlich rollt Intel schnell entsprechende Microcodes aus, deaktiviertes HT wäre schlimmer für die meisten Anwendungen als ein Patch der 6-9 % Leistung kostet.
Zum Vergrößern anklicken....

VMSA-2019-0008
Update wird verteilt ;)


Zumindest in der Form hat Intel dazu gelernt, dass man am Veröffentlichungstag mit einer "Lösung" zur Schadensbegrenzung aufwarten kann...
 
Also daß HT HTT generell deaktiviert gehört, ist eigentlich nicht so neu.
 
HT hat ja mehr Lücken als ein Schweizer Käse, was für ein vergammeltes Stück Milch.
Langsam kann man glauben dass das Absicht ist...
 
Intel hat für die neue µArch hoffentlich eine komplett neue SMT-Implementierung entwickelt.
Wenn nicht, können sie die neue µArch auch gleich einstampfen bevor sie auf den Markt kommt...
 
Hi,
in dem Beitrag und den Links ist es doch schon sehr gut erklärt, HT wird über kurz oder lang geändert werden müssen.
Schaut man sich die Sache genauer an fragt man sich wirklich ob das nicht doch Absicht war und hier ab gewägt wurde zwischen Leistung und Sicherheit.
Alleine wenn ich mir anschaue wie schnell Intel jetzt auf einmal die patche hat befürchte ich das war noch nicht das ende dieses Problems, und wer denkt er
seit nicht betroffen eure Clouds arbeiten auch mit dieser Hardware, morgen wird das eine system langsamer übermorgen das andere und irgendwann fragt man
sich was eigentlich los ist...
lg
 
drakrochma schrieb:
Da stellt sich die Frage ob Intel die Lücke schon vor den 8xxx gekannt hat und Leistung höher bewertet hat als die Sicherheit der Kunden...
Zum Vergrößern anklicken....
Also würde eher davon ausgehen, dass diese Lücke Intel nicht vorab bekannt war, da die Entdecker sonst schon früher über sie berichtet hätten, sondern sie durch die Maßnahmen gegen die schon seit Anfang 2018 bekannten Lücken mit gestopft wurde.
sch4kal schrieb:
Das könnte Intel solangsam richtig in Bredouille bringen, insbesondere im Datacenter-Market.
Zum Vergrößern anklicken....
Es betrifft ja nur Virtualisierung bei der unkontrollierter Code auf den VMs läuft, also Mietserver die auf VMs laufen. Solange der Betreiber die VMs und die Software darauf selbst unter seiner Kontrolle hat, ist dies kein Problem.
sch4kal schrieb:
Hoffentlich rollt Intel schnell entsprechende Microcodes aus,
Zum Vergrößern anklicken....
Die sind schon draußen, dies geht bei Intel viel schneller als bei AMD: Spectre — AMD-Microcodeupdate-Chaos seit über einem Jahr (planet3dnow)

Hier das pdf mit dem Updatestatus am 14.05.2019 und hier auf Github die Intel-Linux-Processor-Microcode-Data-Files.
sch4kal schrieb:
deaktiviertes HT wäre schlimmer für die meisten Anwendungen als ein Patch der 6-9 % Leistung kostet.
Zum Vergrößern anklicken....
Wenn Du einen Server hast auf dem eine bestimmte Anwendung läuft, dann sind diese Sicherheitslücken komplett irrelevant, denn wenn es jemand schafft da Schadsoftware einzuschleusen um diese Lücken nutzen zu können, dann hat er sowieso schon Zugriff bekommen und kann auch direkt die Dinge abgreifen oder ausführen die er will, ohne dafür Sicherheitslücken zu brauchen. Gefahr besteht eben, wenn da VMs laufen auf denen unbekannte Nutzer alles machen können, also eben auch Software ausführen um Sicherheitslücken auszunutzen und so Zugriff auf Dinge außerhalb seiner VM zu bekommen.
 
Holt schrieb:
Also würde eher davon ausgehen, dass diese Lücke Intel nicht vorab bekannt war, da die Entdecker sonst schon früher über sie berichtet hätten, sondern sie durch die Maßnahmen gegen die schon seit Anfang 2018 bekannten Lücken mit gestopft wurde.
Zum Vergrößern anklicken....
Mir hat sich die Frage gestellt, weil eine neue cpu ja nicht von heute auf morgen fertig ist und, wenn es Änderungen am layout gab, der Grund für die Änderung ja schon vorher bekannt gewesen sein muss.
Also müsste intel doch mindestens sein der Planung der 8000er von der Schwachstelle wissen.
Und das dürfte schon ein paar Tage her sein...
 
Computerbase schreibt: "Es ist eine Mischung aus Meltdown und Spectre" und bei den neusten Revisionen hat Intel auch in Hardware Maßnahmen gegen diese schon über ein Jahr bekannten Lücken eingebaut, aber selbst wenn die Änderungen nur von Microcode kommen, so ist es durchaus möglich, dass sie eben auch diese neue Sicherheitslücke schließen, selbst wenn sie so noch gar nicht bekannt war.
 
Holt schrieb:
... Solange der Betreiber die VMs und die Software darauf selbst unter seiner Kontrolle hat, ist dies kein Problem ...
Zum Vergrößern anklicken....

Ich sehe das ähnlich, nur kann sich der Betreiber dann trotzdem nicht gegen die Updates schützen, welche die CPU Leistung reduzieren.
Weil Schutz- Ein/Aus Schalter hab ich bisher noch keine gefunden :-)

Oder ist das was bekannt in diese Richtung?
 
Holt schrieb:
Es betrifft ja nur Virtualisierung bei der unkontrollierter Code auf den VMs läuft, also Mietserver die auf VMs laufen. Solange der Betreiber die VMs und die Software darauf selbst unter seiner Kontrolle hat, ist dies kein Problem.
Zum Vergrößern anklicken....

Genau die Anbieter hatte ich mit meiner Ansicht gemeint, aber auch auf eigenen VMs mit bspw. Web-Apps kann es durchaus sein, das sich doch irgendwo eine XSS/CSRF-Lücke im Code eingeschlichen hat. Und dann werden die neuen Lücken nämlich zu einem sehr realen Problem. Ohne diese CPU-Lücken hätte man sich nämlich durchaus etwas schützen können (Stichwort RBAC/SELinux). Da hilft also als letztes Schutzmittel nur noch eine gut funktionierende WAF.

Holt schrieb:
Die sind schon draußen, dies geht bei Intel viel schneller als bei AMD: Spectre — AMD-Microcodeupdate-Chaos seit über einem Jahr (planet3dnow)
Zum Vergrößern anklicken....
Das ist löblich, war aber zu Anfangszeiten von Meltdown und Spectre auch bei Intel nicht so schnell verfügbar, obwohl die public disclosure Frist mW. sogar verlängert wurde und Intel damit schon viel früher in Kenntnis gesetzt wurde.

Holt schrieb:
Wenn Du einen Server hast auf dem eine bestimmte Anwendung läuft, dann sind diese Sicherheitslücken komplett irrelevant, denn wenn es jemand schafft da Schadsoftware einzuschleusen um diese Lücken nutzen zu können, dann hat er sowieso schon Zugriff bekommen und kann auch direkt die Dinge abgreifen oder ausführen die er will, ohne dafür Sicherheitslücken zu brauchen. Gefahr besteht eben, wenn da VMs laufen auf denen unbekannte Nutzer alles machen können, also eben auch Software ausführen um Sicherheitslücken auszunutzen und so Zugriff auf Dinge außerhalb seiner VM zu bekommen.
Zum Vergrößern anklicken....

S.o.
Das ließe sich mit SELinux recht gut abwehren (schon in der Praxis erlebt bzw. gibt auch einige Papers dazu), nur leider setzen viel zu wenig Betreiber von Web-Apps SELinux breitflächig und feingranular ein.

Fakt ist, Intel muss seine Sicherheitsanstrengungen verstärken und auch seine SMT-Strategie einfach neu evaluieren, so kann es ja nicht einfach immer weiter gehen.
 
Nicht auf jedem Server laufen Web-App Server, aber wenn man sowas hat, muss man da auch aufpassen was für Code ausgeführt wird (kann man die Exploits auch z.B. unter JAVA ausführen?) oder eben die Microscodes einspielen. Das auch bei Intel die Verteilung der Microcode Update eine gewisse Zeit gedauert hat, ist doch keine Entschuldigung dafür das bei AMD noch viel länger dauert.
 
Wir haben ein Update in der News erstellt, welches einige Fragen zu ZombieLoad, RIDL und Fallout klärt und auch auf die betroffenen Intel-Prozessoren eingeht. Außerdem gibt es zu Fallout erste Statements von AMD und ARM: Neue Side-Channel-Attacke betrifft alle Intel-CPUs mit Hyper-Threading (Update) - Hardwareluxx

Holt schrieb:
Nicht auf jedem Server laufen Web-App Server, aber wenn man sowas hat, muss man da auch aufpassen was für Code ausgeführt wird (kann man die Exploits auch z.B. unter JAVA ausführen?) oder eben die Microscodes einspielen.
Zum Vergrößern anklicken....

RIDL kann per JavaScript-Code im Browser ausgeführt werden.
 
Wenn man sicherstellen kann das auf den beiden logischen Prozessoren eines Kernes nur derselbe Kunde
läuft, kann Hyperthreading doch an bleiben... oder ?
 
Rollo3647, ja, denn die Lücken betreffen nur die beiden Threads auf dem gleichen physikalischen Kern. Man muss bei VMs dann aber auch aufpassen, dass wirklich keine Software eines anderen Kunden, also keine die man nicht kontrollieren kann, dann auf dem anderen Thread eines Kerns landet und dies ist schon eine deutliche Einschränkung. Andererseits hat jeder der wirklich sensible Dinge in der Cloud laufen lässt, eine geradezu kindliche Unbekümmertheit.
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh