WebGL erlaubt es OpenGL in Webseiten einzubetten, also 3D Grafiken auf der lokalen Hardware direkt zu rendern. WebGL baut auf der API von OpenGL ES 2.0 auf, welches selbst eine Untermenge (und Teilweise Übermenge) von OpenGL 2 ist. Eine Webseite, die WebGL einbindet, funktioniert somit prinzipiell auf aller Hardware die entweder OpenGL 2 oder OpenGL ES 2.0 unterstützt. Das ist so ziemlich jedes moderne Smartphone und auch jede Grafikkarte der letzten Jahre.
Persönlich betrachte ich WebGL als den größten Durchbruch im Web Bereich der letzten Jahre und als viel wichtiger als HTML 5. WebGL hat das Potential eine neue Ära einzuleiten. Vor allem im Bereich der Web basierten Spiele sehe ich ein unglaubliches Potential für diese Technologie. Aktuell wird für vieles immer noch Flash verwendet, was größtenteils über die CPU ineffizient rendert. Aber auch viele Webdienste wie z.B. Kartendienste können von 3D Beschleunigung profitieren.
OpenGL ist der offene Industriestandard für 3D Grafik und steht in direkter Konkurrenz zu einer proprietären API, welche nur von einem Softwarehersteller kontrolliert wird. Mit OpenGL laufen Anwendungen auf allen verfügbaren PC Plattformen, mit OpenGL ES 2.0 ist der boomende Markt der Smartphones und Tablets abgedeckt, auf dem es noch keinen konkurrierenden Standard gibt und mit WebGL betritt OpenGL erneut einen Bereich in dem es noch keinen vergleichbaren Standard gibt. Es ist erfreulich zu sehen, dass der offene Standard hier vor der Konkurrenz ist und die Technologie vorantreibt.
Sollte WebGL sich als bevorzugter Vermarktungsweg für moderne Spiele durchsetzen, wäre dies ein schwerer Schlag für die konkurrierende API und den Webbrowser des selben Herstellers, der WebGLnicht unterstützt. OpenGL Anwendungen würden ohne jegliche Anpassung auf allen verfügbaren Plattformen über den Webbrowser laufen, sämtlicher Portierungsaufwand entfällt komplett. Zusätzlich gibt es dem Hersteller der Anwendung ein bewehrtes Distributionsmedium (das Web) in die Hand.
Zuletzt hörte man einiges an Kritik bezüglich der Sicherheit von WebGL (z.B.
bei fefe), vor allem möchte der Konkurrent von OpenGL, WebGL nicht in seinen Webbrowser einbauen aus
Sicherheitsgründen. Die Sicherheitsproblematik läuft zusammen auf die Tatsache, dass Anwendungen aus dem Web Zugriff auf die lokale Hardware bekommen und nativen Code ausführen können. Zusätzlich gibt es auch (noch) keine
Sandbox um den Code abzuschotten und da auf die Hardware zugegriffen werden kann, wird auch einiges des Codes im Kernelmode ausgeführt.
Das ist soweit natürlich alles korrekt, nur macht es die Technologie WebGL grundsätzlich nicht zu einem Sicherheitsproblem. OpenGL für sich ist eigentlich eine riesige Sandbox. OpenGL ist ein
Zustandsautomat bei dem die eigentliche API nur dazu da ist den Zustand zu setzen. Also zum Beispiel eine Textur zu laden und anzugeben, dass die nächsten Zeichenbefehle diese Textur verwenden sollen. Das eigentliche Zeichnen der Geometrie erfolgt mit sogenannten
Shadern. Es gibt dabei einen Vertexshader zum Umwandeln von Vertices im Anwendungskoordinatensystem nach Clipcoordinaten und den Fragmentshader um jedes vom Vertexshader bestimmte Fragment zu zeichnen. OpenGL verwendet zur Programmierung dieser zwei Shader Zustände eine eigene Programmiersprache namens
OpenGL Shading Language (GLSL).
GLSL ist eine sehr
domain spezifische Sprache speziell für die Anforderungen der 3D Grafikprogrammierung. Der Vertexshader bekommt als Eingabewerte Attribute pro Vertex und als Ausgabewerte liefert er variierende Werte, die an den Fragmentshader weitergegeben werden und als Eingabeparameter verwendet werden. Der Fragmentshader produziert nun einen Farbwert. Zusätzlich können beide Shader auf gemeinsamen Speicher zugreifen: auf den OpenGL Zustand über sogenannte “uniform” Werte und auf Texturen.
Die Shader in GLSL werden vom OpenGL Treiber in hardwarespezifischen Assemblercode kompiliert. Der Compiler sollte dabei sicherstellen, dass der Code nichts machen kann, was OpenGL nicht erlaubt, also z.B. auf Speicher außerhalb des Kontexts zuzugreifen. Jede Textur und auch jeder Shader wird nämlich in einem Kontext erstellt und ein Objekt darf nur auf Objekte des selben Kontexts zugreifen. Wenn der Shader vom Treiber nicht kompiliert werden kann, so wird ein Fehler zurückgeliefert auf den der Anwendungscode reagieren muss.
Die Technologie WebGL ist also selbst die Sandbox, die angeblich nicht existiert. Ein Shader kann nur graphikspezifischen Code ausführen und es wäre mir auch noch kein Fall bekannt, bei dem GPU Code auf die CPU “ausbrechen” könnte. Die einzige verbleibende Gefahr wäre somit das setzen der Zustände um den Shader auszuführen. Dabei besteht eigentlich auch kein Problem, denn OpenGL ist sehr fehlertolerant und bei einem fehlerhaften Ansprechen der API wird ein GL_ERROR zurückgeliefert was im schlimmsten Fall zu Darstellungsfehlern führt. Die OpenGL API ist somit auch Bestandteil der Sandbox.
Wie wir sehen bietet die Technologie WebGL außreichend Sicherheit. Mittels der Technologie ist es nicht möglich Schadprogramme auf den Client zu bekommen. Die Vorwürfe gegenüber der Technologie sind daher einfach falsch.
Anders sieht es mit den Implementierungen aus. In der Theorie sollte OpenGL sicher sein, jedoch kann ich aus eigener Erfahrung sagen, dass dies nicht der Fall ist. Alle Treiber (egal ob offen oder proprietär) haben Fehler und können die Anwendung zum Absturz bringen, bei legalen und illegalen OpenGL Befehlssequenzen. Somit ist ein Angriffspotential denkbar: ist man in der Lage über die richtigen Befehle in WebGL den Treiber zum Absturz zu bekommen, kann man im schlimmsten Fall Code auf der CPU ausführen. Dies ist ein reales Angriffsszenario, dessen sich die Browserhersteller bewusst sind. So hatte ein Mozilla Entwickler vor der Veröffentlichung von Firefox 4 z.B. auf der KWin Mailingliste nach den Erfahrungen zur Stabilität insbesondere der freien Treiber nachgefragt.
Von dem theorethischen Angriffsszcnario zu einem Exploit ist es dennoch ein weiter und meiner Meinung nach sehr unwahrscheinlicher Weg. Zum einen ist es schwer den OpenGL Treiber gezielt zum Absturz zu bringen, zum anderen diesen Absturz zum Angriff auszunutzen. Abstürze lassen sich nach der Erfahrung mit KWin meistens nur in einer bestimmten Kombination von OpenGL Befehlen, Treiberversion und Hardware erreichen. Ein Angreifer müsste also den Angriff speziell auf Hardware und Treiber zurechtschneiden. Natürlich wäre solch ein Fall dann eine Möglichkeit den Browser remote abstürzen zu lassen, dies ist natürlich schon einmal sehr schlecht, lässt sich aber von Browserherstellerseite sehr leicht beheben indem WebGL Kontexte in einen eigenen Prozess ausgelagert werden.
Die viel größere Schwierigkeit dürfte sein den Crash zum Angriff auszunutzen. Außer GLSL (was ja nicht auf der CPU sondern GPU ausgeführt wird) gibt es keine Codebestandteile, die direkt ausgeführt werden. Die WebGL API zum Setzen des OpenGL Zustands verwendet JavaScript und sollte somit vom restlichen System abgeschottet sein. Die API selbst erlaubt auch ausschließlich nur das Setzen der Zustände. Die einizige Möglichkeit größere Speichermengen über Buffer anzusprechen (um zum Beispiel Angriffscode abzulegen) ist das Laden von Texturen was jedoch in der WebGL API im Vergleich zur OpenGL C-API abgesichert wurde.
Falls es mittels Texturen und OpenGL API möglich ist einen Treiber so zum Absturz zu bekommen, dass Code ausgeführt werden kann, so ist das ein grundsätzliches Problem was nichts mit der Technologie WebGL zu tun hat. Moderne Webbrowser verwenden OpenGL auch zum Rendern der Canvas womit es denkbar ist, dass durch das einfache Einbinden desselben gefährlichen Bildes der Browser zum Absturz gebracht werden kann und der Schadcode ausgeführt werden kann.
Wie wir sehen ist der Vorwurf gegenüber der Technologie WebGL nicht sicher zu sein, schlicht falsch. Genaugenommen betrifft es nur sich fehlverhaltende Implementierungen deren Schwachstellen generell ausgenutzt werden können, egal ob es sich um WebGL, hardwarebeschleunigtes Rendern der HTML Canvas oder harwarebeschleunigtes Flash oder Silverlight handelt. WebGL ist hier im Vergleich zu anderen Lösungen wie hardwarebeschleunigtes Flash sogar besser, da es sich abschotten lassen kann.
Ich möchte hier nicht sagen, dass der Einsatz von WebGL ungefährlich ist. Sicherlich besteht durch die Instabilität der OpenGL Implementierungen und der recht neue Einsatz in Webbrowsern ein Gefährdung. Jedoch betrifft diese alle Technologien, die auf OpenGL (oder auch Direct3D) zugreifen. Das Argument des Konkurrenzherstellers klingt daher für mich als vorgeschoben und nach FUD um der Konkurrenz zu schaden und die konkurrierende API nicht im eigenen Webbrowser einsetzen zu müssen.
=-=-=-=-=
Powered by Blogilo
