WebGL, maillon faible de la sécurité
WebGL est une technologie promue par le Khronos Group, qui permet d'exploiter les capacités des cartes graphiques, tant dans l'affichage de modèles 3D que de calcul générique par le GPU, à l'intérieur même de pages web.
Mais qui dit exécution de code dit problème de sécurité : alors que les développeurs de navigateurs s'échinent à confiner toute possibilité de marquer la mémoire comme étant exécutable, WebGL ouvrirait grand la fenêtre juste à côté de la porte condamnée. D'autre part, l'accès direct au matériel par le code stocké dans une page web pourrait faire office de porte dérobée, alors que le navigateur s'efforce de jouer les garde-fous. L'injection d'images dans l'affichage d'une page innocente par une page coupable (ou à l'inverse leur aspiration d'une page à l'autre) peut tromper l'utilisateur, on peut également causer le plantage de l'ordinateur, etc.
C'est le constat réalisé par Context, un cabinet spécialisé en sécurité, qui en conclut qu'en dépit du réel besoin que WebGL est susceptible de satisfaire, celui-ci n'est pour l'heure pas prêt pour l'utilisation de masse. Context recommande sa désactivation par les gestionnaires de parc informatique.
En cause, les pilotes des cartes graphiques, dont les constructeurs n'avaient pas vraiment eu affaire à du code susceptible d'être d'origine douteuse jusqu'ici. Le Khronos Group a publié en réponse de molles dénégations, expliquant qu'une extension d'OpenGL a d'ores et déjà été mise sur pied pour répondre à ce problème, et qu'elle n'attend plus que son implémentation dans les pilotes de cartes graphiques.
Le cabinet Context ne se dit pas satisfait par la réponse du Khronos Group, qui placerait entre les mains des seuls fabricants la sécurité des contenus en ligne, et ils n'ont que peu d'intérêt direct à s'investir sur ces questions. A l'heure actuelle, seuls Chrome, Firefox, et les nightly builds de Webkit intègrent WebGL.
Mais qui dit exécution de code dit problème de sécurité : alors que les développeurs de navigateurs s'échinent à confiner toute possibilité de marquer la mémoire comme étant exécutable, WebGL ouvrirait grand la fenêtre juste à côté de la porte condamnée. D'autre part, l'accès direct au matériel par le code stocké dans une page web pourrait faire office de porte dérobée, alors que le navigateur s'efforce de jouer les garde-fous. L'injection d'images dans l'affichage d'une page innocente par une page coupable (ou à l'inverse leur aspiration d'une page à l'autre) peut tromper l'utilisateur, on peut également causer le plantage de l'ordinateur, etc.
C'est le constat réalisé par Context, un cabinet spécialisé en sécurité, qui en conclut qu'en dépit du réel besoin que WebGL est susceptible de satisfaire, celui-ci n'est pour l'heure pas prêt pour l'utilisation de masse. Context recommande sa désactivation par les gestionnaires de parc informatique.
En cause, les pilotes des cartes graphiques, dont les constructeurs n'avaient pas vraiment eu affaire à du code susceptible d'être d'origine douteuse jusqu'ici. Le Khronos Group a publié en réponse de molles dénégations, expliquant qu'une extension d'OpenGL a d'ores et déjà été mise sur pied pour répondre à ce problème, et qu'elle n'attend plus que son implémentation dans les pilotes de cartes graphiques.
Le cabinet Context ne se dit pas satisfait par la réponse du Khronos Group, qui placerait entre les mains des seuls fabricants la sécurité des contenus en ligne, et ils n'ont que peu d'intérêt direct à s'investir sur ces questions. A l'heure actuelle, seuls Chrome, Firefox, et les nightly builds de Webkit intègrent WebGL.
L'HTML5 est vraiment fait pour simplifier la vie on dirait…
Il me semble que le HTML 5, en lui même, n'implémente pas WebGL mais que l'on peut l'utiliser par l'intermédiaire de la balise "canvas".
Bah merde ... je pensais que seul Flash avait des failles de sécurité .... on m'aurait menti ??? heumheum
@BioSS :
L'HTML5 et WebGL peuvent fonctionner ensemble, mais l'un n'est PAS l'autre. Je sens poindre une tentative de troll, après toutes les discussions qui ont eu lieu sur ce site (et ailleurs) au sujet de Flash et de son rejet par Apple pour ses iDevices.
Tentative de troll
La même chose s'applique à tout code exécutable récupéré de "ailleurs"
Qu'il soit du Javascript compilé natif, native code de Google (du c compilé et fourni au navigateur), du flash ou autre.
-
Oui, il faut que le matériel soit restreint si on le met en face de code en qui on n'a pas confiance.
-
Cela fait un petit moment que les cartes video intègrent les pratiques des processeurs et bus génériques. En voila une de plus à prendre en compte : le code n'est pas digne de confiance.
Je m'en cogne qu'Apple ou autre refuse Flash, mais qu'on vienne pas dire que Flash est responsable de tous les maux de la terre parce qu'il a des failles de sécurité ... comme dit Oomu ... la même chose s'applique partout ....
Je moque juste certaines grandes gueules qui ne trouvait rien d'autre à dire que ... "oh bah merde Adobe et Flash sont vraiment caca car il y a des failles de sécurité en plus !!!" .... :)
"dont les constructeurs n'avaient pas vraiment eu affaire à du code susceptible d'être d'origine douteuse jusqu'ici."
Y a pas besoin d'avoir du code douteux pour faire kernel panicer un Mac avec de l'OpenGL selon les releases.
@ cdou59 : Flash n'est pas responsable de tous les maux de la terre, mais seulement responsable du fait d'être mal implémenté et optimisé avec les pieds sur Macintosh. De plus, les tentatives d'optimisation qui ont été faites par Adobe concernent uniquement la lecture de vidéos. Mais il n'y a pas que les vidéos dans Flash ! C'est Flash en soit qui n'est pas optimisé du tout sur les plateformes autres que Windows. Rien de plus, rien de moins, mais c'est déjà trop.