Microsoft hält WebGL für gefährlich. Stimmt das?

WebGL – harmful, harmlos oder von beidem etwas?
Kommentare

Vor etwas mehr als einem Jahr hat Microsoft bekannt gegeben, dass WebGL zu gefährlich sei, um es im Internet Explorer zu unterstützen. Zuvor waren von Context Information Security in zwei Berichten Schwachstellen in WebGL aufgezeigt worden. Wie sicher oder unsicher ist WebGL denn nun wirklich?

Bevor ich zu den einzelnen Kritikpunkten bzw. Schwachstellen komme, eine allgemeine Einschätzung der Lage. Seit einigen Jahren geben sich die System- und Anwendungsentwickler größte Mühe, Systeme und Anwendungen sicher zu machen. Siehe beispielsweise die Sandbox für Windows-8-Apps, Tabs in Googles Chrome oder den Einsatz der Memory Management Unit (MMU) für den Speicherschutz. Dadurch wird verhindert, dass ein Programm den Speicher anderer Programme oder des Betriebssystems manipulieren kann. Und da es hier um Grafik geht: Auch in Hinsicht auf die Grafikkarten hat sich bei Microsoft seit Windows XP einiges getan. Seit Windows Vista, der ersten vollständig nach Microsofts Security Development Lifecyle entwickelten Windows-Version, wurden die Grafikkartentreiber immer weiter abgesichert. Sie bestehen inzwischen aus einem kleinen Kernel-Mode-Treiber und einem größeren User-Mode-Treiber, der die meiste Arbeit übernimmt. Mit anderen Worten: Man gibt sich große Mühe, die Möglichkeiten der Programme, Schaden anzurichten, einzugrenzen.

Über den PCI-Bus in den Kernel

Betrachten wir jetzt mal PCI-Karten allgemein bzw. Grafikkarten im Speziellen. Für die gibt es keinen Speicherschutz. Code, der auf PCI-Karten läuft, kann auf den gesamten Speicher des Rechners zugreifen. Das war lange Zeit kein Problem, da auf den PCI-Karten kein vom Benutzer (und damit auch einem Angreifer) manipulierbarer Code lief. Das hat sich bei den aktuellen Grafikkarten geändert, denn auf denen laufen vom Benutzer gelieferte Shader zur Manipulation der Grafikausgaben und die haben prinzipiell (zu den Einschränkungen komme ich gleich) vollständigen Zugriff auf den gesamten Hauptspeicher einschließlich des vom Betriebssystem genutzten Bereichs.

In Form der IOMMU, einer MMU für I/O-Zugriffe, gibt es bereits Ansätze, auch für den PCI-Bus einen Speicherschutz zu implementieren. Über die IOMMU kann festgelegt werden, welche Speicherbereiche die Grafikkarte sehen und/oder beschreiben darf. Aber auch auf diesen Schutz gibt es bereits erste Angriffe [1].

Grafikkarte mit Internetanschluss

Bisher war ein Angriff auf bzw. über die Grafikkarte ziemlich unwahrscheinlich. Zwar könnte ein Angriff über eine entsprechend präparierte normale Anwendung bzw. deren Daten theoretisch erfolgen. Praktisch ist das aber irrelevant. Ein Angreifer, der eine Anwendung oder deren Daten so präparieren kann, dass sie das System über die Grafikkarte angreifen, hat im Allgemeinen weitaus einfachere Möglichkeiten für einen Angriff. Zum Beispiel, indem er die Anwendung direkt zum Ausführen seines Schadcodes präpariert oder eine Schwachstelle in den vielen Anwendungsprogrammen ausnutzt.

Mit WebGL erhält die Grafikkarte aber quasi einen direkten Anschluss ans Internet und ist damit Angriffen über beispielsweise präparierte Websites ausgesetzt. Und darauf sind die Grafikkartentreiber einfach nicht eingerichtet. Vor einem Angriff schützen nur zwei Faktoren: Über WebGL wird kein Binärcode hochgeladen, stattdessen werden die Shader in der OpenGL Shading Language (GLSL) geschrieben, einer C-ähnlichen Sprache, und dann auf dem Clientrechner für die jeweilige Grafikhardware kompiliert. Und die Grafikkarte kann nur auf die Speicherbereiche zugreifen, auf die ihr Treiber den Zugriff erlaubt.

Anders formuliert: Die Sicherheit des gesamten Systems ist beim Einsatz von WebGL von der Sicherheit des Grafikkartentreibers abhängig. Und die sind i. A. nicht in Hinsicht auf besondere Sicherheit entwickelt. Zumal sich die Anforderungen an Grafikausgaben und die Anforderungen an sichere Software diametral gegenüber stehen: Bei der Grafikausgabe kommt es vor allem auf die Performance an, gefolgt von Genauigkeit. Bei der Sicherheit kommt Sorgfalt beim Prüfen aller Parameter an erster Stelle, was sich meist nur zu Lasten der Performance realisieren lässt.

Kommen wir nun zu den konkreten Schwachstellen, die Context Information Security gefunden hat und die von Microsoft ebenfalls bemängelt wurden.

WebGL – Ein Einfallstor für Angreifer?

Die erste Analyse von WebGL wurde am 9. Mai 2011 von James Forshaw veröffentlicht [2]. Der erste Kritikpunkt ist das bereits oben beschriebene Problem des unkontrollierten Zugriffs auf den Speicher, außerdem wurden DoS-Angriffe und das Ausspähen von Bildern fremder Domains bemängelt. Bevor wir zu den möglichen Angriffen kommen, gibt es zuerst einen vereinfachten Überblick über den Aufbau des 3-D-Grafiksystems.

3-D-Grafik im Überblick

Das 3-D-Grafiksystem basiert auf mehreren Schichten (Tabelle 1). Auf der untersten Schicht befindet sich die Hardware mit dem Grafikprozessor (Graphics Processor/Processing Unit, GPU) selbst. Auf dieser Schicht gibt es kein allgemeines API, sondern nur herstellerspezifische Interfaces, die die auf Programmiersprachenebene benötigten Funktionen bereitstellen. Moderne Grafikhardware enthält i. A. von User-Mode-Prozessen individuell programmierbare Einheiten, die so genannten „Shader“.

Über der Hardware befindet sich der Treiber, der meistens im Kernel-Mode des Betriebssystems läuft. Er verbindet die herstellerspezifische Low-Level-Hardware mit einem standardisierten Interface wie beispielsweise dem Windows Display Driver Model (WDDM), über das die anderen Komponenten des Betriebssystems auf die GPU zugreifen können.

Über dem Treiber sitzt das Scheduling, für das es mehrere mögliche Orte für seine Implementierung gibt: Im Kernel-Treiber selbst, im Betriebssystem oder auch komplett im User Mode. Seine Aufgabe ist die Verwaltung der Zugriffe durch die verschiedenen auf dem Rechner laufenden Programme. Bei herkömmlichen Grafikkarten greift normalerweise zu jedem Zeitpunkt nur eine Anwendung, beispielsweise ein Windows-Manager, auf die GPU zu. Im Fall von 3-D-Grafiken müssen mehrere Programme gleichzeitig direkten Zugriff auf die Shader und den Speicher der Grafikkarte haben, was über den darauf spezialisierten Scheduler realisiert wird.

Über dem Scheduler sitzt dann die Interface-Library, über die die Benutzerprozesse auf die Grafikkarte zugreifen. Beispiele hierfür sind Direct3D (die auch einige Kernel-Funktionen enthält) und OpenGL als Cross-Platform-Lösung. Die Interface-Library stellt APIs zum Erstellen der anzuzeigenden 3-D-Grafiken, Compiler zur Umwandlung der in einer allgemeinen Sprache geschriebenen Shader-Programme in GPU-spezifischen Code sowie Funktionen für die Verwaltung der Textur-Informationen für den Grafikkartenspeicher bereit. Die Interface-Library ist die höchste Abstraktionsstufe, auf der soweit wie möglich auf hardwarespezifische Funktionen verzichtet wird.

Tabelle 1: Das 3-D-Grafiksystem basiert auf mehreren Schichten

WebGL und seine Auswirkungen

Normalerweise haben die Inhalte im Webbrowser keinerlei Zugriff auf die Hardware. Soll zum Beispiel eine Bitmap-Grafik angezeigt werden, ist dafür entsprechender Code im Webbrowser selbst zuständig. Und der ruft dafür normalerweise eine dafür zuständige Betriebssystemfunktion auf, die dann die eigentliche Darstellung übernimmt. Selbst beim Einsatz von 2-D-Grafikbeschleunigung hat der Browserinhalt selbst keinen direkten Zugriff auf die GPU. Außerdem sind 2-D-Grafiken recht einfach zu prüfen, relativ schnell zu rendern und enthalten generell nur wenige programmierbare Funktionalitäten, die einen direkten Zugriff auf die Grafikhardware erfordern.

WebGL dagegen erlaubt den direkten Zugriff auf die Grafikhardware. Der Shader-Code wird in den GPU-spezifischen Code kompiliert, in den Speicher der Grafikkarte geladen und von der GPU ausgeführt. Wie lange das Rendering der Daten dauert, lässt sich aus den Rohdaten nur schwer ermitteln. Außerdem sind die 3-D-Grafiken zumindest teilweise nur schwer zu prüfen, sodass Sicherheitsbedingungen kaum durchzusetzen sind.

Läuft der Shader-Code erst einmal auf der GPU, kann er nicht mehr so einfach gestoppt werden. Zumindest nicht ohne Auswirkungen auf das gesamte System. Durch entsprechend präparierte Daten sind daher zumindest DoS-Angriffe möglich, eventuell auch weiterführende Angriffe, die die Integrität von System und Daten gefährden.

Grafikkartentreiber mit Internetanschluss

Das wäre noch kein wirkliches Problem, wenn Grafikkartentreiber und -hardware auf die Verarbeitung potenziell bösartiger Daten eingerichtet wären. Das sind sie aber zumindest zurzeit noch nicht. Bisher waren Schutzmaßnahmen ganz einfach nicht nötig.

Wie oben schon erwähnt, werden Grafikkartentreiber nicht in Hinsicht auf die Sicherheit, sondern auf die Performance entwickelt. Die Entwicklung sicherer Treiber würde sehr wahrscheinlich zu Lasten der Performance gehen (was sich teilweise durch eine verbesserte Leistung der Grafikkarten ausgleichen lässt) und auf jedem Fall sehr viel Geld kosten. Es ist also zweifelhaft, ob die Grafikkartenhersteller gewillt sind, ihre Hard- und Software zu härten, nur damit WebGL sicher wird.

Dazu kommt, dass es nicht ausreicht, die Treiber etc. einmal sicher zu entwickeln. Mit hoher Wahrscheinlichkeit werden später Schwachstellen gefunden, für die Patches entwickelt und verteilt werden müssen. Das dürfte, vor allem angesichts der vielen OEM-Hersteller mit speziell angepasster Hard- und/oder Software ziemlich schwierig, wenn nicht gar unmöglich werden.

[ header = WebGL – harmful, harmlos oder von beidem etwas? – Teil 2 ]

Ein Klassiker

Context Information Security hat auch konkrete Angriffe bzw. Schwachstellen aufgezeigt. Im ersten Bericht gibt es davon zwei [2].

Denial-of-Service-(DoS-)Angriffe auf Anwendungen sind ärgerlich, aber in den allermeisten Fällen nicht wirklich gefährlich. Im Fall von WebGL betrifft der DoS-Angriff die komplette Grafikausgabe, hat also Auswirkungen auf das gesamte System. Es ist ziemlich ungeschickt (höflich formuliert), einen Standard in die Welt zu setzen, der DoS-Angriffe aus der Ferne zulässt und keinerlei Schutzmaßnahmen bieten kann. Und genau das ist hier der Fall.

Worum geht es konkret? Um ein schon in der Spezifikation von WebGL beschriebenes Problem [3]: „It is possible to create, either intentionally or unintentionally, combinations of shaders and geometry that take an undesirably long time to render. This issue is analogous to that of long-running scripts, for which user agents already have safeguards. However, long-running draw calls can cause loss of interactivity for the entire window system, not just the user agent.“

Damit ist eigentlich schon alles Wesentliche gesagt: Durch entsprechende Eingaben, entweder im Form eines Shaders oder der Grafikdaten selbst (oder einer Kombination von beiden), wird die GPU so weit ausgelastet, dass keine Grafikausgabe mehr möglich ist.

Die Spezifikation führt weiter aus, dass eine Prüfung der Daten keinen wirklichen Schutz bieten kann und schiebt den Schwarzen Peter den „User agens“; also den Webbrowsern, und den Grafik-APIs zu.

Es gibt bereits Bestrebungen, DoS-Angriffen durch eine Prüfung der Eingaben zu begegnen, zum Beispiel im Rahmen des ANGLE Project [4]. ANGLE steht für „Almost Native Graphics Layer Engine“ und dient unter anderem Google Chrome und Mozilla Firefox unter Windows als Default-WebGL-Backend. Teile des Shader-Compilers von ANGLE werden von WebGL-Implementierungen auf verschiedenen Plattformen als Shader-Validator genutzt. Damit lassen sich natürlich nicht alle möglichen DoS-Angriffe erkennen und verhindern, es ist aber zumindest ein Ansatz.

Context Information Security konnte die Möglichkeit von DoS-Angriffen wie es sich gehört auch mit einem Proof of Concept demonstrieren. Dafür musste man nicht einmal einen selbst entwickelten veröffentlichen: Eine Demo aus dem WebGL SDK sperrt den Desktop von Mac OS X, führt zum Absturz von Windows XP und löst unter Windows 7 einen GPU-Reset aus.

Kritische Schwachstellen

Schwachstellen, über die aus der Ferne Code eingeschleust und ausgeführt werden kann, sind für einen Angreifer natürlich sehr viel interessanter als DoS-Schwachstellen. Bei der Suche nach DoS-Schwachstellen wurden von Context Information Security auch Abstürze des Rechners festgestellt, die teilweise für das Einschleusen von Schadcode ausgenutzt werden können. Zum Beispiel wurden in Firefox 6 zwei entsprechende Schwachstellen gefundene, die inzwischen behoben wurden [5]. Diese Schwachstellen kann man WebGL aber nur indirekt zur Last legen, da sie sich in Firefoxs Implementierung und nicht im WebGL-Standard befinden.

Bilderdiebe unterwegs

Context Information Security hat aber auch eine ernsthafte Schwachstelle in der WebGL-Spezifikation gefunden, die das Ausspähen von Bildern über Domaingrenzen hinweg ermöglicht.

Was ist die wichtigste Schutzmaßnahme der Webbrowser? Das Einhalten der Domaingrenzen, wie es durch die Same Origin Policy dokumentiert wird. Der Grundsatz ist ganz einfach: Inhalte von einer Domain dürfen (mit Ausnahme weniger Ausnahmen) nicht auf die Inhalte anderer Domains zugreifen. Durch die Einführung des Canvas-Elements in HTML5 entstand eine Möglichkeit, auf die Bilder anderer Domains zuzugreifen. Um das zu verhindern, wurde das ‚origin-clean‘-Flag eingeführt. Ausgehend vom Default-Wert ‚true‘ wird das Flag auf ‚false‘ gesetzt, sobald Inhalte von einer anderen Domain, beispielsweise ein Bild, auf den Canvas geladen werden. Wenn das Flag ‚false‘ ist, sind keine API-Aufrufe mehr möglich, mit denen die Inhalte aus dem Canvas kopiert werden können [6].

WebGL setzt auf dem Canvas-Element auf und erweitert das ‚origin-clean‘-Flag, sodass es auch Cross-Domain-Texturen abdeckt [7]. Damit sollte der Zugriff auf Inhalte fremder Domains eigentlich effektiv unterbunden sein. Context Information Security hat jedoch einen Weg gefunden, trotz auf ‚false‘ gesetztem ‚origin-clean‘-Flag auf fremde Inhalte zuzugreifen.

Pixelige Spionage

The Shader-Code kann direkt auf die Pixeldaten von Texturen zugreifen. Egal von welcher Domain diese Texturen geladen wurden, denn auf der Grafikkarte gibt es das Konzept der Origins nicht. Mittels eines Timing-Angriffs ist es möglich, Pixelwerte auszuspähen, auch wenn sie nicht direkt gelesen werden können. Dazu wird die Laufzeit des Shaders in Abhängigkeit von Farbe oder Helligkeit geändert und über JavaScript gemessen, wie lange der Shader für die Darstellung der Grafik benötigt. Dabei muss ein Angreifer nicht zwingend das gesamte Bild Pixel für Pixel extrahieren, unter Umständen reicht es ihm, Teile davon mit bekannten Bildern anderer Domains zu vergleichen, um das richtige Bild zu ermitteln.

Context Information Security nennt dafür das folgende Beispiel: Eine Website verwendet Profilbilder mit einem festen URL. Welches Profilbild dargestellt wird, wird anhand des Session-Cookies im Browser entschieden. Ein Angreifer kann dann das dargestellte Bild mit den ihm bekannten Profilbildern bestimmter Personen vergleichen, um festzustellen, welche Person seine bösartige Seite gerade besucht.

Context Information Security hat einen Proof of Concept veröffentlicht und auch ein Video davon bereitgestellt [8]. Das ganze läuft nach folgendem Muster ab:

  1. Ein Timer wird gestartet.
  2. Ein Pixel wird ausgewählt und eine passende Anweisung zum Zeichnen des Bilds erstellt.
  3. Der Render-Prozess wird gestartet.
  4. Ist der Render-Prozess abgeschlossen, wird der Timer gestoppt.
  5. Aus der Dauer des Render-Prozesses wird auf den Wert des Pixels geschlossen.
  6. Die Schritte 1 bis 5 werden so lange wiederholt, bis das Bild ausgespäht wurde.

Reaktion von Khronos

Die Khronos Group als Entwickler der WebGL-Spezifikation hat noch am gleichen Tag auf die Vorwürfe von Context Information Security reagiert [9]: Die Sicherheit sei bei der Entwicklung von WebGL von Anfang an berücksichtigt worden. Alle WebGL-Implementierungen müssen Schutzmaßnahme gegen den Zugriff auf fremde oder nicht initialisierte Speicherbereiche enthalten.

Die Abwehr von DoS-Angriffen werde laufend weiter verbessert, mit GL_ARB_robustness [10], einer Erweiterung für OpenGL und OpenGL ES, sollen DoS-Angriffe und der Zugriff auf fremde Speicherbereiche weiter erschwert werden. Einige GPU-Hersteller haben GL_ARB_robustness bereits implementiert. Browser können ggf. vor dem Aktivieren von WebGL das Vorhandensein der Erweiterung prüfen.

Das Einbinden von Cross-Domain-Bildern wird als äußerst nützlich eingestuft, es wird aber überlegt, Cross Origin Resource Sharing (CORS) oder andere Maßnahmen zum Schutz vor einem Missbrauch zu implementieren.

WebGL Working Group und die GPU-Hersteller in der Khronos Group arbeiten zusammen an der sicheren Implementierung von WebGL, und WebGL bewegt die GPU-Hersteller zur Entwicklung neuer, flexibler Sicherheitsfunktionen.

Es gibt keine bekannten WebGL-Exploits, und Khronos wird auch in Zukunft sicherstellen, dass WebGL sicher genutzt werden kann.

Was ist davon zu halten?

Dass die Sicherheit von Anfang an bei der Entwicklung von WebGL berücksichtigt wurde, mag stimmen. Trotzdem hat Context Information Security mit dem Cross-Domain Image Theft eine Schwachstelle entdeckt und einen Proof of Concept dafür entwickelt. Darüber, ob eine Version 1.0 eines (Möchtegern-)Standards Fehler enthalten darf oder nicht, lässt sich sicher streiten.

Was die Abwehr von DoS-Angriffen mithilfe von GL_ARB_robustness betrifft, muss auf eine Einschränkung hingewiesen werden: Das funktioniert natürlich nur, wenn die GPU die Erweiterung unterstützt. Sofern die Webbrowser WebGL nur aktivieren, wenn die GPU GL_ARB_robustness unterstützt, sind sie vor DoS-Angriffen geschützt (jedenfalls so gut das möglich ist). 3-D-Grafikkarten, die die Erweiterung nicht unterstützen, sind dann nicht WebGL-fähig – auch wenn sie die 3-D-Grafiken prinzipiell darstellen könnten. Das ist eine Tatsache, die man so akzeptieren muss. Sicherheit gibt es nicht geschenkt, in diesem Fall kostet sie dann entweder eine neue, WebGL-fähige Grafikkarte oder den Verzicht auf WebGL.

Context Information Security weist in seinen FAQ [11] darauf hin, dass die Verhinderung eines DoS durch einen Reset der Grafikkarte zu Nebenwirkungen führen kann, da sowohl das Betriebssystem als auch alle zum Zeitpunkt des Resets die Grafikausgabe nutzenden Anwendungen darauf korrekt reagieren müssen. Eventuell kann man das aber auch dem Grafikkartentreiber überlassen, der dann vor dem Reset den Status aller unbeteiligten Benutzer des Grafiksystems sichern muss, um sie nach dem Reset wieder herzustellen.

Es ist ja schön, dass man Cross-Origin-Texturen nützlich findet. Vielleicht hätte man sich dann aber schon früher Gedanken über deren Sicherheit oder Unsicherheit machen sollen. Das wurde nach der Veröffentlichung der Schwachstelle durch Context Information Security dann etwas später nachgeholt.

„Wir arbeiten an der Sicherheit“ ist eine schöne Marketingaussage. Etwas anderes bleibt ja wohl keinem Softwareentwickler übrig. Insbesondere dann nicht, wenn er mit Schwachstellen erwischt wurde. Die Aussage „Es gibt noch keine Exploits“ ist erstens falsch, der Proof of Concept für den Cross-Domain Image Theft ist ein Exploit. Zweitens ist das so ziemlich die ungeschickteste Aussage, die man in Zusammenhang mit Software machen kann. Denn sie beweist rein gar nichts, kann aber schnell dazu führen, dass irgendjemand der Ansicht ist, er müsste das Gegenteil beweisen. Nur, weil es keine Exploits gibt, bedeutet es noch lange nicht, dass es keine Schwachstellen gibt. Das beste Beispiel dafür dürfte Apple bzw. Mac OS X bis vor ca. einem Jahr sein – da gab es trotz vorhandener Schwachstellen auch kaum Angriffe. Entweder hat sich keiner dafür interessiert oder es hat sich für die Cyberkriminellen mangels Masse nicht gelohnt. Wie weit verbreitet ist WebGL – denn lohnt es sich für die Cyberkriminellen, darin nach Schwachstellen zu suchen und dann dafür Exploits zu entwickeln, wenn es doch massenhaft potenzielle Opfer für Java-, Flash- und PDF-Exploits gibt?

[ header = WebGL – harmful, harmlos oder von beidem etwas? – Teil 3 ]

Context Information Security legt nach

Am 16. Juni wurde dann von James Forshaw, Paul Stone und Michael Jordon die zweite Analyse veröffentlicht [12]. Darin wurde das Ausspähen von Daten über eine Schwachstelle in der WebGL-Implementierung von Firefox beschrieben.

Ursache der Schwachstelle ist ein Fehler beim Löschen des Grafikkartenspeichers, durch die ein Angreifer nicht initialisierte Speicherbereiche lesen kann. Als Proof of Concept wurde demonstriert, wie das Bild eines iframe, in dem die Website von LinkedIn geladen wurde, ausgespäht werden kann. Prinzipiell können über die Schwachstelle Screenshots beliebiger Fenster erstellt werden. Beispielsweise von anderen Browserfenstern, dem Desktop oder anderen laufenden Anwendungen.

Des Weiteren wurde von Context Information Security geprüft, inwieweit die WebGL-unterstützenden Browser Google Chrome und Mozilla Firefox die Konformitätstests von Khronos bestehen. Beide Browser bestanden auf allen getesteten Betriebssystemen (Windows XP SP3, Windows 7, Mac OS X 10.6.7 und Ubuntu 11.04) mehr oder wenige viele Tests nicht. Einige der nicht bestandenen Tests weisen auf mögliche Schwachstellen hin. So wurde auch die als Beispiel gewählte Schwachstelle in Firefox entdeckt.

Was ist davon zu halten?

Die Schwachstelle in Firefox darf man erneut nicht WebGL anrechnen, da sie sich nicht im Standard befindet, sondern in dessen Implementierung. Die vielen nicht bestandenen Konformitätstests sind bedenklich, vor allem wenn sie auf mögliche Schwachstellen hinweisen. Da drängt sich die Frage auf, ob die betroffenen Entwickler entweder die Tests gar nicht durchgeführt oder aber kein Interesse am Beheben der Fehler und potenziellen Schwachstellen haben. Beides ist bedenklich.

WebGL Considered harmful

Ebenfalls am 16. Juni wurde dann in Microsofts Security Research & Defense Blog der Beitrag „WebGL Considered Harmful“ veröffentlicht, der in den Medien und allgemein im Web einiges an Aufsehen erregte [13]. Mit Berufung auf die beiden Berichte von Context Information Security werden drei Kritikpunkte aufgeführt:

  • WebGL erlaubt direkte Zugriffe auf die Hardware, die Microsoft für zu weitgehend hält.
  • Die Sicherheit von WebGL hängt zu stark von Dritten ab. Nicht alle Schwachstellen in WebGL werden sich im zugehörigen API befinden. Schwachstellen in den Komponenten von Drittherstellern werden evtl. zu spät oder gar nicht behoben. Die Benutzer sind nicht daran gewöhnt, dass sie ihren Grafikkartentreiber aktuell halten müssen, und insbesondere OEM-Hersteller aktualisieren ihre angepassten Treiber oft erst sehr spät und zu selten. Als Workaround kann WebGL die Nutzung betroffener Komponenten verweigern, was die Benutzer aber einschränken wird.
  • DoS-Angriffe sind möglich. Weder Betriebssysteme noch Grafikinfrastruktur sind darauf ausgelegt, Angriffe über manipulierte Shader oder Daten abzuwehren. ARB_robustness und das sich in Entwicklung befindende ARB_robustness_2 können die Gefahr mindern, ihre Wirksamkeit muss aber erst noch bewiesen werden.

Der nicht genannte Autor kommt zu dem Schluss „We believe that WebGL will likely become an ongoing source of hard-to-fix vulnerabilities. In its current form, WebGL is not a technology Microsoft can endorse from a security perspective.“

Was ist davon zu halten?

Microsofts Bedenken sind verständlich, haben aber einen gewissen Beigeschmack, der auch von vielen Kritikern vorgebracht wurde: Microsoft erlaubt in Silverlight 5 ebenfalls den direkten Zugriff auf die Grafikkartenhardware [14], [15]. Allerdings ist Silverlight ein Plug-in, während WebGL Teil des Webbrowsers ist.

Weitere Reaktionen

Am 8. Juni wurden in Firefox 5 Cross-Domain-WebGL-Texturen deaktiviert, um Cross-Domain Image Theft zu verhindern [16]. Zuvor war die Spezifikation von WebGL angepasst worden. WebGL verbietet nun das Laden von Texturen von anderen Origins als der des Dokuments mit dem Canvas-Element des WebGLRenderingContexts sowie von Canvas-Elementen, deren ‚origin-clean‘-Flag auf ‚false‘ gesetzt ist [17]. In einem nicht-normativen Zusatz wurden Cross-Domain-Texturen zugelassen, wenn sie über Cross Origin Resource Sharing (CORS) [18] freigegeben sind.

Am 6. Juli war Googles Chrome an der Reihe – die Nutzung von Cross-Origin-Texturen wurde deaktiviert [19].

Am 8. November wurde angekündigt, dass in Firefox 8 und Google Chrome Cross-Domain-Texturen wieder zugelassen sind. Sie müssen dafür entsprechend dem nicht-normativen Zusatz in der WebGL-Spezifikation über CORS freigegeben sein [20].

Weitere Schwachstellen

Es wurden bereits mehrfach Schwachstellen in den WebGL-Implementierungen gefunden und behoben. Da sie nicht WebGL zuzuschreiben sind, will ich auf sie nicht weiter eingehen, Benoit Jacob hat einige Beispiele für Firefox in seinem Blog aufgeführt [21].

Am 16. April 2012 wurde in Khronos Bugzilla ein Widerspruch in der Spezifikation von GL_ARB_robustness bemängelt [22]. Bisher ohne Reaktion. Henri Astre hat am 3. Oktober 2011 [23] und am 5. Dezember 2011 [24] die Möglichkeit zum Umgehen der Same Origin Policy von WebGL beschrieben. Eigentlich will der damit nur in guter Absicht trotz des Verbots von Cross-Domain-Texturen Texturen von fremden Origins laden. Tatsächlich hat er aber einen Exploit für eine Schwachstelle veröffentlicht. Bisher ohne Folgen.

Wie gefährlich ist WebGL?

Werfen wir noch kurz einen Blick auf die möglichen Folgen eines Angriffs über eine Schwachstelle , zum Beispiel in Code zur Verarbeitung von JPEG-Bildern und in WebGL. Beide Schwachstellen können über präparierte Webseiten ausgenutzt werden, die zurzeit von den Cyberkriminellen bevorzugte Angriffsvariante. Beim Angriff über ein JPEG-Bild läuft der eingeschleuste Code mit den Rechten des Webbrowserbenutzers. Beim Angriff über WebGL ist die Gefahr groß, dass er im Kernel Mode ausgeführt wird. Was einem Angreifer lieber ist, dürfte jeder wissen.

Trotzdem halte ich Angriffe auf bzw. über WebGL für unwahrscheinlich. Auch und gerade die Cyberkriminellen denken wirtschaftlich. Sollte ihnen ein Exploit für eine WebGL-Schwachstelle in den Schoß fallen, werden sie nicht zögern, ihn zu benutzen. Nach Schwachstellen zu suchen und einen Exploit dafür zu entwickeln, dürfte sich aber nicht lohnen. Sehr wahrscheinlich würde es für so einen Angriff viel weniger potenzielle Opfer geben als beispielsweise für einen Angriff auf eine Schwachstelle in Java, Flash Player oder Adobe Reader, die bisherigen Lieblinge der Cyberkriminellen.

Fazit

Die WebGL-Spezifikation ist, mit Ausnahme der nicht zu beherrschenden DoS-Angriffe, sicher. Das Problem sind die Implementierungen. Insbesondere angesichts der Tatsache, dass WebGL den direkten Zugriff auf die Hardware und damit den Speicher erlaubt. Trauen Sie den Grafikkartenherstellern zu, ihre Treiber wirklich sicher zu machen? Ich habe da gewisse Zweifel.

Und was Microsofts Kritik betrifft: Wer, wenn nicht Microsoft, wäre in der Lage, WebGL für Windows sicher zu machen? Grafikkartentreiber müssen signiert werden, damit sie installiert werden können. Microsoft sitzt also immer am längeren Hebel, wenn es darum geht, deren Entwickler zur Implementierung von Sicherheitsmaßnahmen zu bewegen. Es ist schade, dass Microsoft diese Möglichkeit nicht nutzt. Denn unabhängig davon, ob man nun WebGL nutzen will oder nicht, wäre ein sicherer Grafikkartentreiber immer ein Vorteil.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -