Je suis un peu gêné par tes propos car tu exposes un problème générale comme si ca provenais de WebGL.
Tu peux réaliser du DoS avec un peu n'importe quoi... Ca à déjà été fait avec les décodeurs jpeg, j'en avais même trouvé un dans le format WebP alors que je ne me considère pas comme un codeur fou (et pour mon plus grand malheur avait déjà été reporté :) ou le javascript lorsque l'interpréteur ou le compilateur JIT à des bugs!
OpenGL n'a jamais été conçu dans un contexte Web
Vous rencontrez des problèmes spécifiques à la spec OpenGL
WebGL est une adaptation d'OpenGL ES pour le web, je ne vois pas le problème. Ca reviendrait à dire que le java ne peut pas être intégré comme langage web (quoi dart? ;) ou que le JS ne peut pas faire du serveur (nodejs). Bien sûr, il faut ajouter ou enlever quelques fonctionnalités et le résultat sera plus ou moins adapté, mais c'est toujours possible.
Vous exposez de nouvelles API qui interagissent avec le matos, plus difficilement contrôlable par l'OS,
Si c'est difficile et ajoute un risque, on ne doit rien faire? Dans ce cas les compilateurs JIT des moteurs javascript ne devraient pas exister. D'autant plus que, si j'ai bien compris, le vrai problème ne se situe pas vraiment au niveau de l'OS mais des drivers mal fait, drivers qui sont blacklisté et désactive WebGL. On a déjà vue pire pour des drivers réseaux et c'est hautement plus crucial car faire planter serveur ca n'a pas le même impact qu'un poste client. Du coups, je débranche internet?
A noter que les sources de WebGL (les shaders) sont aussi compilé à la volé, un peu comme le javascript donc il est possible de le rendre parfaitement sécurisé, soit en faisant des vérifications formelles soit en ajoutant des watch sur les opcodes bas niveau ou un mix des deux. Le problème, j’imagine, c'est que les fabricants doivent préférer le faire eux même car ca impacte beaucoup les performances. Je crois qu' ANGLE* fait une partie de ces vérifications (*la lib ajoutant OpenGL ES au dessus de directX)
bref, vous élargissez l'exposition en terme de sécurité.
C'est le cas pour toutes nouvelles fonctionnalités et pas seulement dans le monde du navigateur mais aussi dans le kernel, les solutions de virtualisations (oui je triche, un navigateur c'est un OS virtualisé pour moi)...
Je ne sais pas si j'ai été clair et je m'excuse si ce n'est pas le cas : j'ai tendance à m'égarer dans mes propos.
[^] # Re: ca fait peur
Posté par tallion . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing". Évalué à 3.
Je suis un peu gêné par tes propos car tu exposes un problème générale comme si ca provenais de WebGL.
Tu peux réaliser du DoS avec un peu n'importe quoi... Ca à déjà été fait avec les décodeurs jpeg, j'en avais même trouvé un dans le format WebP alors que je ne me considère pas comme un codeur fou (et pour mon plus grand malheur avait déjà été reporté :) ou le javascript lorsque l'interpréteur ou le compilateur JIT à des bugs!
WebGL est une adaptation d'OpenGL ES pour le web, je ne vois pas le problème. Ca reviendrait à dire que le java ne peut pas être intégré comme langage web (quoi dart? ;) ou que le JS ne peut pas faire du serveur (nodejs). Bien sûr, il faut ajouter ou enlever quelques fonctionnalités et le résultat sera plus ou moins adapté, mais c'est toujours possible.
Si c'est difficile et ajoute un risque, on ne doit rien faire? Dans ce cas les compilateurs JIT des moteurs javascript ne devraient pas exister. D'autant plus que, si j'ai bien compris, le vrai problème ne se situe pas vraiment au niveau de l'OS mais des drivers mal fait, drivers qui sont blacklisté et désactive WebGL. On a déjà vue pire pour des drivers réseaux et c'est hautement plus crucial car faire planter serveur ca n'a pas le même impact qu'un poste client. Du coups, je débranche internet?
A noter que les sources de WebGL (les shaders) sont aussi compilé à la volé, un peu comme le javascript donc il est possible de le rendre parfaitement sécurisé, soit en faisant des vérifications formelles soit en ajoutant des watch sur les opcodes bas niveau ou un mix des deux. Le problème, j’imagine, c'est que les fabricants doivent préférer le faire eux même car ca impacte beaucoup les performances. Je crois qu' ANGLE* fait une partie de ces vérifications (*la lib ajoutant OpenGL ES au dessus de directX)
C'est le cas pour toutes nouvelles fonctionnalités et pas seulement dans le monde du navigateur mais aussi dans le kernel, les solutions de virtualisations (oui je triche, un navigateur c'est un OS virtualisé pour moi)...
Je ne sais pas si j'ai été clair et je m'excuse si ce n'est pas le cas : j'ai tendance à m'égarer dans mes propos.