Intel CPU "Feature": Zufallszahlen zwischen CPUs teilen

[Piktogramm]

Das ist mehr eine Meldung als ein Diskussionstarter. Irgend eine zur Diskussion anregenden Frage dürfen sich @SV3N @Volker oder @Jan ausdenken, wenn sie hoffentlich einen Artikel daraus machen

Das Problem
Für viele kryptografische Operationen benötigt es guten Zufall. Eine Möglichkeit diesen ohne all zu große Performanceinbußen zu erhalten sind in CPUs integrierte Zufallsgeneratoren. Für Intel CPUs wurde nun gefunden, dass Zufallswerte die von einem Prozess auf einem CPU-Kern durch einen anderen Prozess auf einer anderen CPU-Kern ausgelesen werden können. Das ist insofern problematisch, da es an vielen Stellen notwendig ist, dass eben jener Zufall geheim bleibt. Wenn Zufallswerte jedoch von anderen Prozessen ausgelesen werden können, ist die Geheimhaltung gefährdet.

Der Fix
Es gibt ein Microcode Update, welches seit dem 9.Juni veröffentlicht ist.
Der Fix frisst Performance, wenn immer einige bestimmte CPU-Befehle zur Erzeugung von Zufallszahlen auftreten. Das dürfte für viele Endanwender vernachlässigbar sein. Relevant sind die Einbußen aber zum Beispiel bei Webservern, die ständig verschlüsselte Verbindungen aufbauen müssen.


Welche CPUs sind betroffen:
Getestet und betroffen sind bisher Broadwell, Skylake, Kabylake, Coffelake, Whiskeylake

Persönliche Einschätzung
Ohne das komplette Paper gelesen zu haben (das ist was fürs Wochenende), der Fehler ist schlimmer als Meltdown. Ich würde nicht empfehlen das µCode update auzusitzen.


Quellen:
gefunden über: https://twitter.com/marcan42/status/1270570295884038145
Paper: https://www.vusec.net/projects/crosstalk/


[1] Vergleichsweise selten aus Sicht eines Computers. Für 1x Zufallszahl erzeugen kommen da Milliarden sonstige CPU-Befehle.

 

[ghecko]

Uff, und das um halb 3 morgens. Ich muss schlafen, Piktogramm. Aber jetzt will ich wissen wie die Lücke funktioniert...

 

[Marco01_809]

Nennenswert ist auch dass die Performance von RdRand, also die gelieferten Zufallszahlen pro Sekunde mit dem gepatchten Microcode um etwa 97% sinken:
https://www.phoronix.com/scan.php?page=news_item&px=RdRand-3-Percent

Besonders problematisch ist, dass der Fix von Intel wohl so aussieht, dass während einem RdRand-Aufruf der Speicherbus komplett lahmgelegt wird. Dadurch müssen andere Kerne auf die Fertigstellung des Befehls warten bevor sie wieder auf den Speicher zugreifen können: https://twitter.com/marcan42/status/1270642703542317056
Damit kann ein Angreifer der einen Prozess dazu bringen kann, Zufallszahlen zu generieren, die Performance des Gesamtsystems drastisch reduzieren => DoS.

Weitere Informationen von Intel finden sich hier:
https://blogs.intel.com/technology/2020/06/ipas-security-advisories-for-june-2020/
https://software.intel.com/security...ep-dive-special-register-buffer-data-sampling

 

[Piktogramm]

Uff, und das um halb 3 morgens. Ich muss schlafen, Piktogramm. Aber jetzt will ich wissen wie die Lücke funktioniert...

Kurz:
Es gibt einen Zufallszahlengenerator, jedoch hat jede CPU ein eigenes Register aus welchem Zufallszahlen gelesen werden. Dieses Register bedient sich jedoch immer nur aus dem einen Zufallszahlengenerator. Wenn zwei Threads auf unterschiedlichen Kernen ihr Zufallsregister lesen, kommt der selbe Zahlwert in deren Registern an. Zufall ist damit geleakt und an der Stelle ist dann auch jede Diskussion zu Ende, denn das ist scheiße.

Für Genaueres muss ich echt das Paper lesen und dass frisst oft einen Tag oder länger um es mit meinem Halbwissen zu verstehen.

Ergänzung (11. Juni 2020)

Besonders problematisch ist, dass der Fix von Intel wohl so aussieht, dass während einem RdRand-Aufruf der Speicherbus komplett lahmgelegt wird. Dadurch müssen andere Kerne auf die Fertigstellung des Befehls warten bevor sie wieder auf den Speicher zugreifen können

Das "wohl" kannst du streichen, dass die Mitigation so ausschaut steht so in der Zusammenfassung vom Paper.
Was man jedoch sagen muss ist, dass dein DoS damit zwar denkbar ist, aber auch nicht trivial. Selbst wenn man als Angreifer massiv verschlüsselte Verbindungen aufbaut, folgen auf 1x Zufallszahlen erzeugen locker einige tausend bis Millionen sonstige Instruktionen. Dabei ist es für Server so oder so ein Problem, wenn irgend ein Angreifer versucht massiv Verbindungen aufzubauen, weswegen man die Anzahl von Verbindungen je Gegenstellen so oder so hart begrenzt. Wenn sich irgendwer im Internet nicht benimmt und sowas versucht, landet die Person sowieso auf den temporären Blacklists der Firewall und es gibt eine "Abuse" Hinweis zum Provider des Netzes aus dem ein solches Verhalten beobachtet wird.


Edit:
Typische Anwendungen wie Webserver verlieren zwar ein paar Prozentpunkte an Leistung, dass aber auch nur für den Worst Case (viele Verbindungsaufbauten für simpelste File Transfers, ohne dass der Webserver zB PHP ausführen muss)
https://www.phoronix.com/scan.php?page=article&item=srbds-crosstalk-benchmark&num=2

 

[madmax2010]

Uff. Das wars dann mal mit dem freien donnerstag. Danke fürs posten @Piktogramm

 

[Fortatus]

@Piktogramm Für Cloud-Dienste ist das aber durchaus relevant. Da muss ein Angreifer ja nicht mal extern drauf zugreifen, sondern kann sich eine virtuelle Maschine mit einem Kern mieten, ein kleines Programm ausführen, dass die ganze Zeit nur Zufallszahlen von der CPU will und schon steht der Server. Mit einem Core diverse virtuelle Maschinen lahm legen.
Bislang haben die Cloud-Anbieter sich wohl damit beholfen, dass die VMs auf einzelne Cores gelockt werden, so dass ein Angreifer auf Core 1 nicht die Daten der anderen 27 Cores lesen kann. Wenn aber 1 Core die gesamte CPU locked, ist es damit vorbei.

 

[Piktogramm]

@Fortatus
Ich merke gerade, dass mit die kriminelle Energie fehlt

Ein bisschen muss ich aber relativieren. Die ganz dicken Xeon CPUs sollen das Problem nicht haben (muss das Paper noch lesen...), da gibt es im Zweifelsfall mehr als einen RNG auf dem Die.
Auf Systemen wo sich mit dem neuen µCode die Möglichkiet für DoS bietet, müsste man dem Hostsystem verbieten rdrand als CPU Feature den VMs anzubieten. Schön ist aber defintiv anders.

 

[ChrFr]

Golem und Heise haben das Thema ebenfalls aufgegriffen, der RDRand scheint nicht das Einzige zu sein wo neue Schwachstellen aufgetaucht sind.
golem.de / heise.de
Bin gespannt auf den CB Artikel.

MfG
Christian

 

[Holt]

Für Intel CPUs wurde nun gefunden, dass Zufallswerte die von einem Prozess auf einem CPU-Kern durch einen anderen Prozess auf einer anderen CPU ausgelesen werden können.

Nein, von einer andere CPU ist nicht die Rede, nur von anderen Kernen, also sollte der ganze Thread am Besten zu den Fischen.

 

[ghecko]

Die großen scheinen ihre liebe Müh mit RdRand zu haben. Erst kommt raus, dass RdRand bei Zen2 nicht funktioniert und jetzt kommt raus, das der von Intel die Ergebnisse von seinem für alle Prozesse auf allen Kernen zugänglich macht.
Läuft. Die Entropie ist kaputt.

Kann es sein dass nur Prozessoren mit Ringbus betroffen sind?

 

[Trefoil80]

Ist das bei Zen2 nicht schon repariert (via UEFI-Update)?

 

[ghecko]

Repariert nicht, deaktiviert. Zumindest ist das der workaround unter linux.

 

[0x8100]

rdrand wurde bei zen2 mit agesa 1003abb gefixt. der workaround für linux davor war das entfernen des rdrand aufrufs in systemd.

 

[Trefoil80]

rdrand wurde bei zen2 mit agesa 1003abb gefixt. der workaround für linux davor war das entfernen des rdrand aufrufs in systemd.

So hatte ich das auch in Erinnerung.

 

[Piktogramm]

Repariert nicht, deaktiviert. Zumindest ist das der workaround unter linux.

Zen und neuer bekamen µCode Updates, da anounced der Linux Kernel auch, dass die CPUs rdrand können. Auf AMD Systemen ohne fix, wird rdrand seitens des Kernels verschwiegen. Ein Programm welches auf einem solchen System rdrand nutzt, würde aber weiterhin laufen und wäre gegen den Bug anfällig.

rdrand wurde bei zen2 mit agesa 1003abb gefixt. der workaround für linux davor war das entfernen des rdrand aufrufs in systemd.

rdrand nutzt systemd weiterhin. Es wurde aber ein sehr kruder fix eingefügt, der darauf prüft ob rdrand den Wert 0 oder -1 zurück gibt um den AMD Bug zu detektieren und auf langsameren Software PRNG auszuweichen, wenn der Bug gefunden wurde.
https://github.com/systemd/systemd/blob/master/src/basic/random-util.c#L130

Nein, von einer andere CPU ist nicht die Rede, nur von anderen Kernen, also sollte der ganze Thread am Besten zu den Fischen.

Danke für die konstruktive und freundlich vorgetragene Kritik. Es ich habe eine kleine Anpassung im Post #1 vorgenommen.