it-swarm.com.de

Ist WebGL ein Sicherheitsrisiko?

Ist WebGL aufgrund des geringen Zugriffs ein potenzielles Sicherheitsproblem?

Beispielsweise kann eine Webseite versuchen, eine beliebige Shader-Quelle zu kompilieren und auszuführen.

Es scheint, dass die Sicherheit insbesondere bei Open-Source-Webbrowsern ein Problem darstellt, da ein Angreifer Schwachstellen in der Implementierung leichter finden kann.

27
user9148

Ja, WebGL ist in der Tat ein potenzielles Sicherheitsrisiko, obwohl das Ausmaß des Risikos schwer einzuschätzen und zur Debatte zu stellen ist. Hier gibt es einige knifflige Probleme. Die Browser haben einige Schutzmaßnahmen gegen die Sicherheitsrisiken eingerichtet, aber es scheint eine Debatte darüber zu geben, ob sich diese Schutzmaßnahmen auf lange Sicht als angemessen erweisen werden.

Ein großes Risiko besteht darin, dass WebGL das direkte Ausführen von Code auf der Grafikkarte und das Bereitstellen von APIs umfasst, die direkten Zugriff auf Grafikkarten-APIs bieten. Der Browser versucht (bis zu einem gewissen Grad), diesen Code zu sandboxen, und Browser erzwingen eine Reihe von Sicherheitsbeschränkungen, um böswilliges Verhalten zu verhindern. Viele dieser APIs und ihre Implementierungen wurden jedoch ursprünglich nicht für nicht vertrauenswürdige Entitäten bereitgestellt (sie konnten nur von nativen Anwendungen verwendet werden, die vollständig vertrauenswürdig sind). Daher gibt es Bedenken, ob die Bereitstellung von Websites für beliebige Websites Websites ermöglichen könnte um Ihr System anzugreifen.

Es gab ein gut sichtbares Whitepaper (siehe auch die Fortsetzung ), das sich mit der Sicherheit der WebGL-Implementierung in Browsern zu dieser Zeit befasste und eine Reihe von Schwachstellen feststellte. Sie fanden einige Probleme mit der Speichersicherheit in mehreren WebGL-APIs und auch einige Angriffe, die es einer Website ermöglichen würden, Pixeldaten anderer Websites zu lesen (was eine Verletzung der Vertraulichkeit ermöglichen könnte). Siehe auch diese dritte Studie , die das Vorhandensein dieser Sicherheitslücken in einer Reihe von Browsern und Webkarten (zu dieser Zeit) demonstrierte.

Browser haben darauf mit einer Reihe von Abwehrmaßnahmen reagiert: Sie haben Grafikkarten mit bekannten Sicherheitsproblemen auf die schwarze Liste gesetzt. Sie haben versucht, die bekannten Probleme mit der Speichersicherheit zu beheben. und sie haben die Verwendung von WebGL gemäß derselben Origin-Richtlinie eingeschränkt , um zu verhindern, dass --- eine böswillige Website mit WebGL die Nutzung anderer Websites durch Benutzer ausspioniert .

Es gibt einige laufende Debatten darüber, ob sich diese Abwehrkräfte langfristig als angemessen erweisen werden. Microsoft hat die Position vertreten, dass WebGL ist ein zu großes Sicherheitsrisiko und die vorhandenen Abwehrmechanismen sind nicht robust genug . Auf der anderen Seite vertritt Mozilla die Position, dass die von ihnen eingerichteten Abwehrmaßnahmen angemessen sind und dass WebGL dem Web einen wichtigen Wert bietet. Ars Technica hat eine hervorragende Zusammenfassung des Problems ; und hier ist ein weiterer Pressebericht .

P.S. Ich bin völlig anderer Meinung als Ihre Aussage, dass dies insbesondere für Open Source-Webbrowser ein Problem darstellt. Das ist ein Mythos. Siehe Open Source vs Closed Source Systems , das diese Argumente bereits behandelt. (Siehe auch Chrome vs Explorer - wie kann man in einfachen Worten erklären, dass Open Source besser ist? für zusätzliche nachdenkliche Diskussionen zu diesem Thema.)

31
D.W.

Einige wichtige Punkte:

  • WebGL setzt OpenGL nicht nur JavaScript aus. Alle Einstiegspunkte wurden eingeschränkt, um Möglichkeiten von Speicherzugriffen außerhalb der Grenzen zu entfernen, sodass der Browser immer nach Zugriffen außerhalb der Grenzen suchen kann (und dies durch Konformitätstests abgedeckt wird).
  • Mit WebGL können fast beliebige Shader auf der GPU ausgeführt werden. Beachten Sie jedoch, dass Shader kein willkürlicher Allzweckcode sind. Sie können nur auf eine Weise auf einen bestimmten Speicher zugreifen, die von Browsern auf Zugriff außerhalb der Grenzen überprüft wird. Shader werden von einem im Browser eingebetteten Shader-Compiler validiert und übersetzt, bevor sie an den GPU-Treiber übergeben werden.
  • Es gab immer nur genau eine Sicherheitslücke in einer WebGL-Spezifikation: Die WebGL-Spezifikation erlaubte ursprünglich die Verwendung von Origin-Cross-Bildern als WebGL-Texturen, und es wurde gezeigt, dass ein Timing-Angriff diese erfolgreich lesen konnte. Dies wurde Mitte 2011 korrigiert und die aktuelle Version der WebGL-Spezifikation 1.0.1 ist sicher.
  • Weitere Informationen zur WebGL-Sicherheit finden Sie hier: http://www.khronos.org/webgl/security/
10
Benoit Jacob

Es scheint, dass die Sicherheit besonders bei Open Source-Webbrowsern ein Problem darstellt.

Sie, mein Herr, sind sehr falsch. Es hat sich oft gezeigt, dass OpenSource-Programme oft viel sicherer sind als Closed-Source-Programme, da es viel mehr Augen gibt, die den Code überprüfen.

Außerdem führen alle Browser diese Dinge in einer Sandbox aus. Das Ausbrechen aus der Sandbox wird schwierig sein, aber es wird in Closed Source genauso problematisch sein wie in Open Source Browsern.

3
Lucas Kauffman

Vergleichen wir WebGL mit Javascript.

Der entscheidende Unterschied zwischen (Shader-Code, der über WebGL ausgeführt wird) und Javascript besteht darin, dass der Shader-Code auf der GPU-Karte ausgeführt wird, während Javascript auf der CPU ausgeführt wird.

Ob der Code interpretiert oder kompiliert wird, spielt keine Rolle. Das daraus resultierende Potenzial für Schwachstellen ist immer noch vorhanden.

Javascript hat also mehr Kapazität für Missbrauch, da ein betrügerisches Skript, sobald es aus dem Browser-Gefängnis ausbricht, grundsätzlich Zugriff auf Ihren PC hat. Ein betrügerisches WebGL-Shader-Skript könnte Zugriff auf Ihre GPU erhalten.

Es gibt Faktoren, die diese einfache Sichtweise erschweren. Javascript gibt es schon eine Weile, wurde also genauer unter die Lupe genommen und es wurden mehr Löcher geschlossen. Javascript ist viel komplizierter. Javascript als Sprache ist viel komplizierter. etc etc. etc.

1
Michael Slade

WebGL ermöglicht den Zugriff auf die GL - Pipeline zu Ihren GPU-Kernen. Einige Hersteller integrieren GPUs direkt auf dem CPU-Chip. Dadurch kann die GPU den internen CPU-Speicher gemeinsam nutzen, anstatt wie er ist über einen eigenen Speicher zu verfügen Dies ist ein potenzielles Informationssicherheitsrisiko.

Leistungshungrige Parallelprozessoren wie GPUs sind auch ideal für Kryptografieanwendungen.

Es gibt viele Beispiele für webgl-basierte Bitminer in Botnetzen. Obwohl diese Botnets keine Bedrohung für die Informationssicherheit darstellen (umgekehrt sind Bitminer die Grundlage für die Blockchain-Informationssicherheit), stehlen sie den riesigen Netzwerken unwissender Geräte, auf denen sie ausgeführt werden, eine erstaunliche Menge an Energie.

Dies bedeutet, dass Bitcoin einen wachsenden, aber weitgehend verborgenen CO2-Fußabdruck aufweist, der eine potenzielle Bedrohung für die Umweltsicherheit darstellt.

Wenn Sie jemals bemerken, dass einige Websites Ihre Anzeige verlangsamen, ohne die CPU-Auslastung zu erhöhen, wird höchstwahrscheinlich Webgl-Code auf Ihrer GPU ausgeführt. Auch eine wahrscheinliche Ursache für mysteriöse Stromausfälle bei Mobilgeräten.

Mobile Anwendungen (wie Webbrowser) können GPU-Code ständig im Hintergrund ausführen und erfordern möglicherweise einen Neustart des Geräts, um sie anzuhalten.

0