Rekonstruktion von Daten über den VRAM der Graka

[Popeljoe]

Habe es grade bei Heise gefunden und finde es extrem spannend, was man aus dem VRAM der Graka so Alles noch auslesen kann.
http://www.heise.de/newsticker/meldung/Gefaehrliches-Gedaechtnis-der-Grafikkarte-2586875.html
Die letzten Minuten verbleiben anscheinend und sind gut auslesbar, da der VRAM bei vielen Grakas auch nach dem Neustarten nicht gelöscht wird.
Gruselige Sicherheitslücke...

[Leonidas]

Und der Bug schlummert sicher schon seit des Anfangstagen des PCs im System ...

[5tyle]

Interessant schon, nur ob man das tatsächlich als Bug klassifizieren kann? Ist der Framebuffer nicht eigentlich genau dazu da, Frames zwischenzuspeichern? Man kann auch Daten aus dem RAM wiederherstellen nachdem man den Rechner ausgeschalten hat. Weiß aber nicht wie das hier beim VRAM aussieht.

Soweit ich das sehe liegt das Problem hier eher dabei, dass die Daten nach einem Neustart nicht gelöscht werden. Wenn man jetzt einen öffentlichen Rechner hat, dann könnte man dort sowieso einen Keylogger installieren oder Screenshots mitspeichern. Warum sollte man da den Umweg über den VRAM gehen, leuchtet nicht ganz ein. Wenn man schon Zugriff auf den VRAM hat wird man vorher Zugriff auf den Rechner erlangt haben. Wenn man den hat kann man sowieso alle Daten auslesen, ... Wenn es Schwachstellen gibt, dann sind das eher die Treiber, die erlauben Daten von außerhalb des laufenden Betriebssystems auszulesen.

Wie auch immer. In Verschlüsselungsprogrammen wird ja auch immer davor gewarnt, dass ggf. Passwörter und zu verschlüsselnde Daten im Speicher verbleiben können, wohl mit gutem Grund.

[dosenfisch24]

Wir hatten vor einigen Jahren gut 20 GTX 460 in der Uni für Cuda Spielereien angeschafft. (Für anständige 480er hat natürlich das Geld nicht gereicht.)
Davon abgesehen, dass die Karten chronisch unzuverlässig waren und später gegen GTX 560 Ti 448 Core Edition getauscht wurden, hatten einige einen interessanten Bug. Nach einem Neustart und Wechsel des OS (Fedora/Windows), konnte man noch verzerrte Teile des Loginbildschirms oder Desktops des vorher laufenden OS im Bild finden. Ich habe damals vermutet, dass es sich nur um einen Bug dieser speziellen Karten handelt, aber anscheinend hat ihr Fehler nur zufällig die hier angesprochene Schwachstelle aufgezeigt.

[MrSpadge]

Das passt auch zu der Beobachtung: benimmt sich ein Rechner nach nem Absturz merkwürdig, reicht ein Neustart manchmal nicht. Erst trennen des Netzsteckers (oder Umlegen des Netzschalter am Netzteil, wenn es denn einen hat), am besten für ein paar Minuten, hilft meistens.

Damit DRAM seinen Zustand zuverlässig speichert, muss er im µs-Bereich aufgefrischt werden. Trennt man die Speicher bei nem Neustart für wenigstens 1s vom Netz (6 Größenordnungen länger), sollte das doch schon reichen. Das könnte sogar die Zuverlässigkeit der Rechner erhöhen, ist aber natürlich nicht ganz so sicher wie ein absichtliches Überschreiben.

MrS

[jor]

Mein Post aus dem Heise Forum:

Das Problem ist eigentlich jedem bekannt der sich etwas mehr (beruflich) mit GPUs über einem längerem Zeitraum beschäftigt. Dem Finder muss man zugute halten, dass er dieses Problem nun endlich publiziert.

=> Mein Fazit vorab: Die ganz GPU Branche hat das Thema Security völlig verschlafen. Erst mit dem Thema WebGL wurde hier ein Bewusstsein geschaffen. Das im Artikel genannte Problem sollte mit neueren GPUs eigentlich nicht mehr auftreten. Ich kann dies leider aus Mangel an einer neuen GPU nicht prüfen.

Auffällig ist, das die Grafikkarten nicht mehr die neusten sind (vor 2012). Das gleiche Thema kam etwa 2011 im Rahmen von webGL auf. Ich habe leider den Link nicht mehr zur Hand, es gab aber mehrere Testseiten im Internet, in denen man mittels WebGL den aktuellen Framebuffer oder andere Surfaces auslesen konnte. Nach diesem Zeitpunkt war auch das Problem mehr im Fokus, so dass ich vermute es ist kein Thema mehr auf den neusten GPUs.

Was könnte das Problem verursachen?
1. Das Problem scheint unabhängig vom Betriebssystem und Treiber aufzutreten. Es ist also eher auf der eigentlichen Grafik-Hardware zu vermuten. Ich denke man kann es nicht direkt dem Video-Speicher anlasten. Wobei das Problem wohl nicht bei Onboard Grafikkarten auftritt, die ja bekanntlich den Systemspeicher benutze, also DDRx Ram.

2. Vermutlich liegt der Fehler irgendwo in der Firmware der betreffenden GPUs. Es wird wohl angenommen, dass eine angelegte Surface (Framebuffer, etc..) immer vom Nutzer initialisiert wird und damit der vorhandene Inhalt on vorherigen Sessions gelöscht wird. Man scheint nicht mit der "Bösartigkeit" von einigen Entwicklern gerechnet zu haben.

3. Auf neueren Treibern/GPUs sollte dieses Problem eigentlich nicht vorkommen. Falls ja, dann hat der Hersteller an dieser Stelle wirklich geschlafen. Allerdings könnte man diesen Fehler zumindest in Open Source Treibern beheben, indem man angelegte Surfaces in jedem Fall mit einem Standardwert überschreibt ("formatiert") und somit die vorhandenen Inhalte löscht. Leider verschlechtert das die Performance ein bisschen, gerade wenn man öfter Surfaces/Texturen anlegt.

4. Das Problem sollte auf mehreren Ebenen gelöst werden. Zum einen in der vom Entdecker benutzten SDL Bibliothek, man könnte hier auch darauf hinweisen, dass dies ein Fehler in SDL ist. Zum anderen sollten die GPU Hersteller Ihre Firmware und Treiber dementsprechend anpassen.

5. Virtualbox ist nicht unbedingt ein Sonderfall, es ist ja eigentlich keine abgeschottete Virtualisierung, sondern nur eine Applikation die eine Hardware emuliert. Das wird teilweise mit Bordmitteln gemacht (CPUs), teilweise nur per Software. So werden alle Grafikbefehle, SDL, OpenGL etc.. nur an das unterliegende Betriebssystem weitergeleitet bzw. umgewandelt. Es wird sozusagen nur eine GPU emuliert, deshalb sieht man in der Virtualbox auch nie die richtige GPU. Aus grafischer Sicht ist VirtualBox nur eine weitere Fensterapplikation. So wundert es eigentlich nicht, dass dieses Problem auch dort auftritt.

6. Grafik und Security, dies ist im übrigen nicht das einzige Problem mit Grafikhardware. Das liegt unter anderem auch am Kontext, denn wer hat denn Angst vor Bildschirmdieben wenn er einen Egoshooter zockt? Zum anderen liegt es auch an der Nichtspezifikation. OpenGL hat hier einige Lücken. Was passiert z.B. wenn man mittels glReadPixels über den eigentlichen Framebuffer hinausliest ist nicht definiert. Es könnte also passieren dass man auch hier den Inhalt fremder Applikationen ausliest. So könnte der Browser z.B. ein anderes Onlinebanking Fenster oder eine offene Textdatei mit Pins auslesen. Das war ja auch schon Inhalt diverser Untersuchungen zu WebGL.

[Coda]

Das Problem existiert exakt gleich bei normalem RAM. Der einzige Unterschied ist, dass man darauf vom Userspace so einfach aus keinen Zugriff hat. Das hindert einen aber nicht etwas zu booten womit das geht. Da gilt wie immer das Prinzip, das es sowieso keine Sicherheit gibt wenn man wirklich so einen Zugriff auf die Maschine hat.

Ich finde das ganze wird viel zu heiß gekocht. Was sichergestellt werden sollte ist, dass während das OS läuft Applikationen abgeschottet sind und die modernen GPUs können das alle, denn seit einiger Zeit ist der Support für virtuellen Speicher da. Wie weit da der OS-Support unter Windows ist weiß ich nicht.

Und der Bug schlummert sicher schon seit des Anfangstagen des PCs im System ...
Das der RAM-Inhalt bei einem Reboot nicht gelöscht wird ist mit Sicherheit kein Bug. Da hat überhaupt keine Software Einfluss darauf.

Und du willst mit Sicherheit nicht darauf warten, dass die Firmware beim Booten allen Speicher löscht. Das wären einige Sekunden.

Bei RAM gibt das OS den Applikationen bei Allokationen nur gelöschte Pages. Das geht sogar so weit, dass im Hintergrund Threads laufen die freigegebene Speicherseiten löschen. Sowas könnte man auch bei VRAM machen. Aber das bringt wie gesagt auch nichts, wenn ich freie Hand habe welche Software ich booten will.

Je länger ich darüber nachdenke desto mehr nervt es mich. Da wird mal wieder was aufgebauscht ohne das mal jemand drüber nachgedacht hat. Es gibt weitaus problematischere Sicherheitsprobleme. Aber da gibt's halt keine Bilder und man kann sie nicht in drei Absätzen erklären.

Man könnte das in Hardware lösen, indem man in das DRAM-Protokoll ein Reset-Signal einbaut und der Speicher-Chip bei unbeschriebenen Speicher-Seiten zunächst nur Nullen zurück gibt. Aber ich denke nicht, dass da jemand dazu bereit ist das zu implementieren.

[Leonidas]

Normaler RAM wird im OS-Betrieb glücklicherweise so heftig genutzt, das jener schon nach Sekunden mehrfach überschrieben ist (es sei denn man hat 1 TB RAM für Windows 7). Das Problem von Grafikkartenspeicher ist, das für den Bildschirminhalt nur wenige MB benutzt werden, die Grafikkarten aber Gigabytes von RAM haben und jener außerhalb von Spielen nicht genutzt wird. Deswegen kann man von Grafikkarten auch noch mehrere Minuten danach lesen.

Oder falsch gedacht?

[Coda]

Das spielt keine Rolle. Worauf ich hinaus will ist das der, der so einen Angriff machen kann sowieso volle Kontrolle über das System hat. Das is so wie dem Einbrecher den Schlüssel hinlegen und sich dann beschweren, dass er klaut.

[Acid-Beatz]

Das spielt keine Rolle. Worauf ich hinaus will ist das der, der so einen Angriff machen kann sowieso volle Konrrolle über das System hat. Das is so wie dem Einbrecher den Schlüssel hinlegen und sich dann beschweren, dass er klaut.
Zielt der Gedanke/die Gefahr nicht eher darauf, dass so etwas bei Maschinen möglich ist, auf die mehrere Benutzer Zugriff haben - sei es durch RDP oder remote X oder von mir aus auch vrtualisiert mit GPU-Pass-Through?


Greez

[Coda]

Nein, wie gesagt kann das System Prozesse voneinander abschotten.

Es ging in dem Artikel nur darum das nach dem reboot der jeglicher RAM nicht gelöscht ist. Thanks Captain Obvious.

[=Floi=]

darf ich mal fragen, warum dieser nicht einfach verschlüsselt wird und bei jedem "start" ein neuer schlüssel angelegt wird?

[Grestorn]

Weil das Aufwand ist den keiner bezahlt. Warum auch.

[Coda]

Das würde auch nicht unwesentlich Perfomance kosten.

[Andi_669]

sogar auch noch nach einem PC-Neustart – was die Gefährlichkeit des Angriffs enorm erhöht, denn viel weiter als bis zum Ausschalten des PCs denkt kaum ein Sicherheits-Ansatz
dise formulirung in der Meldung ist so wie ich das lese falsch, die Daten bleiben bei eine Neustart erhalten,
nicht jedoch wenn der PC erst einmal aus war, u. der VRAM damit stromlos

[jor]

Soweit mir bekannt ist, wäre ähnliches mit Systemspeicher auch möglich. Zumindest unter Linux oder Windows.

Nehmen wir an, wir starten einen Texteditor und öffnen eine Textdatei mit Passwörtern. Diese Passwörter werden dann im Memory als Strings zwischengespeichert. Wir schließen den Editor anschließend wieder. Wenn der Editor die Daten nicht wieder explizit löscht oder überschreibt, bleiben diese Daten im physikalischen Speicher liegen.

Das Problem dabei ist, dass die Speicher MMU nur Pages/Bereiche im Speicher ungültig markiert, aber nicht mit Nullen überschreibt. Ungültige/freie Pages können nun an andere Anwendungen vergeben werden.

Nun startet man Applikation "Böse" oder ein Trojaner im Hintergrund und dieser erhält durch Zufall den gleichen physikalischen Speicherbereich des Texteditors. Nun könnte diese böse Applikation den Speicher auslesen und irgendwas damit anstellen, also z.B. irgendwohin schicken.

Letztendlich müssen die Anwendungen so entwickelt werden, dass diese den genutzten Speicher beim Beenden sicher wieder löschen und auch das Auslagern auf die Festplatte verbieten. Das sollte bei Bankingsoftware oder Truecrypt etc.. eigentlich der Fall sein.

[Hübie]

Ich überlege wirklich die ganze Zeit wo ich Passwörter sehe :|

[Andi_669]

Ich überlege wirklich die ganze Zeit wo ich Passwörter sehe :|
stimmt jedes halbwegs richtig programmierte Programm zeigt ja nur Sternchen oder Punkte an :freak:

[Popeljoe]

Ich stelle mir vor, dass ich an einem Pc im Hotel eine Sache bei Ebay ersteigere und über den Rechner später mein Passwort für Ebay oder gar Papal ausgelesen wird.
Soweit her geholt ist das imo nicht.

[Andi_669]

wie gesagt da die Passwörter nicht im Klartext da stehen kann da auch keiner was auslesen aus dem VRAM, u. spätestens wenn der Rechner richtig aus war ist sowieso ende mit auslesen,

[fezie]

Wichtiger ist das auf dem PC kein keylogger läuft. Und wenn man mit seinem eigenen Laptop WLAN nutzt dann immer verschlüsselte Verbindungen nutzen

[Lokadamus]

Das Problem existiert exakt gleich bei normalem RAM.Das ist schon ein altes Thema.
http://www.heise.de/security/meldung/Passwortklau-durch-gekuehlten-Speicher-182603.html
http://www.heise.de/security/meldung/Abhilfe-gegen-Passwortklau-durch-gekuehlten-Speicher-199802.html
http://en.wikipedia.org/wiki/Cold_boot_attackDas der RAM-Inhalt bei einem Reboot nicht gelöscht wird ist mit Sicherheit kein Bug. Da hat überhaupt keine Software Einfluss darauf.Doch, bei HP ist dies als Bios- Funktion vorhanden und die paar Sekunden stören den Anwender nicht.

[Coda]

Mich wuerde das sehr wohl stoeren.

[Mosher]

Naja, mich jetz zB überhaupt nicht, solange es sich um einen einstelligen Sekundenbereich handelt. Ich fahre meinen Rechner idR genau 1x täglich hoch, außer ich tätige gerade irgendwelche OC-Settings oder installiere neue Hardware.

Andererseits ist es mir auch scheißegal, wenn jemand, der Zugang zu meinem Haus und meinem Rechner hat, ohne dass ich es mitbekomme, Informationen aus dem VRAM extrahieren kann.
Ich hoffe dann nur, dass er das Silber liegen lässt.

Dennoch ist das kein Grund, warum es kein Nachlaufprogramm geben soll, welches sämtliche Speicher nullt, wenn man es denn will.

[jor]

Ich denke Software die sensible Informationen darstellt sollte es so machen, wie es auch im nichtgrafischen Bereich üblich ist. Die Daten sollten beim Schliessen des Programms "genullt" werden. Dann sollte dieses Problem nicht mehr auftreten.

Konkret sollte eine Applikation des VRAM löschen indem es alle Surfaces und Texture mit zufälligen Werten oder Nullen überschreibt. Ich vermute ein standardmässiges Überschreiben würde zu viel Performanz kosten. Ideal wäre natürlich, wenn die MMU auf der GPU dies automatisch machen würde.

[Lokadamus]

Dennoch ist das kein Grund, warum es kein Nachlaufprogramm geben soll, welches sämtliche Speicher nullt, wenn man es denn will.Hab mal gehört, dass FreeBSD die FPU benutzt, um den genutzten Speicher zu nullen, wenn eine Anwendung beendet wird.

Bei einer Graka dürfte es etwas schwieriger werden, weil erkannt werden müsste, welches Programm welchen und wie viel Speicher benutzt hat.
Nullen sollte reichen, außer es gibt hier irgendwelche ECC Tricks, um den vorherigen Zustand der Speicherzelle wiederherzustellen.