> > > > Nun doch: Auch GPUs für Sidechannel-Attacken anfällig (Update)

Nun doch: Auch GPUs für Sidechannel-Attacken anfällig (Update)

Veröffentlicht am: von

tu102-gpuAuch wenn Intel mit der Cascade-Lake-Architektur sowie Coffee-Lake-Refresh eine gewisse Absicherung gegen die Sidechannel-Attacken (Spectre und Meltdown) vorgenommen hat, wird das Thema den Chipgiganten noch lange beschäftigen. Je nach Architektur konnte bisher ausgeschlossen werden, dass bestimmte andere Prozessoren und Chips gegenüber solchen Attacken anfällig sind – so bislang auch die GPUs. Dies scheint sich nun geändert zu haben.

Mehrere Forscher der University of California haben Methoden entwickelt, die zeigen sollen, dass auch GPUs für solche Attacken anfällig sind. Ihre Ergebnisse haben sie nun unter dem Titel "Rendered Insecure: GPU Side Channel Attacks are Practical" (PDF) veröffentlicht.

Die Forscher (zwei Professoren und zwei Studenten) haben einen Weg gefunden, wie sie die Renderpipelines derart manipulieren können, dass Sidechannel-Attacken möglich werden. Dazu wurde die Funktionsweise einer GPU Reverse Engineered – also die Methode, wie die GPU funktioniert, sozusagen vom Ende her untersucht. Das war nötig, da viele Details über die Funktionsweise nicht öffentlich sind. Demonstriert wird dies mit einer GPU aus dem Hause NVIDIA. Es ist jedoch nicht ausgeschlossen, dass dies auf vielen anderen GPU-Architekturen anderer Hersteller ebenfalls möglich ist.

Drei konkrete Methoden haben die Forscher dabei entwickelt. Die Tatsache, dass Grafikkarten das Rendering von Browser-Inhalten vornehmen, sorgt dafür, dass per OpenGL eine Malware eingeschleust werden kann, die dann wiederum sämtliche Daten ausliest. Dies können einfach nur die visuellen Inhalte aus dem Browser, aber auch Daten sein, die dort eingegeben werden. 

In die gleiche Kerbe schlägt auch ein Angriff, der Benutzernamen und Passwörter aus den Login- und Passwort-Abfragen im Browser extrahiert. Eigentlich sollten solche Prozesse voneinander getrennt und es damit nicht möglich sein, von einem Prozess auf den Speicher eines weiteren zuzugreifen. Eben genau dies ist über die Sidechannel-Attacken aber möglich.

Die dritte Methode könnte vor allem im Datacenter ein Problem sein, denn Prozesse müssen nicht auf die Darstellung von UI-Elementen oder Browserfenstern beschränkt sein. GPUs übernehmen als GPU-Beschleuniger auch die Berechnung großer Datenmengen. Aufgrund der vielen tausend Shader pro GPU können komplizierte Aufgaben in tausende kleine Teile aufgetrennt und damit deutlich schneller berechnet werden. Die Prozesse sollten ihre Daten aber immer getrennt voneinander behandeln und nur auf Wunsch Zugriff untereinander gewähren. Eben dies können sich Angreifer ebenfalls zu Nutze machen und über infizierte Prozesse auf den Speicher anderer zugreifen, um dort die gewünschten Daten zu extrahieren.

Zumindest die letzte Attacke lässt sich wohl verhindern, in dem man den Zugang zu den Performance Countern für User-Level-Prozesse abschaltet. Allerdings funktionieren einige Anwendungen nur, wenn genau dies möglich ist. Die Performance Counter führen auf, wann Zugriffe auf den Speicher erfolgen. Daraus lassen sich beispielsweise Rückschlüsse darauf ziehen, um welche Daten es sich handelt.

Die Forscher haben ihre Ergebnisse bereits im vergangenen Monat auf der ACM SIGSAC präsentiert. Neben NVIDIA wurden auch AMD und Intel über die Erkenntnisse informiert. Derzeit gibt es noch keine offiziellen Reaktionen seitens der besagten GPU-Hersteller.

Danke an Gamer1969 für den Hinweis!

Update:

Wir werden darauf verwiesen, dass die eigentliche Entdeckung von Sidechannel-Attacken auf GPUs bereits mehrere Monate alt ist. Mit einem GeForce-Treiber im Februar diesen Jahres sollen einige der Sicherheitslücken bereits geschlossen worden sein. Wie dies auf Seiten von AMD aussieht, ist nicht bekannt.

Social Links

Ihre Bewertung

Ø Bewertungen: 5

Tags

Kommentare (15)

#6
customavatars/avatar268282_1.gif
Registriert seit: 14.03.2017

Oberstabsgefreiter
Beiträge: 435
Habe weitere Informationen gesucht, aber dieses Thema ist nicht so bekannt geworden.

Wenn das einem anderen Hersteller passiert wäre, hätte es sicher einen Riesen Aufschrei gegeben.

Ein Patch soll Ende Februar diese Lücke geschlossen haben.

Aber ob sich weitere Lücken ausnutzen lassen ist momentan nicht bekannt. Vielleicht wird das Thema auch nur totgeschwiegen.
#7
customavatars/avatar269623_1.gif
Registriert seit: 02.05.2017

Admiral
Beiträge: 10661
Stimmt, das war hier schon mal Thema: Nvidia: Warnung vor Sicherheitslücken, Treiberupdate nötig

Aber ob der "Patch" auch auf die News von hier zutrifft?
#8
customavatars/avatar215183_1.gif
Registriert seit: 01.01.2015
€Uropäische Union - Bairischer Sprachraum
Kapitän zur See
Beiträge: 4056
Holla, das ganze ist ja mittlerweile eine ausgewachsene Epidemie, wenn das alle Hersteller mit Treibern hinbekommen wäre ich froh, denn das mit BIOS Updates ist wie man weiß eine Totgeburt, das erreicht nur eine relativ kleine Informierte Gruppe.
#9
customavatars/avatar268282_1.gif
Registriert seit: 14.03.2017

Oberstabsgefreiter
Beiträge: 435
@III
@Don

Als ich die Nachricht in einem anderen, ausländischen Forum, las und nach Suche im deutschsprachigen Raum keine Warnung gefunden habe, erstellte ich einen Thread.

So auch in CB, dort wurde ich darauf hingewiesen die Nachricht sei schon ein halbes Jahr alt und es wurde auf eine „Notiz“ verwiesen. Diese besagt das durch einen Patch die Lücke geschlossen wurde.

Wird in einer CPU eine Sicherheitslücke gefunden rasten alle gleich aus und es werden Warnungen gepostet und Sondermeldungen veröffentlicht. Geht es um Sicherheitslücken in GPUs ist das eine Notiz wert oder in der Logdatei findet sich der Hinweis auf eine Lücke. OK diese Lücken sind selten, aber wie gesehen nicht unmöglich.

Wie viele haben noch alte Treiber für ihr Grafikkarten? Ich kenne Kollegen die sind mit Treiber unterwegs die sie beim installieren der Grafikkarte installierten und nie aktualisierten. Die wundern sich immer wenn ein Neuer Treibe ein bisschen Geschwindigkeit oder Stabilität bringt.

Sicherheitslücken, egal ob CPU oder GPU sollten immer schnellsten durch alle Medien gehen. Vor allem auch mit dem Hinweis was man dagegen machen kann, ob BIOS Update oder in diesem Fall NUR ein Treiber Update.

[COLOR="red"]- - - Updated - - -[/COLOR]

Da stellt man sich aber die Frage:

Ist die Lücke wirklich dicht?
#10
customavatars/avatar287074_1.gif
Registriert seit: 29.08.2018

Oberleutnant zur See
Beiträge: 1363
Zitat Holzmann;26888395
Ob da auch was per Bios Update geht und Leistung kostet ist bestimmt eine entscheidende Frage, oder?

Die entscheidente Frage wäre eher, ob das bei GCN oder einer Intel-GPU überhaupt anwendbar ist und wenn ja, ob man auch verwundbar ist.
#11
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
SN
Moderator
Beiträge: 34345
Zitat Gamerkind;26888924
Die entscheidente Frage wäre eher, ob das bei GCN oder einer Intel-GPU überhaupt anwendbar ist und wenn ja, ob man auch verwundbar ist.


Das PDF gibt darüber auskunft, dass die API zur Auslese der Timings auch bei AMD funktioniert. Für Intel IGPs gibts keinen Hinweis bis dato.
Durch die Auslesefeatures vom Memory funktioniert recht sicher also auch die OpenGL Angriffsmethode über den Browser - also User/PW Abgriff.

"We veri!ed that the memory channel is available on both Nvidia and AMD GPUs and on any Operating System supporting OpenGL (including Linux, Windows, and MacOS)."
...
"Note that AMD also provides the similar APIs to query the available GPU memory on both OpenCL and OpenGL applications through "cl_amd_device_attribute_query" and "ATI_meminfo" extensions respectively, making our attacks possible on AMD GPUs as well."

Der letzte Teil der Frage stellt sich übrigens auch nicht - hier geht es zumindest in Teilen um eine Timingattacke. Das ist ein alter Hut, wenn man es so will. Wer das Timing weis - kann den Spaß rückwärts auch aushebeln.
Noch nie The Rock gesehen?? Sean Connery kennt das Timing um Alcatraz Rückwärts zu infiltrieren. Hollywood damals? Ganz klar ja... Dummerweise im Nachgang betrachtet passend wie Arsch auf Eimer.

Zitat hRy;26888419
Reverse Engineering bei einer nicht näher genannten NV GPU vollzogen. Sind andere Architekturen und Intel sowie AMD auch betroffen?


Wieso nicht näher benannt?
"We verifed the existence of all the reported vulnerabilities in this paper on three Nvidia GPUs from three different microarchitecture generations: a Tesla K40 (Kepler), a Geforce GTX 745 (Maxwell) and a Titan V (Volta) Nvidia GPUs. We report the result only on the Geforce GTX 745 GPU in this paper. The experiments were conducted on an Ubuntu 16.04 distribution, but we verifed that the attack mechanisms are accessible on both Windows and MacOS systems as well. The graphics driver version is 384.11 and the Chrome browser version is 63.0.3239.84."

Der Angriffsvektor ist bei AMD offenbar auch offen. Intel wird nicht erwähnt.
#12
customavatars/avatar148454_1.gif
Registriert seit: 20.01.2011

Leutnant zur See
Beiträge: 1192
Tja, jetzt wird es interessant wie das zu lösen ist. Ob OpenGL gefixt werden muss, der Browser, die GPU Treiber oder die Hardware.
#13
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
SN
Moderator
Beiträge: 34345
Was willst du da fixen?
So eine Form des "Seitenkanal" funktioniert doch immer. Das Prinzip lässt sich nicht fixen. Wer das Timing kennt und diese Umstände rückwärts entschlüsseln kann - der bekommt nun mal Infos. Das ist schlicht logische Konsequenz.

Ein möglicher Workarround der Thematik ist eher, die Zugriffe auf die Infos zu verhindern. Stand jetzt ist der Spaß halt offen, weil man die Möglichkeit der Auslesung solcher Infos defakto in der Form haben wollte. Es wäre bspw. wohl sicher ein leichtes, den Spaß einfach zuzudrehen. API ausgeknipst und fertig. Schon ist kein Access mehr auf die Daten möglich, mit der hier Timingattacken gefahren werden.

Die Frage ist eher, will man das? Man muss hier mMn einfach irgendwo auch die Kirche im Dorf lassen. Über solche Angriffsvektoren lässt sich effektiv alles knacken. Du musst nur die richtigen Infos zur Funktionsweise haben. Der wirksamste "Schutz" vor dieser Art von Angriffen ist die idR Dritten unbekannte Funktionsweise. Vllt hier und dort noch gepaart mit Möglichkeiten zur aktiven Verschleierung.
#14
customavatars/avatar43357_1.gif
Registriert seit: 22.07.2006
orbit des planeten get-low
Korvettenkapitän
Beiträge: 2048
die einfache lösung wäre, arbeitsspeicher und das ganze kaskadierte speichermodell komplett aus dem computer zu streichen und bei start des computers den kompletten inhalt der festplatte in den (natürlich "etwas" vergrößerten) cache zu laden, dann gibts keine zeitliche verzögerung zwischen cachehit und -miss :D LOL

spaß beiseite, so wie ich das damals verstanden habe, liegt es "lediglich" daran, dass die branch prediction, oder genauer die speculative execution "blind" arbeitet. ich hab damals nur einen einzelnen, längeren post über den ganzen exploit gelesen und glaube grob verstanden zu haben wie der funktioniert. du scheinst ja ahnung zu haben, bitte schau das hier mal durch.

ich schreibe in meinem programm ein if-statement mit einem "bösartigen" branch in den ich in echt garnicht reinspringen möchte, es aber antäusche. dieser bösartige branch enthält einen zugriff auf die speicheradresse die ich scannen will. die fremde speicheradresse wird also ausgelesen und der inhalt (ums einfach zu halten die zahl 17) auf den startindex von einem array dass ich mit spezieller länge angelegt habe addiert. speziell deshalb, weil der inhalt der zu scannenden adresse so multipliziert wird, dass jeweils eine ganze cacheline an daten entsteht und so groß muss das array dann eben insgesamt sein.
die speculative execution führt diesen ganzen teil also schonmal blind aus um die cpu busy zu halten, während ich an der jetzigen programmstelle auf irgendwas warten muss. und wenn ich schliesslich an mein if-statement im code gelange und in den "gutartigen" branch springe, um keinen access fault zu bekommen, wird alles vorher berechnete verworfen. jetzt muss ich in meinem gutartigen branch lediglich alle indizes im array einmal aufrufen und der inhalt der am schnellsten ankommt, wurde offensichtlich im vorneherein schonmal gecachet, ergo kann ich rückrechnen was die zahl war, die addiert wurde.

stimmt das so? wenn ja, dann erklär mir bitte was du mit

Zitat fdsonne;26889329
Über solche Angriffsvektoren lässt sich effektiv alles knacken. Du musst nur die richtigen Infos zur Funktionsweise haben. Der wirksamste "Schutz" vor dieser Art von Angriffen ist die idR Dritten unbekannte Funktionsweise. Vllt hier und dort noch gepaart mit Möglichkeiten zur aktiven Verschleierung.


genauer meinst? meiner meinung nach lässt sich das lediglich lösen, indem man immer den speicherzugriff überprüft, was ja aus performancegründen beim predicten eben nicht gemacht wird.
#15
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
SN
Moderator
Beiträge: 34345
Genauer?
Ließ mal das PDF um was es hier geht.

Kurz zusammengefasst - es gibt ne Schnittstelle, welche Speicherauslastung überwachen lässt. Speicherauslastung ändert sich - logisch, bei aller möglichen ausgeführten Dinge. Der "Angriff" hier ist einfach in der Form, dass jemand anhand des Musters der Speicheränderungs-Daten (Menge, Anzahl, Häufigkeit usw.) ziemlich exakt sagen kann, was wo wie passiert. -> und im Falle der PW Themen auch das Password und den Usernamen bekommt.
Da wird nicht mit realen Daten hantiert! Zugriff gibt es über die OpenGL Thematik auf den Speicher in der Form nicht - sondern über den Umweg mit dem "entschlüsseln" der Muster.
Das lässt sich nicht fixen
Um Kommentare schreiben zu können, musst Du eingeloggt sein!

Das könnte Sie auch interessieren:

  • Die GeForce RTX 2080 Ti und RTX 2080 Founders Edition im Test

    Logo von IMAGES/STORIES/2017/GEFORCERTX2080

    Heute nun ist es endlich soweit und wir präsentieren die vollständigen Leistungsdaten und Messwerte zu den beiden ersten Karten der GeForce-RTX-20-Serie von NVIDIA. Nach der Vorstellung der Pascal-Architektur im Mai 2016 sind die neuen Karten für NVIDIA in vielerlei Hinsicht ein... [mehr]

  • GeForce RTX 2080 Ti von ASUS und MSI im Test

    Logo von IMAGES/STORIES/2017/ASUS-STRIX-RTX2080TI-25_EBA36C79E22348199FB2B590657E5413

    Nach den ersten drei Modellen der GeForce RTX 2080 schauen wir uns nun zwei Custom-Varianten der GeForce RTX 2080 Ti an. Diese stammen aus dem Hause ASUS und MSI, unterscheiden sich äußerlich in einigen Aspekten natürlich, sind sich auf den zweiten Blick aber ähnlicher als man denken möchte.... [mehr]

  • Kleiner Turing-Ausbau: Gigabyte GeForce RTX 2070 WindForce 8G im Test

    Logo von IMAGES/STORIES/2017/GIGABYTE-RTX2070-WINDFORCE-LOGO

    Gestern war es soweit und mit der GeForce RTX 2070 startet die vorerst "kleinste" GeForce-RTX-Karte der neuen Serie von NVIDIA. Mit der Gigabyte GeForce RTX 2070 Windforce 8G haben wir ein Partnermodell im Test, denn die Founders Edition ist bislang noch nicht verfügbar. Erwartet wird die GeForce... [mehr]

  • 7-nm-GPU und 16 GB HBM2: Die Radeon VII im Test

    Logo von IMAGES/STORIES/2017/AMD-RADEONVII

    Heute ist es endlich soweit: Es gibt in Form der Radeon VII endlich wieder eine neue Grafikkarte aus dem Hause AMD. Zwar kommt auch hier die bekannte Vega-Architektur zum Einsatz, durch die Kombination einer in 7 nm gefertigten GPU mit 16 GB an extrem schnellen HBM2, ist die Radeon VII aber... [mehr]

  • ASUS ROG Strix GeForce RTX 2070 OC im Test

    Logo von IMAGES/STORIES/2017/ASUS-ROG-RTX2070

    Nach dem ersten Einstiegsmodell können wir uns nun auch eines der schnelleren Modelle der GeForce RTX 2070 anschauen. Die ASUS ROG Strix GeForce RTX 2070 OC ist eine typische ROG-Strix-Lösung, die das Maximum aus der Hardware herausholen soll. Allerdings gönnt sich ASUS auch einen... [mehr]

  • GeForce RTX 2080 von ASUS, Gigabyte und PNY im Test

    Logo von IMAGES/STORIES/2017/ASUS-GEFORCE-RTX

    Nach dem Test der GeForce RTX 2080 in der Founders Edition, wollen wir uns nun die ersten Custom-Modelle genauer anschauen. Diese stammen von ASUS, Gigabyte sowie PNY. Zwei Modelle verwenden das Referenz-PCB von NVIDIA, eines baut aber auch schon auf einem eigenen PCB des Herstellers auf. Eine... [mehr]