Frage:
Ist WebGL ein Sicherheitsrisiko?
user9148
2012-04-16 08:16:28 UTC
view on stackexchange narkive permalink

Ist WebGL aufgrund des von ihm bereitgestellten Zugriffs auf niedriger Ebene 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.

Fünf antworten:
D.W.
2012-04-17 03:22:20 UTC
view on stackexchange narkive permalink

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.

Ein großes Risiko besteht darin, dass WebGL die direkte Ausführung von Code beinhaltet die Grafikkarte und Offenlegen von APIs, 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 voll 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 befasste Browser zu der Zeit und fand eine Reihe von Schwachstellen. 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, in der das Vorhandensein dieser Sicherheitslücken in einer Reihe von Browsern und Webkarten (zu diesem Zeitpunkt) nachgewiesen wurde.

Browser haben darauf mit einer Vielzahl von Antworten reagiert Verteidigung: 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 Richtlinie eingeschränkt, um zu verhindern, dass eine böswillige Website WebGL verwendet, um die Nutzung anderer Websites durch Benutzer auszuspionieren.

Es gibt einige laufende Debatten darüber, ob sich diese Abwehrkräfte langfristig als angemessen erweisen werden. Microsoft hat die Position vertreten, dass WebGL ein zu großes Sicherheitsrisiko darstellt und die vorhandenen Abwehrmechanismen nicht robust genug sind. 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 verleiht. Ars Technica hat eine hervorragende Zusammenfassung des Themas; 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, in dem diese Argumente bereits behandelt werden. (Siehe auch Chrome vs Explorer - wie kann man in einfachen Worten erklären, dass Open Source besser ist? für weitere nachdenkliche Diskussionen zu diesem Thema.)

Benoit Jacob
2012-04-30 17:40:15 UTC
view on stackexchange narkive permalink

Einige wichtige Punkte:

  • WebGL setzt OpenGL nicht nur JavaScript aus. Alle Einstiegspunkte wurden eingeschränkt, um die Möglichkeit 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 ist). Mit li>
  • 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.
  • In einer WebGL-Spezifikation gab es immer nur genau eine Sicherheitslücke: Die WebGL-Spezifikation erlaubte ursprünglich die Verwendung von cross -origin Bilder 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 /
Lucas Kauffman
2012-04-16 10:55:35 UTC
view on stackexchange narkive permalink

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

Sie, Sir, liegen sehr falsch . Es hat sich oft bewährt, dass OpenSource-Programme oft viel sicherer sind als Closed-Source-Programme, da viel mehr Augen den Code überprüfen.

Auch alle Browser führen 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.

Michael Slade
2012-04-30 19:24:22 UTC
view on stackexchange narkive permalink

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, ist von geringer Bedeutung. Das daraus resultierende Potenzial für Sicherheitslücken ist immer noch vorhanden.

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

Es gibt Faktoren, die diese einfache Ansicht 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. usw. usw.

Dominic Cerisano
2017-06-04 02:59:44 UTC
view on stackexchange narkive permalink

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 bei externen Grafikchipsätzen über einen eigenen Speicher zu verfügen. Dies ist ein potenzielles Informationssicherheitsrisiko.

Leistungshungrige Parallelprozessoren wie GPUs eignen sich 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, Es ist sehr wahrscheinlich, dass auf Ihrer GPU Webgl-Code ausgeführt wird. 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.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...