WebGL est-il un problème de sécurité?
WebGL est-il un problème de sécurité potentiel en raison de l'accès de bas niveau qu'il fournit?
Par exemple, une page Web peut tenter de compiler et d'exécuter n'importe quelle source de shader qu'elle souhaite.
Il semble que la sécurité serait particulièrement un problème avec les navigateurs Web open source, car un attaquant pourrait plus facilement trouver des vulnérabilités dans la mise en œuvre.
Oui, WebGL est en effet un risque potentiel pour la sécurité, bien que l'ampleur du risque soit difficile à évaluer et à débattre. Il y a quelques problèmes délicats ici. Les navigateurs ont mis en place des défenses contre les risques de sécurité, mais il semble y avoir un débat quant à savoir si ces défenses s'avéreront adéquates à long terme.
Un risque majeur est que WebGL implique d'exécuter du code directement sur la carte vidéo et d'exposer des API qui fournissent un accès direct aux API de carte vidéo. Le navigateur tente de mettre en sandbox ce code (dans une certaine mesure), et les navigateurs appliquent un certain nombre de restrictions de sécurité conçues pour empêcher les comportements malveillants. Cependant, bon nombre de ces API et leurs implémentations n'ont pas été initialement conçues pour être fournies à des entités non fiables (elles n'étaient utilisables que par des applications natives, qui sont entièrement fiables), donc il est à se demander si les exposer à des sites Web arbitraires pourrait activer des sites Web. pour attaquer votre système.
Il y avait n livre blanc à haute visibilité (voir aussi la suite ) qui a examiné la sécurité de l'implémentation de WebGL dans les navigateurs à l'époque, et a trouvé un certain nombre de vulnérabilités. Ils ont trouvé des problèmes de sécurité de la mémoire dans plusieurs API WebGL et ont également trouvé des attaques qui permettraient à un site Web de lire les données de pixels d'autres sites Web (ce qui pourrait permettre une violation de la confidentialité). Voir aussi cette troisième étude , qui a démontré l'existence de ces vulnérabilités sur un certain nombre de navigateurs et de cartes Web (à l'époque).
Les navigateurs ont répondu à cela par diverses défenses: ils ont mis sur liste noire les cartes vidéo présentant des problèmes de sécurité connus; ils ont essayé de résoudre les problèmes connus de sécurité de la mémoire; et ils ont restreint l'utilisation de WebGL selon la même politique d'origine , pour empêcher un site Web malveillant de en utilisant WebGL pour espionner l'utilisation par les utilisateurs d'autres sites Web .
Il y a un débat en cours pour savoir si ces défenses s'avéreront adéquates à long terme. Microsoft a pris la position que WebGL est un risque de sécurité trop grand et les défenses existantes ne sont pas assez robustes . D'un autre côté, Mozilla est d'avis que les défenses qu'ils ont mises en place seront adéquates et que WebGL apporte une valeur importante au Web. Ars Technica a n excellent résumé du problème ; et voici un autre rapport de presse .
P.S. Je suis totalement en désaccord avec votre affirmation selon laquelle cela pose particulièrement problème pour les navigateurs Web open source. Voilà un mythe. Voir Open Source vs Closed Source Systems , qui couvre déjà ces arguments. (Voir aussi Chrome vs Explorer - comment expliquer en termes simples que l'open source est mieux? pour une discussion approfondie supplémentaire sur ce sujet.)
Quelques points clés:
- WebGL n'expose pas seulement OpenGL à JavaScript. Tous les points d'entrée ont été restreints pour supprimer les possibilités d'accès à la mémoire hors des limites, de sorte qu'il est toujours possible pour le navigateur de vérifier les accès hors des limites (et cela est couvert par des tests de conformité).
- WebGL permet d'exécuter des shaders presque arbitraires sur le GPU. Cependant, gardez à l'esprit que les shaders ne sont pas du code polyvalent arbitraire. Ils ne peuvent accéder qu'à une mémoire très spécifique de manière à ce que les navigateurs vérifient les accès hors limites. Les shaders sont validés et traduits par un compilateur de shaders intégré dans le navigateur avant d'être transmis au pilote GPU.
- Il n'y avait jamais qu'un seul défaut de sécurité dans une spécification WebGL: la spécification WebGL permettait à l'origine l'utilisation d'images d'origine croisée en tant que textures WebGL, et il a été démontré qu'une attaque temporelle pouvait réussir à les lire. Cela a été corrigé à la mi-2011 et la version actuelle de la spécification WebGL, 1.0.1, est sécurisée.
- Plus d'informations sur la sécurité WebGL peuvent être trouvées ici: http://www.khronos.org/webgl/security/
Il semble que la sécurité serait particulièrement un problème avec les navigateurs Web open source.
Vous êtes monsieur très mal. Il a été prouvé à maintes reprises que les programmes open source sont souvent beaucoup plus sécurisés que ceux fermés, car il y a beaucoup plus d'yeux qui vérifient le code.
De plus, tous les navigateurs exécutent ces choses dans un bac à sable. Sortir du bac à sable sera difficile, mais ce sera autant un problème dans les sources fermées que dans les navigateurs open source.
Comparons WebGL avec javascript.
La différence critique entre (code de shader exécuté via) WebGL et javascript est que le code de shader est exécuté sur la carte GPU, tandis que javascript est exécuté sur le CPU.
Que le code soit interprété ou compilé n'a que peu d'importance; le potentiel de vulnérabilités qui en résulte est toujours là.
Ainsi, javascript a plus de capacité d'abus, car une fois qu'un script escroc sort de la prison du navigateur, il a essentiellement accès à votre PC. Un script shader WebGL voyou pourrait avoir, euh, accès à votre GPU.
Il y a des facteurs qui compliquent cette vision simple; javascript existe depuis un certain temps, il a donc fait l'objet d'un examen plus approfondi et a fermé davantage de trous. javascript est beaucoup plus compliqué. Javascript en tant que langue est beaucoup plus compliqué. etc.
WebGL permet d'accéder au pipeline GL vers vos cœurs de GPU. Certains fabricants intègrent des GPU directement sur la puce du processeur. Cela permet au GPU de partager la mémoire interne du processeur, plutôt que d'avoir sa propre mémoire, comme c'est le cas). le cas des chipsets graphiques externes, ce qui représente un risque potentiel pour la sécurité des informations.
Les processeurs parallèles gourmands en énergie comme les GPU sont également idéaux pour les applications de cryptographie.
Il existe de nombreux exemples de bitminers basés sur webgl dans les botnets. Bien qu'ils ne constituent pas une menace pour la sécurité des informations (à l'inverse, les bitminers sont la base de la sécurité des informations de la blockchain), ces botnets volent une quantité stupéfiante d'énergie aux vastes réseaux d'appareils involontaires sur lesquels ils fonctionnent.
Cela signifie que Bitcoin a une empreinte carbone croissante mais largement cachée, ce qui constitue une menace potentielle pour la sécurité environnementale.
Si vous remarquez que certains sites Web ralentissent votre affichage sans augmenter la charge du processeur, il est très probable qu'ils exécutent du code webgl sur votre GPU. Également une cause probable de drains électriques mystérieux sur les appareils mobiles.
Les applications mobiles (comme les navigateurs Web) peuvent exécuter le code GPU perpétuellement en arrière-plan et peuvent nécessiter un redémarrage de l'appareil pour les arrêter.