„Take A Way“ Sicherheitslücke bei Ryzen und Epyc

[Schnoesel]

Eine neue Sicherheitslücke betrifft alle AMD-Prozessoren seit dem Jahr 2011, einschließlich aktuellster Ryzen und Epyc auf Basis von Zen, Zen+ und Zen 2. Begonnen hat das Problem aber bereits mit der Bulldozer-Architektur und allen darauf basierenden Lösungen...

https://www.computerbase.de/2020-03/amd-ryzen-epyc-sicherheitsluecke-cpu/

Mal sehen wie sich AMD dazu äußert und ob sie es besser machen als INTEL. Von der Einordnung her wohll nicht so schlimm wie Meltdown oder Spectre, weil weitaus weniger Daten abgegriffen werden können, aber das heißt nicht dass es unbedeutend ist.

Viel Spass Intel Boys :biggrin:

[JVC]

"Die Forscher, die die Lücke gefunden haben, hatten zuletzt bereits fast ein Dutzend Probleme in Intel-Prozessoren aufgedeckt."
"Allerdings sei die Lücke weitaus nicht so gravierend wie die zuletzt bei Intel-Prozessoren entdeckten..."
~1:12 ... ab in die nächste Runde ^^

M.f.G. JVC

[Ex3cut3r]

Und was ist darin jetzt so überraschend? Haben AMDler wirklich erwartet das ihre Prozessoren keine Lücken haben? Und sich etwa über die Konkurrenz lustig gemacht? Jedes System kann Lücken haben, scheiße nur wenn die Patches mal wieder Performance fressen, ich habe bis heute mit meinen 4770k die Patches nicht installiert, und es juckt mich auch nicht. Ich habe keine erheblichen Summen auf digitalen Konten. Oder sonstiges. Bargeld FTW.

[Monsta]

Und was ist darin jetzt so überraschend? Haben AMDler wirklich erwartet das ihre Prozessoren keine Lücken haben? Und sich etwa über die Konkurrenz lustig gemacht? Jedes System kann Lücken haben, scheiße nur wenn die Patches mal wieder Performance fressen, ich habe bis heute mit meinen 4770k die Patches nicht installiert, und es juckt mich auch nicht. Ich habe keine erheblichen Summen auf digitalen Konten. Oder sonstiges. Bargeld FTW.

Sollen wir nicht darüber diskutieren weil es für Dich nicht überraschend ist?

Ich erwarte von einem Produkt das es KEINE Lücken hat, natürlich ist die Realität eine Andere, und darüber muss gesprochen werden um ggf die nächste Kaufentscheidung zu überdenken.

Und es ist hier den Leuten sowas von egal das du keine Sicherheitspatches einspielst weil Du Deine Kiste lediglich zu daddeln benutzt.

[Ex3cut3r]

Aha. Und was machst du so? Einen kleinen Investbank Server? :freak:

Als ob jemand als Privat User solchen Lücken juckt. Wie lang ist es nun seit Spectre/Meltdown her? 3-4 Jahre? Also ich habe selbst von Banken die wohl alle Intel nutzen, nix gehört. Komisch....

Es wurden all die Jahre nur von Jubel AMD Perser durchs Foren Dorf getrieben. Und jetzt ist AMD selbst auch mal betroffen? Und wo sind Sie alle? Richtig beim Hartz 4 Antrag ausfüllen.

Da lache ich mich echt tot.

[Langlay]

Ich erwarte von einem Produkt das es KEINE Lücken hat, natürlich ist die Realität eine Andere, und darüber muss gesprochen werden um ggf die nächste Kaufentscheidung zu überdenken.


Die Realität muss in so einem komplexen Produkt anders sein. Ein komplexes Produkt ohne Fehler und Schwachstellen gibt es nicht und wird es auch nie geben. Wenn dann muss man abwegen welche Fehler für einen gravierend sind und mit welchen man gut leben kann.

[Denniss]

Im Vergleich zur Intel Lücke von Vorgestern ist das jetzt bei AMD gefundene ein Mückenfurz.
Zumindest verstehe ich die Kommentare des Entdeckers bei Twitter so.

[Monsta]

Aha. Und was machst du so? Einen kleinen Investbank Server? :freak:

Als ob jemand als Privat User solchen Lücken juckt. Wie lang ist es nun seit Spectre/Meltdown her? 3-4 Jahre? Also ich habe selbst von Banken die wohl alle Intel nutzen, nix gehört. Komisch....

Es wurden all die Jahre nur von Jubel AMD Perser durchs Foren Dorf getrieben. Und jetzt ist AMD selbst auch mal betroffen? Und wo sind Sie alle? Richtig beim Hartz 4 Antrag ausfüllen.

Da lache ich mich echt tot.


Ja ich betreibe einen Server, und natürlich versuche ich Ihn so sicher wie möglich zu halten.
Ich setze alle Kernel patches lade aktuellen Microcode und halte meine Software aktuell.
Ich setze auf max Sicherheit, was natürlich auch komfort kostet.
Alles andere wäre fahrlässig.

Banken spielen keine Patches ein? Finde ich schon was seltam.

Und meine Desktop Pc nutze auch ich für meine Finanzen, Banking Einkäufe Versicherungen ect. da spiele ich natürlich auch alles ein.
Kein Plan warum ich das nicht machen sollte.

Ich weiß auch nicht was Du mit Deinem letzten Absatz meinst, ich denke Du solltest mal an die frische Luft.

[Ex3cut3r]

Sry. War definitiv nicht an dich gerichtet, aber es ist schon merkwürdig, wo denn alle hin sind? Wäre in der Überschrift Intel + Lücke, da bin ich mir sicher, hätte dieser Thread hier schon 10 Seiten.

[Brillus]

Sry. War definitiv nicht an dich gerichtet, aber es ist schon merkwürdig, wo denn alle hin sind? Wäre in der Überschrift Intel + Lücke, da bin ich mir sicher, hätte dieser Thread hier schon 10 Seiten.
Überprüfen wir mal diese Behauptung. Dieser Thread 8 Post in 12 Stunden = 0,67 Posts/h

Bei Intel (https://www.forum-3dcenter.org/vbulletin/showthread.php?t=599169)

21 Posts in 44 Stunden = 0,48 Posts/h

Deine Aussage ist vollkommen widerlegt, weder hat Intel 10 Seiten, sondern gerade mal 2 in mehr als der dreifachen Zeit, und auch insgesamt weniger Post in der selben Zeit.

[Linmoum]

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.
https://www.amd.com/en/corporate/product-security

[Lehdro]

AMD believes these are not new speculation-based attacks.
Das sind ja schon fast Intelmäßige Aussagen. Ganz schwach AMD.

[Linmoum]

Die Aussage hast du aber schon verstanden, oder? Genauso wie das, was AMD im Zuge dieser Aussage gegen diese Attacken an Maßnahmen empfiehlt?

[Lehdro]

Die Aussage hast du aber schon verstanden, oder? Genauso wie das, was AMD im Zuge dieser Aussage gegen diese Attacken an Maßnahmen empfiehlt?
Ja.

Aber wenn man solange wie AMD dabei Vorlauf hatte (halbes Jahr?), helfen einem diese Aussagen auch nicht wirklich weiter, da sie komplett normale Standards sein müssten. Es ist halt wischi-waschi. Ich habe nichts davon und AMD haut ein "ist nichts neues" raus. Super.

[Screemer]

das bedeutet schlicht, dass die maßnahmen die man gegen andere spekulative-angriffe schon getroffen hat nach amds einschätzung ausreichend sein sollten. wo ist also das problem an dieser aussage?

[Lehdro]

das bedeutet schlicht, dass die maßnahmen die man gegen andere spekulative-angriffe schon getroffen hat nach amds einschätzung ausreichend sein sollten. wo ist also das problem an dieser aussage?
Dass das explizit eben nicht da steht, während bei allen anderen Posts dort spezifische Sachen stehen. Dass das eben nicht ausdrücklich dasteht sagt mir genug.

Wenn AMD meint dass dem so wäre wie ihr es beschreibt, warum schreiben sie dann nicht dieselben Textschnipsel wie bei den anderen speculative attack Sachen? :confused:

[Denniss]

Mit dem Angriff können halt keine Nutzdaten abgegriffen werden, das geht nur in Kombination mit einem Spectre V1 Angriffsvektor. Und dagegen hilft momentan halt nur aktuelle Software die die Möglichkeiten da einschränkt.

[samm]

Additional funding was provided by generous gifts from Intellol?

Einer der Autoren des Papers:


lí ḃaao
@gnyueh
Replying to
@lavados

@Cmoney_319
and 5 others
Thanks a lot for your work! I find it hard to read a paper which is irrelevant to my profession. Is this vulnerability as severe as Meltdown or Zombieload?

---

Daniel Gruss
@lavados
·
Mar 7
Replying to
@gnyueh

@Cmoney_319
and 5 others
Certainly not. The attacks leak a few bit of meta-data. Meltdown and Zombieload leak tons of actual data.https://twitter.com/lavados/status/1236218121704239104?s=20

[Rooter]

das bedeutet schlicht, dass die maßnahmen die man gegen andere spekulative-angriffe schon getroffen hat nach amds einschätzung ausreichend sein sollten. Aber sie sagen doch etwa einen Satz später, es seien keine spekulativen Attacken. :ugly:

MfG
Rooter

[samm]

Aber sie sagen doch etwa einen Satz später, es seien keine spekulativen Attacken. :ugly:

MfG
RooterKeine neuen ;)

[Screemer]

Nein sie sagen es wäre keine neue und nicht das es keine wäre.

[Opprobrium]

Aber sie sagen doch etwa einen Satz später, es seien keine spekulativen Attacken. :ugly:

MfG
Rooter
keine neuen spekulativen Attacken

edit: rot/grüner Doppelpost ;)

[lumines]

Also ich habe selbst von Banken die wohl alle Intel nutzen, nix gehört. Komisch....

Weil ein relativ großer Teil der Systeme dort wahrscheinlich keinen fremden Code ausführt.

[samm]

Weil ein relativ großer Teil der Systeme dort wahrscheinlich keinen fremden Code ausführt.Mainframes: tw. noch IBM
User-seitig: x86 ohne spezifische Beschränkung auf Intel, aber da Latitutes, Elitebooks, T-Modelle waren historisch intelbasiert
Thin Clients: irgendwas inkl. AMD laufen.
Server on premise: alte Intels <= Haswell mitbekommen, neu Migration in die Cloud: was-auch-immer dort an Systemen bereit steht

[lumines]

Ich meinte auch eher entweder die Mainframes oder Systeme, die mit den Mainframes kommunizieren.

Die ganzen CPU-Sicherheitslücken sind ja besonders da unangenehm, wo auch fremder Code ausgeführt wird. Das muss aber nicht auf jedem kritischen System der Fall sein. Deshalb treffen diese Lücken bestimmte Dienste oft härter als andere. Gerade Banken werden wahrscheinlich fast keine Probleme mit solchen Lücken haben, einfach weil ihr primäres Geschäft nicht darauf aufbaut fremden Code auszuführen.

Ob das wirklich so ist, kann ich natürlich schlecht beurteilen, weil ich damit wenig zu tun habe. Man sollte aber immer bedenken, dass diese Lücken nicht jeden Dienst gleichermaßen betreffen.

[Asaraki]

Die ganzen CPU-Sicherheitslücken sind ja besonders da unangenehm, wo auch fremder Code ausgeführt wird. Das muss aber nicht auf jedem kritischen System der Fall sein. Deshalb treffen diese Lücken bestimmte Dienste oft härter als andere. Gerade Banken werden wahrscheinlich fast keine Probleme mit solchen Lücken haben, einfach weil ihr primäres Geschäft nicht darauf aufbaut fremden Code auszuführen.


Genau so ist es, die Spectre/Meltdown Geschichte hat hier nicht einmal für Schweiss gesorgt. Wie oben gesagt liegen die Daten sowieso nicht auf System mit Intel, von ein paar Spastis in den Staaten abgesehen, aber die sind ja auch legallly ausgelagert. Und die Intelsysteme sind hart-administrierte VDIs, d.h. da kannst du problemlos rollend alle updaten und wenn's nötig ist halt ein paar Kernchen dazu kaufen. Fremdcode kriegst du da nur über viele Umwege drauf, da musst du schon vom "malicious user" ausgehen. Hat also nur finanziellen Impact gehabt, aber das ist zu einem grossen Teil einkalkuliert.

Die AMD Geschichte dürfte daher im "Big Business" keine grossen Wellen schlagen, höchstens korrigierend wirken für die Leute die jetzt dachten "Haha Intel kann keine Chips designen". Wo Ingenieure arbeiten kommt immer auch ein bisschen Habakuk raus. True story ^^

[Benutzername]

Mainframes: tw. noch IBM
User-seitig: x86 ohne spezifische Beschränkung auf Intel, aber da Latitutes, Elitebooks, T-Modelle waren historisch intelbasiert
Thin Clients: irgendwas inkl. AMD laufen.
Server on premise: alte Intels <= Haswell mitbekommen, neu Migration in die Cloud: was-auch-immer dort an Systemen bereit steht


SPARCs mit Solaris werden auch zum Teil eingesetzt als Server und als Tradingmaschinen für den elektronischen Handel.

Aber ja, diese ganzen Lücken sind eher ein Problem für cloud und Serververmieter. Banken und Versicherungen lassen eigentlich nur ihren eigenen Kram auf ihren eigenen Rechnern laufen.

pdf von der Uni Graz zu "Take A WAy": https://mlq.me/

---------------------------

Mittlerweile gibt es noch eine Lücke TRRespass(sic)

Was Rowhammer-artiges:

TRRespass (CVE-2020-10255)
3/10/20

AMD is aware of new research related to an industry-wide DRAM issue called TRRespass whereby researchers demonstrated a method that claims to bypass existing Targeted Row Refresh (TRR) mitigations. AMD microprocessor products include memory controllers designed to meet industry-standard DDR specifications. Susceptibility varies based on DRAM device, vendor, technology and system settings.

AMD recommends contacting the DRAM or system manufacturer to determine any susceptibility to this issue, in addition to enabling existing DRAM mitigations that reduce a system’s susceptibility to Row Hammer-style attacks like TRRespass, including:

Using DRAM supporting Error Correcting Codes (ECC)
Using DRAM and memory controllers supporting Targeted Row Refresh (TRR)
Using memory refresh rates above 1x
Using AMD CPUs with memory controllers that support a Maximum Activate Count (MAC)
We thank the researchers for their collaboration and participating in the industry best practice of coordinated disclosure. For more information on their research, visit their website.

https://www.amd.com/en/corporate/product-security


TRRESPASS
Project Description
Rowhammer haunted us for the better part of the past decade. Most DDR3 modules were found to be susceptible to this vulnerability which can compromise data directly inside the memory cells. What made it so scary was the fact that it could be exploited from software on PCs, clouds, smartphones, over the web and even remotely from the network. To address the problem, memory vendors designed and implemented all sorts of defenses inside their modern DDR4 chips. According to the vendors, now that DDR4 is widely-deployed we now live in a Rowhammer-free world. But do we?

Well, after two years of rigorous research, looking inside what is implemented inside CPUs and DDR4 chips using novel reverse engineering techniques, we can tell you that we do not live in a Rowhammer-free world. And we will not for the better part of this decade. Turns out while the old hammering techniques no longer work, once we understand the exact nature of these mitigations inside modern DDR4 chips, using new hammering patterns it is trivial to again trigger plenty of new bit flips. Yet again, these results show the perils of lack of transparency and security-by-obscurity. This is especially problematic since unlike software vulnerabilities, we cannot fix these hardware bit flips post-production.

What’s this Rowhammer thingy again?

There are some guarantees that the memory modules promise to give us. First of all, if we write data in memory, it should remain unchanged unless we modify it – we call this the memory integrity principle. Since 2012, the year of discovery of Rowhammer, this guarantee has been lost. The memory cells can be manipulated by unintended side effects by carefully crafting accesses to adjacent memory locations. An attacker accessing some memory rows (aggressors) repeatedly can trigger errors in the neighbor ones (victim rows). In other words, a bit in memory could change its state from zero to one or vice versa without being directly accessed. It is a hardware bug that we cannot patch with the usual updating mechanism for fixing security problems.

Enter TRR: Target Row Refresh (TRR) is what was sold as the ultimate solution against Rowhammer. This name has been widely misused to coalesce any sort of mitigation protecting DDR4 systems from Rowhammer. In reality every CPU vendor and memory manufacturer has implemented its own solution and due to the secretive policies enforced by all of them most of the discussions about the topic are somewhat confused. Nevertheless, these TRR-like solutions are deployed in any modern DDR4 module and memory vendors proudly sell Rowhammer-free memory.
(...)


https://www.vusec.net/projects/trrespass/

[Unicous]

Wie, noch eine Lücke?:confused:

Das ist keine AMD-spezifische Lücke sondern bezieht sich generell auf DDR4.:rolleyes:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10255

Modern DRAM chips (DDR4 and LPDDR4 after 2015) are affected by a vulnerability in deployment of internal mitigations against RowHammer attacks known as Target Row Refresh (TRR), aka the TRRespass issue. To exploit this vulnerability, the attacker needs to create certain access patterns to trigger bit flips on affected memory modules, aka a Many-sided RowHammer attack. This means that, even when chips advertised as RowHammer-free are used, attackers may still be able to conduct privilege-escalation attacks against the kernel, conduct privilege-escalation attacks against the Sudo binary, and achieve cross-tenant virtual-machine access by corrupting RSA keys. The issue affects chips produced by SK Hynix, Micron, and Samsung. NOTE: tracking DRAM supply-chain issues is not straightforward because a single product model from a single vendor may use DRAM chips from different manufacturers.



Und warum wurde dieses "paper" eigentlich von einem 12-jährigen geschrieben.:rolleyes: