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

[HWL News Bot]

Auch 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...

... weiterlesen

 

[FirstAid]

Sehr interessant, jetzt dürfen wir alle zittern, was in der Zukunft alles auf uns zukommen wird. Hoffe nur, dass es nicht ganz so ein Desaster wird, wie bei den CPUs.

 

[hRy]

Ohohoh, da wird ein Fass ohne Boden aufgemacht. Nicht das ich es begrüße, Lücken aufzudecken die ausgenutzt werden könn(t)en.
Ich fürchte, das Thema wird uns noch lange Zeit verfolgen und hoffe dass diese auch in naher Zukunft geschlossen werden.

 

[Holzmann]

Ob da auch was per Bios Update geht und Leistung kostet ist bestimmt eine entscheidende Frage, oder?

 

[angelsdecay]

das könnte das aus für opencl werden

 

[hRy]

Ob da auch was per Bios Update geht und Leistung kostet ist bestimmt eine entscheidende Frage, oder?

Kann mir nicht vorstellen, dass ein BIOS Update was bringt.
Nach meinem bescheidenen Wissen ändert sowas nichts an der funktionsweise der GPU in Hardware.
Ob es Leistung kostet ist denke ich mal erstmal nebensächlich. Entscheidend ist doch zu aller erst wer und wie betroffen ist.
Reverse Engineering bei einer nicht näher genannten NV GPU vollzogen. Sind andere Architekturen und Intel sowie AMD auch betroffen?

 

[Gamer1969]

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.

 

[Holzmann]

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?

 

[lll]

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.

 

[Gamer1969]

@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.

- - - Updated - - -

Da stellt man sich aber die Frage:

Ist die Lücke wirklich dicht?

 

[Gamerkind]

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.

 

[fdsonne]

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.

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.

 

[Shevchen]

Tja, jetzt wird es interessant wie das zu lösen ist. Ob OpenGL gefixt werden muss, der Browser, die GPU Treiber oder die Hardware.

 

[fdsonne]

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.

 

[fl0]

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 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

Ü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.

 

[fdsonne]

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