News TAA/MDS/RIDL_NG: Intel bestätigt 77 neue Sicherheitslücken und Fehler

[Iscaran]

Es gibt von den MDS/Zombieload "devs" ein nettes Tool das man anstelle der PowerShell Skripterei wohl einsetzen kann um den Patch-Status des Systems zu checken:

https://mdsattacks.com/images/mdstool.png
https://mdsattacks.com/files/mdstool-win-20190519.zip

 

[flmr]

Mich wuerde mal die Performance von einem einigermassen simplen CPU Design ohne speculative execution interessieren

 

[pipip]

Bei AMD sind grundlegende Mechaniken in der Architektur verankert, die zwar Performance kosten, aber für Sicherheit sorgen.

Die Sache bei AMD ist, sie müssen mit Sorgfalt arbeiten, da sie kein Geld für Gerichte und Werbekampangen haben. Das sieht man schon damals bei Phenom I Bug. Dieser Bug wurde mit einer Revision plus Performance Verlust nachgeschoben, obwohl es bei Privatanwender im Laufe eines Monats vllt mal zu einem Bluescreen hätte führen können . Klar für Server dann eine komplett andere Dimension.
Zeigt sich aber wieder der Vorteil aktueller Zen Chiplet. Hat ein Design einen Fehler, betrifft es zwar alle Produkte, kann aber folglich auch für alle ausgebessert werden, wahrend beim Monolith Design jedes Design extra angegriffen werden muss.
Somit klar, Intel wird es vllt versuchen so gut wie möglich bis nächster Architektur, die man ja scheinbar dann sowieso neu aufziehen muss, zu bereinigen und falls man dann auch auf Chiplet setzt, hat man auch so viele Fliegen mit einer Klatsche geschlagen. So kann der 10nm Prozess auch ruhig warten.
Alter Wein wird meist besser. Hier verkocht man scheinbar alles und schenkt bald frisch ein.

 

[Lübke]

Genau das ist der eigentliche Punkt.

Ja, es gibt diese Sicherheitslücken, so wie die vorangegangenen auch ...

Aber man sollte gleichzeitig betrachten, wie wahrscheinlich solch ein Angriffsszenario ist.
Das Thema wird mE etwas polemisiert. Es gibt kein einziges technisches Produkt, dass völlig frei von fehlern ist. Seien es bspw. falsch dimensionierte PCB's wenn es um Hardware geht oder eben um fehlerhaften Code. Natürlich fallen solche sachen nicht direkt auf. Gleichzeitig passiert es schnell, dass ein fix erst neue Türen öffnet.

Man sollte nicht schauen, "oh, dass sind aber viele Fehler"

sondern

"Was habe ich genau durch solche Fehler zu erwarten" "Betrifft mich das überhaupt?"


Und genau hier können sich völlig unterschiedliche Szenarien auftuen.

ich sehe das etwas differenzierter, denn dazu muss man nicht nur die fehler selbst kennen, sondern auch die kreativität und die motivation von angreifern bewerten, was schwierig sein dürfte. mit der herausforderung wächst auch die motivation. nach dem motto "einfach kann ja jeder". ein angriff muss ja nicht zwangsläufig nur eine einzelne lücke nutzen, auch aus der kombination unterschiedlicher kleiner lücken können sich neue möglichkeiten ergeben...
soll heißen, ich sehe schon grund, das ganze ernst zu nehmen, selbst wenn der nutzen dieser lücken noch nicht offensichtlich ist. dass sie existieren ist jedenfalls sicher und dass es menschen gibt, die sowas als herausforderung betrachten wohl auch.

 

[Häschen]

einsetzen kann um den Patch-Status des Systems zu checken:

 

[Lübke]

Nicht, wenn ihnen jetzt der Mist (hoffentlich) um die Ohren fliegt. Dann wird es teuer. Zudem: sollten große Cloud Betreiber auf die Idee kommen Intel zu verklagen wird es ernst. Sie verkaufen ja bewusst die gleichen Fehler seit vielen Jahren, ob aus Leistungsgründen oder (falsch berechneter) Wirtschaftlichkeit ist dem Gericht dann auch egal.
@aldaric spricht sogar von 2005, ich war bei 2011, habe auch keine Lust zu googeln, ich behaupte daher, aldaric liegt richtig (ewig her, als ich diese Info gelesen habe)

wie groß müsste der schaden für intel wohl sein, um ihre profite seit 2011 bzw 2005 aufzuzähren + der erforderlichen entwicklungskosten für eine vollkommen neue architektur, als dass es sich nicht gelohnt hätte? glaub mir, der kleine skandal jetzt ist verschwindend gering dagegen. aus betriebswirtschaftlicher sicht hat das mit sicherheit gepasst. und intel ist wie auch amd, nvidia und andere ein gewinnorientiertes unternehmen, was die meisten hier vergessen. da stecken keine bösen absichten dahinter sondern rein wirtschaftliches handeln.

 

[Banned]

Mir kann jedenfalls keiner erzählen, dass die Intel Ingenieure zu blöd dazu waren zu erkennen, dass Code Ausführung ohne auf Rechteprivilegien zu achten keine gute Idee ist.

Was du sagst, klingt in Teilen durchaus schlüssig.

Aber warum hat man die Lücke (von Angreiferseite) erst so spät erkannt, wenn das Ganze doch deiner Meinung nach so einfach zu durchschauen ist? Das hätte doch dann für potentielle Angreifer leicht zu erkennen sein müssen. War es aber viele Jahre nicht.

Aus dem Linux-Bereich gab es auch keinen Aufschrei die ganzen Jahre von wegen HT deaktivieren.

 

[highsociety]

Habe mir jetzt nicht alle 17 Seiten durchgelesen, bin aber von den Benchmarks schon schockiert.
Kann man schadensersatz fordern?
Hab den i7 8700K Februar diesen Jahres gekauft.
Finde es lächerlich wie viel Leistung hier verloren geht, das ist etwas, was man als Verbraucher nicht akzeptieren sollte.

 

[Iscaran]

Schaut bei mir auf dem Arbeitslaptop nicht soviel anders aus - obwohl ich hier ziemlich sicher ALLE Mitigation (bis auf HT-Aus) aktiviert/installiert habe, die für das Ding verfügbar sind :-).

 

[lars1900]

Ist ja schön, dass Sie sich freuen diese Lücken selbst zu finden. Ich freue mich auch, da meine CPU auch davon betroffen ist. Aber das bekannte Fehler die angeblich gelöst wurden wieder auftauchen, finde ich bedenklich.

das Problem wurde nie gelöst. SMT ist einfach grottig umgesetzt. Das ist so wie wenn du einen Schwamm in einen Feuerwehrschlauch stopfst und dann versuchst den Schwamm mit Superkleber abzudichten - wenn du die 50 großen Löcher zugeklebt hast, dann kommt es halt aus den kleinen raus. Und ihrgendwann hast du am ende vom Schlauch 3m³ Kleber hängen, aber es tropft immernoch. Das Design an sich ist fehlerhaft und die Anzahl der potenziellen Bugs praktisch unendlich.
Ich halte die Leute von FreeBSD für paranoide Spinner, aber sie haben echt Ahnung von der Materie. Und deren Aussage: deaktiviert SMT oder ihr seit für alle Zeiten ein offenes Scheunentor. Aber SMT deaktivieren heißt halt auch, je nach Anwendung, bis zu 50% Performanceverlust. Das kann Intel niemals zugeben. Also bestellen sie nen ganzen Güterzug Superkleber und hoffen das beste.

 

[Lübke]

Aber warum hat man die Lücke (von Angreiferseite) erst so spät erkannt, wenn das Ganze doch deiner Meinung nach so einfach zu durchschauen ist? Das hätte doch dann für potentielle Angreifer leicht zu erkennen sein müssen. War es aber viele Jahre nicht.

woher willst du das wissen? du weist doch gar nicht ob diese lücken nicht schon lange in gebrauch sind. das werden die angreifer dir sicher nicht auf die nase binden.

Aus dem Linux-Bereich gab es auch keinen Aufschrei die ganzen Jahre von wegen HT deaktivieren.

so wie ich gelesen habe, gabs den vor einiger zeit von glaub free-bsd seite durchaus. und war das nicht eine linux-distri, die smt automatisch deaktiviert, ohne die nutzer zu fragen oder zu informieren? aber die wenigsten haben bislang erkannt, wie schwerwiegend diese probleme tatsächlich sind. und ich vermute dass auch intel sich der schwere des problems nicht bewusst war. die meisten, die sowas untersuchen stehen vermutlich auf der seite der angreifer, seien es staatliche oder kriminelle hacker. wer weiß was die schon alles wie lange wussten und ggf. sogar schon nutzen?

 

[textract]

Es ist eher erschreckend, dass selbst RZ Betreiber trotz anhaltender und größer werdender Probleme mit Intel CPUs an Intel festhalten.

AMD sieht man aus dubiosen Imagegründen fast gar nicht und IBM sei angeblich zu teuer.
Dass POWER CPUs im Schnitt natürlich auch ein Vielfaches an Leistung bringen und dabei keinen Honeypot darstellen interessiert diejenigen, die Entscheidungen treffen natürlich auch nicht.

 

[Banned]

woher willst du das wissen? du weist doch gar nicht ob diese lücken nicht schon lange in gebrauch sind. das werden die angreifer dir sicher nicht auf die nase binden.

Bisher gab es m.W. genau 0 erfolgreiche "exploits in the wild".

Ich weiß natürlich nicht, ob irgendein Hacker in Russland oder sonst irgendwo in seinem dunklen Kämmerchen nicht schon 2012 drauf gestoßen ist und es dann in Anbetracht der extrem geringen Erfolgsaussicht aufgegeben hat. Stimme, da gebe ich dir recht.

 

[Müritzer]

Ich lese hier immer wieder:

„Mich als Privatperson betrifft das nicht.“

So gut wie alle Behörden, Verwaltungen und sonstige Betriebe und Institutionen benutzen Intel Systeme. Ist man auch als Privatperson sicher wenn es dort zu einem Hackerangriff kommt?

Dort könnten dann persönliche Daten abgeschöpft werden und man kann Probleme bekommen.
Nur ein Beispiel ist die Energieversorgung in Deutschland und Europa, wenn da was passiert betrifft mich das als Privatperson ja nicht. Ist ja nicht mein PC.

https://www.rbb-online.de/kontraste...-2019/hacker-greifen-energieversorger-an.html

Oh ich vergaß, ich kann meinen PC ja nicht mehr benutzen bei einem Stromausfall.

Wie sicher sind nach den neuen Sicherheitslücken, es wurden wahrscheinlich nicht alle öffentlich kommuniziert, weil noch mit „Embargo“ belegt, die Kraftwerke.

https://www.zeit.de/digital/interne...riff-kraftwerke-lebensgefahr-stuxnet-sabotage

Und es gibt noch mehr Beispiele dafür. Wer solche Lücken ausnutzen will oder schon dabei ist und was schlechtes im Sinn hat wird das nicht an Intel mitteilen. Gibt es nachweislich einen erfolgreichen Angriff und es wird danach festgestellt eine Intel Sicherheitslücke ist dafür verantwortlich, na dann gute Nacht Marie.

Es geht hier nicht nur um den heimischen PC, das ist ja das was einem zum Nachdenken anregen sollte.

 

[Ned Flanders]

Aber warum hat man

Rein spekulativ braucht es halt jemand der das ganze systematisch und mit viel know how angeht und den ersten Toolkit schreibt. Brauchst also erstmal jemanden der so ne Gruppe ein paar Jahre finanziert. Das erste Paper kam von der Uni Graz, mitfinanziert von Google PZ. Nachdem das raus war brechen natürlich die Dämme.

Also ist Google schuld

 

[Zero_Point]

Intels SMT Problem war ja schon zu P4 zeiten bekannt, link ist ein paar Seiten vorher in dem Thread.

Und der Rest?

 

[Alphanerd]

wie groß müsste der schaden für intel wohl sein, um ihre profite seit 2011 bzw 2005 aufzuzähren + der erforderlichen entwicklungskosten für eine vollkommen neue architektur, als dass es sich nicht gelohnt hätte?

1-2 Zivilklagen in USA können da schon reichen. AWS oder Azure: die HW Kosten plus die Arbeitszeit plus die evtl Downtime (ich glaube hier redet man von tausenden USD pro 0,1 Sekunden) jeweils entschädigt zu bekommen frisst dann auch Intels Spardose auf. Dann hat man weniger geld für die OEM "Rabatte" und dann geht es schnell.

Wer sagt, dass Controller immer richtig rechnen, bzw unwägbare Risiken einschätzen können? Siehe VW.

was die meisten hier vergessen. da stecken keine bösen absichten dahinter sondern rein wirtschaftliches handeln

Da stimme ich zu 100% zu.

 

[Lübke]

Bisher gab es m.W. genau 0 erfolgreiche "exploits in the wild".

dass noch keiner nachgewiesen wurde, bedeutet nicht, dass es sie nicht gab, sondern nur dass noch keiner erwischt wurde.
wie war das denn z. b. mit https? wurde offenbar über viele jahre exzessiv ausgenutzt bevor es erkannt wurde. aber bis dahin war kein angriff bekannt, sonst wäre das problem viel früher erkannt und behoben worden.

kann sein dass die lücken noch ungenutzt sind, aber anders als in den anfängen der hacker-scene wollen hacker ja gar nicht mehr bemerkt werden und keinen schaden machen, sie wollen klammheimlich auf systeme zugreifen und unbemerkt wieder verschwinden. im idealfall wird das nie einer bemerken.

 

[TSKNF]

glückwunsch

 

[Benji18]

Mir kann jedenfalls keiner erzählen, dass die Intel Ingenieure zu blöd dazu waren zu erkennen, dass Code Ausführung ohne auf Rechteprivilegien zu achten keine gute Idee ist.

darauf kannst du wetten, das wird wie beim "Dieselskandal" Wirtschaftliche Interessen gewesen sein, damals mit P4 war AMD schneller, man wird wohl eine Anweisung ala "macht die CPU schneller als die Konkurenz" ausgegeben haben und damit wurden gewisse Architekturänderung durchgeführt die letzten endes die Sicherheit geschwächt haben.