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
Danke für die Ausführungen. Sehr aufschlussreich und nachvollziehbar.
Als ich gelesen hab, dass da ein Browser Hersteller davor warnt und die Technologie nicht in den eigenen Browser einbauen will hab ich mir sowieso schon meinen Teil gedacht. Ich hoffe, der Schuss geht nach hinten los.
Wahrscheinlich wird der genannte Browserhersteller mit seiner eigenen Technik kommen, die nur unter seinem eigenen Betriebssystem läuft. Ich hoffe auch, dass dies wie ActiveX und Silverlight nie große Bedeutung erlangen wird.
Bei dem fallenden Marktanteil vom IE kann sich MS sowas eigentlich nicht leisten. Das wäre vor 3-4 Jahren vielleicht noch möglich gewesen
Hallo,
der Schuss wird nicht nach hinten losgehen, die Erfahrungen in der Vergangenheit haben gezeigt das dieses Unternehmen sich immer durchgesetzt hat und den Markt vorschreibt was Norm ist.
Dies ist meine Meinung und kann daher von anderen abweichen.
Danke Martin für die ausführliche Erklärung von WebGL, lese deine Blog’s immer wieder gerne.
Gruß Volker
Lustig, dass im letzten Absatz noch das Wort Direct3D fällt. Guter Artikel!
Echt gut erklärt! Danke für die Arbeit!
Echt gut erklärt! Danke für deine Arbeit und alles!
Eine gute Erklärung, aber auch mangelhaft. Immer dann, wenn die technische Erklärung fehlt, wird auf Annahmen und Vermutungen gesetzt – die natürlich nur eine einzige Interpretationsrichtung kennen. So wird vermutet, dass sich der OpenGL Treibner nicht einfach zum Absturz bringen lässt. Außerdem ist die Annahme, dass WebGL eben durch Aufsetzen auf die OpenGL API auch eine Sandbox ist, vollkommen falsch. WebGL nutzt gerade nicht dieses Konzept, sondern implementiert einen eigenen Layer, der nur bedingt abstrahiert ist. Um die Sandbox wird herumprogrammiert und das wird ja auch ohne Umschweife zugegeben. Wie man dann zu der Einschätzung kommen kann, dass hier eine Sandbox vorliege, bleibt mit unerklärlich.
Ich schreibe doch ganz klar, dass die Treiber zum Absturz gebracht werden können, dass die Implementierungen fehlerhaft sind. Jedoch OpenGL selbst darf unter keinem Fall abstürzen. Ich unterscheide hier sehr deutlich zwischen Technologie und der Implementierung der Technologie. Ich glaube du solltest den Artikel noch einmal lesen.
Sorry – der Treiber darf auch unter keinen Umständen abstürzen. Das Beharren auf OpenGL in dem ZH ist doch Unsinn. Du hast doch lange genug Informatik studiert um das OSI Modell zu verstehen!
Wenn dir der Treiber wegbricht, dann nutzt dir ein vermeintlich herumexistierender Prozess, der noch schon versucht, irgend etwas zu zeichen, reichlich wenig. Dein Device ist flöten und das EWinzige, was du noch kreieren kannst, sind Zombies.
Und dass du zwischen Theorie und Praxis unterscheidest, ist ganz schön, aber auch wieder mangelhaft. Es gibt wunderbare Theorien zu verschiedensten Dingen, die nur leider in der Praxis nicht umsetzbar sind. Was nutzt es dir dann? Und jatzt darüber zu diskutieren, dass der theoretische Ansatz ja ganz fein ist, nur die Entwickler wieder einmal die Bösen seien, ist verfehlt. Offenbar ist zumindest bei dem derzeitigen Stand der Technik WebGL (und darum geht es hier ja, der permanente Verweis auf OpenGL erscheint mir eher aus Ausflucht) eben noch nicht alles im Reinen – eben weil man verschiedene Krücken und Umgehungen zu bekannten, sichereren (wohlgemerkt: nicht sicheren!) Lösungen eingebaut hat. So ganz Unrecht haben fefe & Co. eben hier nicht.
Ich stimme dir voll und ganz zu, dass der Treiber niemals abstürzen darf! Niemals bei der Benutzung von WebGL, dem Rendern von Webseiten ohne WebGL, nicht bei der Benutzung von Flash, nicht bei der Benutzung von Silverlight und auch nicht bei der Benutzung von ActiveX Elementen oder sonst was. Wenn der Treiber zum Absturz gebracht werden kann, dann ist das unabhängig von WebGL! Die Technologie WebGL (JavaScript Bindings für OpenGL) ist also nicht mehr und nicht weniger unsicher als jede andere Technik, die es erlaubt remote Inhalte über OpenGL zu renderen.
Der Hersteller der Konkurrenztechnologie sieht seine Felle davon schwimmen und greift daher auf vermeintlich bewährte FUD-Marketing Taktik zurück.
Sicherheitsprobleme können selbstverständlich auftreten, und zwar immer dann, wenn man bekannte Fehler ausnutzt. Aber das trifft eben auf alle Technologien zu, und wir alle wissen, welche Technologien davon am häufigsten betroffen sind.
Aber nehmen wir mal Googles Chromebooks: Hier ist die Gefahr besonders groß, da ja Treiber und Hardware gut bekannt sind, daher könnten sich Malware-Produzenten erfolgreiche Chromebooks als potentielles Ziel aussuchen. Das trifft aber auch auf iPads zu, wo Hardware und Treiber auch bekannt sind.
Im Grunde haben die Kritiker mit den Anmerkungen zur Sicherheit schon recht – allerdings darf sich diese Kritik dann nicht nur auf WebGL beziehen, sondern muss alle ähnlichen Techniken auch mit einbeziehen – wie Martin ja korrekterweise angemerkt hat.
Ich denke, das Grundproblem ist ganz einfach: Ich kann entweder eine abstrahierte, virtualisierte und abgesicherte Umgebung haben – oder den direkten Hardware-Zugriff. Beides zusammen geht nun mal nicht. Natürlich kann man jetzt darüber streiten, ob es so schlau ist, dem “Internet” direkten, programmierbaren Zugriff auf (in diesem Fall die Grafik-) Hardware zu geben – aber wenn ich coole, beschleunigte 3D-Grafik und Videos im Web haben will, geht es halt nicht anders.
Das Ganze fällt massiv auf die Treiber zurück, die in der Diskussion bisher IMHO ein bisschen zu kurz gekommen sind. Je mehr programmierbare Funktionen in die Grafikkarte wandern, desto mehr muss der Treiber ja quasi Betriebssystem-ähnliche Funktionen übernehmen. Früher oder später werden da auch die Hersteller nicht umhin kommen, Sicherheitsaspekte zu berücksichtigen.