News LeftoverLocals: GPUs von Apple, AMD und Qualcomm anfällig für Datenklau

coffee4free

Redakteur
Teammitglied
Registriert
Okt. 2015
Beiträge
269
  • Gefällt mir
Reaktionen: CountSero und aid0nex
Nicht ein Chip auf der Welt ist komplett "Narrensicher" ,
es wird immer eine geben der sucht und einer der findet.
Einen geben der so etwas ausnutzt oder eben nicht.
Das man immer so einen Aufriss darum macht finde ich etwas übertrieben.
Ich weiß das meine Daten nirgends sicher sind und habe da kein Problem damit.
Ich kann es ja nicht ändern.
 
  • Gefällt mir
Reaktionen: aid0nex, Vasilev, bossbeelze und 3 andere
Auf einer Grafikkarte des Typs AMD Radeon RX 7900 XT sei es etwa möglich, pro GPU-Aufruf rund 5,5 MB an Daten zu exfiltrieren, was sich bei der Ausführung eines 7B-Modells von Metas LLaMA pro LLM-Abfrage auf etwa 181 MB aufsummiere.
Gibt es denn Hinweise darauf, dass auch die MI Serien also CDNA betroffen sind?
Ist ja ne komplett andere Architektur und es werden wohl kaum Supercomputer oder entsprechende AI Systeme mit Consumer Gaming GPUs laufen - nehme ich mal an.
Die RDNA Serie ist ja nicht auf die Anforderungen von LLMs angepasst/optimiert.

Edit: AMD hat einen entsprechenden Security Bulletin veröffentlicht und ja, neben RDNA ist auch CDNA betroffen und somit alle AMD GPUs

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-6010.html

PS: heise hat am Dienstag einen Artikel darüber veröffentlich, dass NVIDIAs HPC Lösungen (A100 und H100) eine kritische Lücke aufweisen, die nach dem erhalt manipulierter Pakete einen Bufferoverflow auslöst und RCE ermöglicht. Dafür gibt es aber inzwischen einen Fix
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Termy
Ich kenn mich in der Materie überhaupt nicht aus. Was heißt das nun für den "normalen" Anwender? Sind nur die Grafikkarten oder auch die CPUs mit integrierter Grafik betroffen?
 
Nur in einer Shared Umgebung (Virtualisierungsplatform).
Hier kann ein Anwender durch Ausnutzung dieser Lücke einen anliegenden Speicherbereich des GPU Speichers auslesen und somit Ein oder Ausgaben (Daten) rekonstruieren.

Du zuhause bist also in erster Linie nicht betroffen und für Anfreifer noch dazu uninteressant
 
Jen-Hsun Huang Gefällt diese Nachricht ! 😬😬


Mal im Ernst , theoretisch möglich und in der Praxis vermehrt vorgekommen ist meilenweit auseinander …
Apple als auch Qualcom haben quasi alternativlos ihre Produkte im Sortiment was gpu angeht.
Also zur Kenntnis genommen ohne zu SHER auf die Waagschale zu legen
 
Ich hatte schon immer das Gefühl, dass mir etwas/jemand ein paar FPS klaut!
 
  • Gefällt mir
Reaktionen: bad_sign und Charminbaer
Naja dazu muss der Bösewicht erstmal auf mein System kommen und alleine das ist schon mal sehr unwahrscheinlich. Denn warum? Noch unwahrscheinlicher ist die Gefahr, dass einer meinen GPU-Speicher ausliest. Welche wichtige Information? Diese News sind was für Nachrichtendienste aber nicht für normale PC-User. Da wird nix passieren.
 
Sorry, aber mir fehlen da wichtige Informationen.

Ist das ein Hardware-Bug oder ein Software-Problem, das z.B. mit Treiberupdates behoben werden kann?

Ich hab in das Git-Repo geguckt und die AMD-GPUs wurden wohl unter Linux mit Mesa getestet. Ob Windows auch betroffen ist? Keine Ahnung

1705515328718.png

Und dafür, dass die dritte Spalte "OS/Driver/Build system" heisst, fehlt mir da z.B. die Kernel-Version, die genutzt wurde. Und die Linux-Grafiktreiber bestehen aus zwei Teilen: Dem Kernelmodul (AMDGPU in diesem Fall) und dem Userspace-Treiber (Mesa).

Mesa 23.1.4 ist auch schon von Juli 2023.


Interessanterweise gab es in Mesa bzw. den DirectX-Vulkan-Übersetzern (DXVK bzw. VKD3D) schon Bugs, die dadurch zustande kamen, dass die Spiele sich darauf verliessen, dass neu alloziierter Grafikspeicher gerade nicht komplett auf Null gesetzt wurde, sondern noch alte Daten vorhanden sind.


/edit: Der Blogpost und das AMD-Statement klären etwas mehr auf als das Github-Repo. Klingt für mich aktuell erst mal danach, dass der Angriffsvektor bislang nicht als kritisch gesehen wurde (Man muss bereits eigenen Code auf dem System ausführen können und eine GPU mit anderen teilen.)

Und genau da macht auch der Sinn auf Machine-Learning-Anwendungen Sinn. Beim (bislang eher gescheiterten) Cloudgaming kann man keinen eigenen Code ausführen.
Erst mit gemieteten ML-Servern ergibt sich ein Szenario, wo sich etwas ausnutzen lässt.

Zumal ein Paper verlinkt ist, dass einen ähnlichen Angriff auf Nvidia-GPUs gezeigt hat - schon im Jahr 2013. Vllt ist Nvidia seitdem dafür sensibilisiert und die anderen ziehen dann jetzt nach.


P.S.: Bevor ich Feierabend mache: Im Blogpost steht das Linux-System, das im Github fehlt: "Arch Linux"...
Genial, ist ja nicht so, dass Arch eine Rolling Distribution ist, die quasi ständig mit Updates versorgt wird. Da ist es ganz genau bekannt, welche Linux-Kernel-Version(en) für die Tests verwendet wurden. /SarkasmusAus
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Knut Grimsrud
MehlstaubtheCat schrieb:
Ich kann es ja nicht ändern.
Man könnte z.B. in Hardware trennen, ich nutze z.B. mein Notebook nur zur Foto und Dokumentverwaltung, Tablet nur zum Surfen, Steam Deck nur für Videospiele usw, nur das Smartphone macht von allem etwas.
Ergänzung ()

Fortatus schrieb:
Der Blogpost und das AMD-Statement klären etwas mehr auf als das Github-Repo. Klingt für mich aktuell erst mal danach, dass der Angriffsvektor bislang nicht als kritisch gesehen wurde (Man muss bereits eigenen Code auf dem System ausführen können und eine GPU mit anderen teilen
Unter den gängigen Desktop Systemen gibt es ja kaum Sandboxen oder ähnliches, aber bei iOS könnte das schon intressant werden...
 
AlphaKaninchen schrieb:
Man könnte z.B. in Hardware trennen, ich nutze z.B. mein Notebook nur zur Foto und Dokumentverwaltung, Tablet nur zum Surfen, Steam Deck nur für Videospiele usw, nur das Smartphone macht von allem etwas.
Dann aber hoffentlich auch Netzwerkseitig getrennt und ohne gemeinsam nutzbaren Speicher.
Ansonsten bringt das alles nichts.

Bei dem Angriffsvektor, geht es ja explizit um shared platforms mit geteilter GPU und dem daraus möglichen auslesen der eigentlich fremden Speicherbereiche.
So wie ich das verstehe geht es auch explizit um Daten im GPU Speicher also noch nichtmal die Möglichkeit in eine andere Sandbox/VM einzudringen.
Meinem Verständnis nach könnte man noch nicht einmal das eingegebene Masterpasswort eines PW Tresors auslesen, sofern die Entschlüsselung nicht durch die GPU erfolgt und das Passwort nicht in jenen Speicher gelangt - aber da könnt ihr mich gerne verbessern.
 
Es geht also im Prinzip nur um GPGPU?
Soweit mir bekannt ist bezüglich "klassischer" Anwendungen das Problem eh bekannt, mindestens mal unter Windows und Linux mit X. Eine GUI-Abschottung gibt es unter Linux meines Wissens erst mit Wayland.
 
  • Gefällt mir
Reaktionen: AlphaKaninchen
Hannibal Smith schrieb:
Dann aber hoffentlich auch Netzwerkseitig getrennt
Du kannst nicht einfach von einem Gerät ein anderes angreifen. Dazu muss die Firewall auf dem Angegriffen Gerät zuerst deine Anfrage durchlassen und es muss dann auch einen Service geben der darauf reagiert und Angreifbar ist.
Ergänzung ()

Hannibal Smith schrieb:
ohne gemeinsam nutzbaren Speicher.
Wenn der Speicher von beiden Seiten geschrieben und gelesen werden kann ja, stellt eine Potenzielle Lücke dar, wenn du allerdings nur mit einem der Geräte lesen und schreiben kannst und mit dem anderen nur lesen stellt es nur für das nur lesen eine Lücke da. Vorausgesetzt natürlich der Server der den Speicher bereitstellt ist nicht selbst der Malware verteilende.
Ergänzung ()

Hannibal Smith schrieb:
Ansonsten bringt das alles nichts.
Jede Trennung bringt etwas, wenn du jede Verbindung untereinander blockierst wird es unbenutzbar bzw man fängt an noch deutlich unsicherer Wege des Datenaustausch zu nutzen.

Denn du wirst feststellen das du dann doch mal ein Foto von der Kamera hochladen möchtest oder ein Dokumente per E-Mail verschicken möchtest. Selbst QubesOS erlaubt daher Datenaustausch zwischen Qubes...

Am Ende ist es immer eine Abwägung, absolute Sicherheit ist möglich aber nahezu unbenutzbar, man kann es aber nutzbar machen indem man an den Richtigen stellen Löcher schlägt. Anzahl, wo und wie hängt vom eigenen Bedrohungsszenario ab.
Ergänzung ()

Hannibal Smith schrieb:
So wie ich das verstehe geht es auch explizit um Daten im GPU Speicher also noch nichtmal die Möglichkeit in eine andere Sandbox/VM einzudringen.
So verstehe ich es ebenfalls, aber wenn eine via WebCL gerenderte Website in der einen Sandbox die anzeigten Passwörter in der anderen sehen kann ist auch nicht so Toll.
 
Zuletzt bearbeitet:
Zurück
Oben