TakeAway-Sicherheitslücke in AMD-CPUs seit 2011

fortunes

Legende
Thread Starter
Mitglied seit
13.06.2003
Beiträge
13.498
Ort
RheinMain

Take Away Paper schrieb:
The key takeaway of this paper is that AMD’s cache way predictorsleak secret information. To understand the implementation details,we reverse engineered AMD’s L1D cache way predictor, leadingto two novel side-channel attack techniques. First, Collide+Probeallows monitoring memory accesses on the current logical core without the knowledge of physical addresses or shared memory. Second, Load+Reload obtains accurate memory-access traces of applications co-located on the same physical core.
Der Angriff ist auf den einen logischen bzw. physischen Kern beschränkt.

Es dürfte daher eines Software-/UEFI-Patches genügen, um die Zugriffe auf den logischen bzw. physikalischen Kern zu "kontrollieren". Dadurch sollten die Angriffe unterbunden werden können.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Das ist natürlich eine sehr ungemütliche Nachricht, das passt mir jetzt so gar nicht in den Kram.
Man müsste also bis zum Athlon XP zurück um sicher zu sein, nicht gut. :oops:

Man kann nur hoffen, dass es per Microcode gefixt werden kann.
 
Würde dein Athlon XP noch in einer höheren Stückzahl auf dem Markt vorhanden sein bzw.wäre es interessant genug, würde man bestimmt auch auf Athlon XP CPU Lücken finden. Wie schon in anderen Threads dazu geschrieben, sobald Angriffe/Suche nach Lücken lukrativ werden, ist kein System sicher.
 
First, Collide+Probeallows monitoring memory accesses on the current logical core without the knowledge of physical addresses or shared memory. Second, Load+Reload obtains accurate memory-access traces of applications co-located on the same physical core.
Also der erste Seitenhieb zeigt die Speicherzugriffe aber ohne wissen welcher Adressbereich Physikalisch als auch Virtuell.
Der zweite Seitenhieb ermöglicht dann den auch die genau Adresse, wenn das Programm sich noch auf dem selben Kern befindet,

Bedeute das nun, dass der Windows Sheduler durch das Weiterreichen in gewissem Maße diese Lücke umgeht?
rofl
 
Mal sehen, was AMD dazu sagt.

In dem Papier wird ein Spectre-Angriff erfolgreich durchgeführt - es steht aber nicht geschrieben, ob der Angriff auf den L1-Cache-Bereich dieses einen logischen/physikalischen Threads beschränkt bleibt.

Wenn die Beschränkung je Kern/Thread bestehen bleibt, ist der Fehler zwar gravierend, aber die Ausmaße überschaubar. Gerade im Cloud-Bereich werden Cores/Threads vermietet. So lange die gleichen Cores/Threads zugewiesen bleiben, kann da nix passieren.
Beitrag automatisch zusammengeführt:

Übrigens sehr interessant, dass diese News von einem Intel-Team zeitgleich an dem Tag publik gemacht wird, wo auch Intels neues ME-"Problem" bekannt wird.

Ablenkungsmanöver und Lügen kennen wir ja von Intel zur Genüge.
 
Zuletzt bearbeitet:
Blah blah, Intel team.
Geh mal dir eine Ecke zum weinen suchen einseitiges irgendetwas,...
 
Das Team, das diese Lücke gefunden hat, hat auch viele Probleme in Intel-Prozessoren aufgedeckt.
 
Das Team, das diese Lücke (und viele weitere bei Intel) entdeckt hat, wird von Intel bezahlt.
 
Ok, damit wird die Wahl zwischen Intel und AMD zwar nicht zur Wahl zwischen Pest und Cholera aber zur Wahl zwischen Pest und Husten...

Dass keine CPU frei von Fehlern ist, war ja eigentlich klar.

Mir ist ein Kaffeefilter aber trotzdem lieber als ein Nudelsieb ;)
 
Ok, damit wird die Wahl zwischen Intel und AMD zwar nicht zur Wahl zwischen Pest und Cholera aber zur Wahl zwischen Pest und Husten...

Dass keine CPU frei von Fehlern ist, war ja eigentlich klar.

Mir ist ein Kaffeefilter aber trotzdem lieber als ein Nudelsieb ;)
Da du dem Angreifer aber leider nicht vorschreiben kannst, welche Sicherheitslücke er ausnutzen darf und welche nicht, kann der vermeintlich sichere Kaffefilter ebenso betroffen sein.
 
AMD schrieb:
We are aware of a new white paper that claims potential security exploits in AMD CPUs, whereby a malicious actor could manipulate a cache-related feature to potentially transmit user data in an unintended way. The researchers then pair this data path with known and mitigated software or speculative execution side channel vulnerabilities. AMD believes these are not new speculation-based attacks.

AMD continues to recommend the following best practices to help mitigate against side-channel issues:



  • Keeping your operating system up-to-date by operating at the latest version revisions of platform software and firmware, which include existing mitigations for speculation-based vulnerabilities
  • Following secure coding methodologies
  • Implementing the latest patched versions of critical libraries, including those susceptible to side channel attacks
  • Utilizing safe computer practices and running antivirus software
AMD geht also davon aus, dass die kombinierte Attacke nur funktioniert, wenn eine bestehende Sicherheitslücke im System ausgenutzt wird.

Und die "Wissenschaftler" führen in ihrem PoC die Spectre-Attacke an.

Spectre ist bei AMD aber Dank Microcode & WindowsUpdates gefixt.

Ergo erhält man bei der bemängelten "Take a Way" - Attacke nur dann Daten, wenn man noch den Spectre-Angriff auf dem betroffenen System ausführen kann.

Wenn nicht - bekommt man Meta-Daten des L1-Cache. Und mit denen kann man nichts anfangen.

Also eine Attacke, die auf Spectre aufbaut. Kein Spectre, keine Attacke. Hui...
 
Da du dem Angreifer aber leider nicht vorschreiben kannst, welche Sicherheitslücke er ausnutzen darf und welche nicht, kann der vermeintlich sichere Kaffefilter ebenso betroffen sein.
Klar :)

Wenn ich bei Gewitter auf ner freien Wiese bin kann ich mich ins Gras werfen oder nen Drachen an nem kupferdraht steigen lassen.

Erwischen kann es einen so und so.
Mir ist allerdings die Option mit der geringeren Wahrscheinlichkeit lieber ;)
 
Also eine Attacke, die auf Spectre aufbaut. Kein Spectre, keine Attacke. Hui...

Du weißt aber, was "with known and mitigated software or speculative execution side channel vulnerabilities" bedeutet, oder??
mitigated <> gefixt...
Spectre lässt sich nicht fixen, aber auch das weißt du sicher ;)

Mir ist allerdings die Option mit der geringeren Wahrscheinlichkeit lieber ;)
Ernst gemeinte Frage - an was machst du die Wahrscheinlichkeit jetzt genau fest?
An der Anzahl der Listungen? -> das kannst du getrost als unsinnig verbuchen. Denn die Anzahl der Fehler sagt erstmal nichts über die Effektivität aus, an sein Ziel zu kommen. Es reicht eine einzige Lücke zur richtigen Zeit an die der "Angriff" ansetzt und das Ding ist offen.


Simples Beispiel, dein Nachbar kann noch tausende mal seinen Schlüssel zu seiner Wohnungstür stecken lassen oder verlieren - und dann noch tausende male das Schloss tauschen, nachdem das ihm gemeldet wurde.
Es reicht der eine einzige Tag wo dir das passiert und der Angreifer steht in deiner Bude.
 
Du weißt aber, was "with known and mitigated software or speculative execution side channel vulnerabilities" bedeutet, oder??
mitigated <> gefixt...
Spectre lässt sich nicht fixen, aber auch das weißt du sicher ;)
AMD spielt bei der "mitigated Software" (usw.) auf die bereits bekannten Sicherheitslücken an. Da die Aussage von AMD sehr allgemein gehalten ist, wird man nähere Ausführungen abwarten müssen, was genau AMD damit ausdrücken möchte.

Da AMD aber davon ausgeht, dass diese Schwachstelle auf bestehenden Sicherheitslücken aufbaut, und diese bei AMD gefixt sind bzw. nicht umsetzbar gelten...

siehe https://www.pcgameshardware.de/Mati...MD-Ryzen-3000-Hardware-Fixes-Spectre-1284233/

... braucht man sich, wie AMD schon schrieb, keine Sorgen machen, insofern man entsprechend aktuelle OS fährt.

Spectre kann vom Prinzip her niemals gefixt werden. Aber die Auswirkungen von Spectre kann man bei AMD an einer Hand abzählen. Bei Intel braucht man noch ein paar Füße dazu.
 
Ernst gemeinte Frage - an was machst du die Wahrscheinlichkeit jetzt genau fest?
An der Anzahl der Listungen? -> das kannst du getrost als unsinnig verbuchen. Denn die Anzahl der Fehler sagt erstmal nichts über die Effektivität aus, an sein Ziel zu kommen. Es reicht eine einzige Lücke zur richtigen Zeit an die der "Angriff" ansetzt und das Ding ist offen.

Das kommt definitv darauf an, welches probabilistische Theorem du zugrundelegst. Bayesianische Inferenz passt die Aussagen des Wahrscheinlichkeitsmodells vor dem Kontext der Menge an verfügbaren Daten entsprechend an.

Dass die Anzahl der Fehler nicht über deren Effektivität aussagt, ist absolut korrekt. Die Behauptung, die Anzahl der Listungen sei deshalb für eine stochastisch basierte Aussage als unsinnig zu verbuchen, ist bestenfalls das: unsinnig.
 
AMD spielt bei der "mitigated Software" (usw.) auf die bereits bekannten Sicherheitslücken an. Da die Aussage von AMD sehr allgemein gehalten ist, wird man nähere Ausführungen abwarten müssen, was genau AMD damit ausdrücken möchte.

Da AMD aber davon ausgeht, dass diese Schwachstelle auf bestehenden Sicherheitslücken aufbaut, und diese bei AMD gefixt sind bzw. nicht umsetzbar gelten...

siehe https://www.pcgameshardware.de/Mati...MD-Ryzen-3000-Hardware-Fixes-Spectre-1284233/

... braucht man sich, wie AMD schon schrieb, keine Sorgen machen, insofern man entsprechend aktuelle OS fährt.

Spectre kann vom Prinzip her niemals gefixt werden. Aber die Auswirkungen von Spectre kann man bei AMD an einer Hand abzählen. Bei Intel braucht man noch ein paar Füße dazu.
Ich kann zumindest, wenn ich als Angreifer eine EC2 Instanz mit 1vCPU miete und vollen Root-Zugriff habe, theoretisch auf Daten des Speichers der zweiten vCPU, wo auch immer diese läuft, abgreifen.
Also dasselbe Spiel wie bei Intel. Und das kannst du als Cloud-Hoster nur unterbinden, wenn du jedem Kunden entweder mindestens 2 benachbarte vCPUs gibst, oder SMT abschaltest, oder eine vCPU "leer" lässt.
 
Ich kann zumindest, wenn ich als Angreifer eine EC2 Instanz mit 1vCPU miete und vollen Root-Zugriff habe, theoretisch auf Daten des Speichers der zweiten vCPU, wo auch immer diese läuft, abgreifen.
Also dasselbe Spiel wie bei Intel. Und das kannst du als Cloud-Hoster nur unterbinden, wenn du jedem Kunden entweder mindestens 2 benachbarte vCPUs gibst, oder SMT abschaltest, oder eine vCPU "leer" lässt.
Das kannst du aber nur, wenn die Sicherheitslücken, die die "Forscher" verwendet haben, nicht geschlossen wurden. Im Text wird Spectre erwähnt.

Bislang gibt es aber nur das Papier der "Forscher" als PoC, keinen echten PoC auf bspw. Github, um das nachzuvollziehen.

AMD steht auf dem Standpunkt, dass die "Forscher" Sicherheitslücken genutzt haben, die bereits als geschlossen oder als "in der Realität nicht angreifbar" gelten. Der Begriff "mitigated software" lässt Interpretationsspielraum.

Andere News-Seiten verstehen das aber so wie ich: die "Forscher" haben bereits geschlossene Lücken geöffnet, um den Angriff durchführen zu können, bei dem man Daten abzweigen kann.

Ohne die Sicherheitslücken bekommt man zwar Zugriff auf den L1-Cache, aber nur die Meta-Daten. Und die helfen dir für gar nichts.
 
Du kapierst es nicht, als EC2 User kann ich das OS und die darauf laufende Software selbst bestimmen, ergo auch anfälligen Code ausführen. Genau das was ihr AMD-Ritter bei Intels Sicherheitslücken moniert habt, tritt eben nun auch bei AMD ein.
 
Ist jetzt auch wenig überraschend, aber mich juckt das so wenig bei AMD wie bei Intel CPUs das da irgend eine Lücke ist oder nicht 8-).
Nur einige User überraschen mit ihrem fast Fanatismus xd
 
Du kapierst es nicht, als EC2 User kann ich das OS und die darauf laufende Software selbst bestimmen, ergo auch anfälligen Code ausführen. Genau das was ihr AMD-Ritter bei Intels Sicherheitslücken moniert habt, tritt eben nun auch bei AMD ein.
Na dann zeig' mal deinen PoC anhand eines Youtube-Videos, dass du in einer EC2-Instanz bei AWS die Lücken ausnutzt.


AWS gibt sich nämlich mehr als nur Mühe, um solchem Schabernack von Vornherein Einhalt zu gebieten.
 
Na dann zeig' mal deinen PoC anhand eines Youtube-Videos, dass du in einer EC2-Instanz bei AWS die Lücken ausnutzt.


AWS gibt sich nämlich mehr als nur Mühe, um solchem Schabernack von Vornherein Einhalt zu gebieten.
Neben der Tatsache, das ich in EC2 auch selbst kompilierte Kernel ausführen kann: Liest du eigentlich auch mal die Quellen, die du postest ?

Presuming that AWS has done everything right, it is still down to its customers to consider whether they are running workloads that may be vulnerable to this type of attack and, if so, to take appropriate action.
 
Neben der Tatsache, das ich in EC2 auch selbst kompilierte Kernel ausführen kann: Liest du eigentlich auch mal die Quellen, die du postest ?
Ja, nur scheinbar hängst du in deiner Theoriewelt fest.


In the Q&A, Anthony was asked about side-channel attacks (such as Spectre and Meltdown). He said that they never allow two instances to occupy the same core simultaneously. A lot of the side-channel issues in the last couple of years were L1-cache-sharing which AWS has never done.
Beitrag automatisch zusammengeführt:

Wie ist das gemeint?
Mit inSpectre lässt sich das schnell heraus finden unter Windows: https://abload.de/img/win_1809_inspectrehekzk.jpg
Download: https://www.grc.com/inspectre.htm

Wenn es den L1 Cache Betrifft, gilt das nicht nur für AMD, immerhin haben alle Cache Stufen Multi-Bit ECC die Veränderungen am Speicher Inhalt erkennen. ;)
Spectre ist nur eine Angriffsmethode für zahlreiche Angriffsvektoren, deren Ausmaß bislang unbekannt ist. Die bisherigen Spectre-Lücken sind gefixt. Aber es werden neue kommen.
 
Ja, nur scheinbar hängst du in deiner Theoriewelt fest.

Wir bewegen uns bei allen Sidechannel-Lücken der letzten 2 Jahren auf einem eher theoretischen Feld.

In the Q&A, Anthony was asked about side-channel attacks (such as Spectre and Meltdown). He said that they never allow two instances to occupy the same core simultaneously. A lot of the side-channel issues in the last couple of years were L1-cache-sharing which AWS has never done.
Da liegt der Hund schon begraben...was ist mit dem zweiten SMT-Thread ?

Die bisherigen Spectre-Lücken sind gefixt. Aber es werden neue kommen.
Falsch, Spectre v2 ist gefixed, v1 müssen die Anwendungen ebenfalls gefixt werden, und da hege ich sehr sehr große Zweifel, dass das schon überall passiert ist.
 
Spectre ist nur eine Angriffsmethode für zahlreiche Angriffsvektoren, deren Ausmaß bislang unbekannt ist. Die bisherigen Spectre-Lücken sind gefixt. Aber es werden neue kommen.
Ok, so war das gemeint.

Wie verhält es sich dann bei inklusivem Cache, wo der L1 Inhalt auch im L2 und L3 Cache vorhanden ist?

AMD nutzt exklusiven Cache, also pro Kern ein Cache Bereich nur für einen Thread. :geek:
 
Die bisherigen Spectre-Lücken sind gefixt. Aber es werden neue kommen.
Bitte keine Unwahrheiten verbreiten. Teile von Spectre lassen sich nicht fixen, sondern nur erschweren - deswegen sprach ich oben auch explizit an, ob dir die Bedeutung von "mitigated" geläufig ist. Denn es ist eben nicht gefixt.

Auch ist an der Thematik hier irgendwie noch nicht alles erzählt wurden.
Klar, es könnte sein, das hier massiv Lügen verbreitet werden, aber es soll, nach Behauptung von zdnet.com!, Aussagen der Entdecker der Thematik hier geben (per Mail auf Nachfrage scheinbar), die Zweifel am Statement von AMD lassen. Einerseits soll mit aktuellen Patches, Firmware und Bios/UEFI die Ausnutzung weiterhin gegeben sein - das AMD stand jetzt sagt, das bisherige "Mitigations" die Thematik beheben stimmt demnach dann nicht - und andererseits widerspricht das Whitepaper auch der Aussage, dass nur Metadaten betroffen sein.

Btw. "AMD believes these are not new speculation-based attacks." finde ich bei sowas ja auch immer ziemlich geil ;)
Politisch korrekt, das stimmt wohl, praktisch aber völlig nichtssagend. Im Zweifel haben sie sich dann einfach geirrt. Denn da steht nicht, ist so, sondern man glaubt, dass das so ist.


Aber egal, spielt am Ende auch weniger eine Rolle.
Genau so wie ich die Meinung vertrete, dass die Lücken hier bei Intel zu stark medial aufgepusht werden, gilt das freilich auch für AMD. Es gibt genügend unmittelbarere Gefahren - vor allem dort, wo Code Execution notwendig ist... Das Ausbrechen aus VMs ist jetzt kein Ding der Unmöglichkeit, Privilege Escalation ist jetzt nicht ultra selten, volle Root Rechte auf ein System ergeben noch viel bessere/einfachere/zielführendere Ansatzmöglichkeit, sodass man auch hier nicht die Kopfstände machen muss um über so einen Weg an sein Ziel zu kommen...
 
@fdsonne
Die Lücke wurde ja von einem Professor und seinen Studenten gefunden, auch wenn diese durch Intel Finanziert werden sehe ich hier kein Grund den Fund als Lüge hinzustellen.

Die Frage die sich mir stellt, ist wie immer wird alles in einen Topf geworfen evt. auch die Tools um solche Lücken zu finden.
Dabei gibt es sehr wohl feine Unterschiede in der Architektur und im Design.

Auch Lücken finden will gelernt werden, gerade weil die Herangehensweise Unbekannt ist.

Das Programm InSpectre gibt mir aber "Protected" aus und nicht mitigated.

System is Meltdown protected: YES
System is Spectre protected: YES
Microcode Update Available: NO!
Performance: GOOD
CPUID: 600F20
(full details below)

This 64-bit version of Windows has been updated for full awareness of both the Spectre and the Meltdown vulnerabilities. If the system's hardware (see below) has also been updated, this system will not be vulnerable to these attacks.

This system's AMD processor is not affected by the Meltdown vulnerability and it has been updated with new features required to allow its operating system to eliminate the Spectre vulnerabilities and/or to minimize their impact upon the system's performance.

 
@fdsonne
Die Lücke wurde ja von einem Professor und seinen Studenten gefunden, auch wenn diese durch Intel Finanziert werden sehe ich hier kein Grund den Fund als Lüge hinzustellen.
Das ließt sich so als wäre Intel hier der alleinige Geldgeber - ist es aber gar nicht, die Entdecker werden unter anderem durch Intel finanziert.

Das Programm InSpectre gibt mir aber "Protected" aus und nicht mitigated.
Welche Rolle spielt was irgend ein Programm angibt??
Der Beitrag hier belegt eineindeutig, dass auch "Protected" in der Anzeige nichts wert ist, wenn es denn dann trotzdem geht. Unabhängig davon ist es trotzdem egal, was irgendwelche Tools anzeigen. Das Statement von AMD ist eigentlich ziemlich eindeutig in der Hinsicht.

Dass es dabei sehr wohl "nur" um Mitigations geht, wie auch einiges bei Intel eben nur (prinzip bedingt) Mitigations sein können zeigt auch:
 
@fdsonne
Also wenn du den Programmiere(rinnen) schon kein Glaube schenkst, wem dann?
Bei InSpectre wird doch der Autor genannt mit Vor und Zu-Name...

Wer ganz sicher gehen will kann immer noch die Kern-Isolierung von Windows Defender nutzen. :)
 
Nimms mir nicht übel, aber du verstehst offenbar das Problem mit InSpectre als Software gar nicht... Ich habe es dir oben versucht zu erklären. Mit "Vertrauen" in den Programmierer hat das nix zu tun.
 
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