Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La fondation Mozilla s'attaque aux critiques de Microsoft contre WebGL
Et estime que Silverlight 5 s'expose aux mêmes risques

Le , par Idelways

0PARTAGES

3  1 
Mise à jour du 20/06/2011

Mozilla réagit à la polémique produite par la récente déclaration assassine de Microsoft contre WebGL, le standard Web de production de graphiques 3D accélérés par la carte graphique.

Mike Shaver, vice-président de la stratégie technique de la fondation, rejette en bloc les critiques de Microsoft en raison desquelles l'entreprise annonce n'avoir aucune intention d'implémenter WebGL sur Internet Explorer (lire ci-devant pour plus de détails sur l'annonce de Microsoft)

Pour Shaver, la question relevée par Microsoft ne se pose même pas quant à la nécessité des capacités 3D pour Web. Il rappelle que c'est justement ce que font le plug-in Silverlight (dans sa version 5) et Molehill, le moteur 3D d'Adobe Flash, qui s'exposent aux mêmes risques que ceux soulevés par Microsoft en permettant au code téléchargé de manipuler des parties sensibles du système.

Mike Shaver estime que tout ajout de nouvelles fonctionnalités à une pile logicielle expose les parties existantes aux contenus potentiellement hostiles, un passage obligatoire qu'ont dû endurer selon lui les « moteurs des polices de caractères, les codecs vidéo, les bibliothèques [de rendus] des images... »

Le temps serait donc venu pour que les pilotes graphiques passent la même épreuve.

Ces risques inévitables seront par la suite « modélisés, compris et atténués » reprend-il, prenant pour exemple les stratégies employées par le navigateur Firefox qui se prive par exemple de l'utilisation de certains pilotes graphiques blacklistés.

L'implémentation de WebGL sur Mozilla Firefox, somme toute expérimentale, vérifie en outre la validité du code source des Shaders, et interdit depuis la version 5 le téléchargement des textures à partir d'un domaine autre que celui qui sert le JavaScript qui les appelle.

Des mesures appelées à être renforcées par d'autres en vue de rendre WebGL une « plateforme plus robuste », promet Mike Shaver qui invite Microsoft à s'engager dans le monde WebGL avant de sceller son sort.

Source : blog de Mike Shaver

Et vous ?

Que pensez-vous des contre arguments de Mike Shaver ?
Quelle position vous convainc-t-elle le plus quand à WebGL ? Celle de Microsoft ou celle de Mozilla ?

Microsoft rejette le standard WebGL jugé « dangereux »
Suite à la découverte de multiples failles critiques sur Firefox

L'avenir du standard WebGL sur Internet Explorer s'annonce très incertain.

Microsoft rejette ce standard d'affichage 3D pour le Web, au moins dans sa forme actuelle qu'il juge « dangereuse » dans une dépêche faisant suite à la découverte de plusieurs nouvelles failles critiques sur l'implémentation de Mozilla Firefox.

Des failles qui pourraient être présentes sur Google Chrome également.

Sur le blog de recherche en sécurité et défense, l'équipe MSRC de Redmond affirme que « le support de WebGL dans les navigateurs expose directement des fonctionnalités du hardware au Web d'une manière que nous considérons comme trop permissive ».

Concrètement, la principale critique de Microsoft à ce standard est qu'il risque de permettre aux pirates de s'attaquer aux faiblesses des pilotes graphiques d'une manière que les navigateurs ne pourront pas atténuer.

Microsoft prend à témoin un rapport de sécurité alarmant, publié hier par la firme de sécurité Context. Ce rapport identifie plusieurs failles de sécurité de ce standard initié par la fondation Mozilla et maintenu à présent par le groupe Khronos.

L'une de ces failles permet le vol de captures d'écran sur Firefox par corruption de mémoire :



Actuellement seuls Firefox et Chrome offrent un support avancé de WebGL, mais ces navigateurs « doivent exposer des parties de bas niveau du système d'exploitation, qui ne pouvaient pas être jusque-là directement exposées aux pages web potentiellement malicieuses », affirment les experts de Context James Forshaw, Paul Stone et Michael Jordon.

De son côté, le groupe Khronos tente de minimiser ces inquiétudes en affirmant que « tous les éditeurs de navigateurs travaillent actuellement pour réussir la suite [des tests] de conformité de WebGL », rejetant ainsi la faute sur les implémentations actuelles, encore immatures.

Khronos fait savoir en deuxième lieu que la faille des captures d'écran sus-citée provient d'un bug de l'implémentation de Firefox ayant été corrigé sur Firefox 5 qui sortira le 21 juin prochain.

Des arguments qui ne convainquent pas Microsoft qui refuse d'assumer un standard « qui deviendra une source permanente de vulnérabilités très difficiles à corriger ».

Microsoft doute de ce fait que WebGL puisse passer les exigences de sécurité de son cycle de développement.
Et prouve encore une fois à travers cette prise de position que le respect des standards n'est jamais sa priorité quand il menace la sécurité des utilisateurs.

Source : Microsoft, Context

Et vous ?

Que pensez-vous de cette décision de Microsoft ?
L'avenir de WebGL est-il menacé d'après vous ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de David_g
Membre éclairé https://www.developpez.com
Le 17/06/2011 à 15:15
c'est amusant comment maintenant absolument tout est un standard.

Sinon je me demande ce qu'aurait été les réactions si la faille WebGL s'était retrouvé sur IE, on aurait eu du : ouais comme toujours Krosoft fait n'imp, sécurité toussa.
11  1 
Avatar de LLB
Membre expérimenté https://www.developpez.com
Le 17/06/2011 à 16:54
Citation Envoyé par Neko Voir le message
Déjà connaissant MS. WebGL n'aurait pas eu d'accès direct mais serait probablement juste émulé via directX.
Comme OpenGL pose pas mal de soucis à cause des drivers, Google et Mozilla utilisent le projet Angle, qui convertit le code OpenGL en appels DirectX. Microsoft aurait évidemment intérêt à suivre la même voie, s'il voulait implémenter WebGL.

Citation Envoyé par Neko Voir le message
Ensuite ya pas moyen de sandboxer tout ça ?
WebGL permet d'écrire des shaders, qui sont compilés et exécutés sur la carte graphique. Je ne vois pas bien comment une sandbox pourrait marcher, tout en gardant les avantages d'exécuter le code sur GPU.

Je sais bien que WebGL est chouette, je l'utilise régulièrement et il y a beaucoup d'applications potentielles très intéressantes. J'aime beaucoup. Tant que c'est peu répandu (il me semble que Firefox et Safari le désactivent par défaut), il n'y a pas trop de problèmes de sécurité. Mais le jour où ça arrive sur Internet Explorer, on trouvera des gens pour chercher à exploiter les failles potentielles.

Honnêtement, il y a pas mal de problèmes qui peuvent arriver. Il y a beaucoup de drivers différents, dont la qualité est loin d'être géniale, les gens les mettent rarement à jour, et le navigateur aura du mal à garantir la sécurité et la stabilité. Si quelqu'un fait une boucle infinie en Javascript ou utilise beaucoup de mémoire, c'est facile de tuer le script ; si ça se passe sur GPU, c'est un poil plus compliqué. Quand je compile des shaders un peu compliqué avec WebGL, ça fige tout Firefox... c'est pas top.

J'espère qu'il y a des solutions fiables à ce problème, mais ça risque de prendre du temps à mettre en place. En tout cas, je comprends la position de Microsoft (même si c'est un peu dommage, vues les applications de WebGL).

Plus d'infos sur la faille "Stealing Graphics Memory from the Desktop" : http://www.contextis.com/resources/blog/webgl2/
10  0 
Avatar de stardeath
Membre expert https://www.developpez.com
Le 17/06/2011 à 14:38
déjà j'aime pas cette idée de développer de l'opengl en javascript, donc perso, pas de webgl, je dis tant mieux.

ensuite quand je vois que le watchdog des pilotes nvidia me sort un bsod puis un redémarrage brutal de ma machine sur un calcul un peu complexe en shader, je suis plutôt d'accord sur le fait que l'accès à la carte graphique par le navigateur est encore un peu trop dangereux.
8  1 
Avatar de Hellwing
Membre chevronné https://www.developpez.com
Le 20/06/2011 à 15:10
Citation Envoyé par umeboshi Voir le message
bonne initiative, ils devraient même rejeter IE et se focaliser sur ce qu'ils savent faire de mieux : attendre que les autres fassent ça bien, et le vendre à leur place.
Ah ben bien sûr, Microsoft c'est des méchants qui veulent toujours freiner l'avancée du web ! Vivement les publicités en 3D qui pompent toutes les ressources de la carte graphique !
7  0 
Avatar de Firwen
Membre expérimenté https://www.developpez.com
Le 21/06/2011 à 11:10
ce qui m'épate avec ces types, c'est qu'ils pensent que la 3D par le navigateur c'est l'avenir ... mais l'avenir de quoi? des sites web en 3D, des applications dont on ne contrôle pas les données parce que utilisé à travers un navigateur, du cloud en somme.
ça c'est un problème lié au RIA, pas à la 3D. Silverlight, FLash, Flex et javaFX ont exactement le même problème.
A partir du moment où l'on quitte le format texte pour du binaire, on perd toute la flexibilité qui va avec.

coupable de leur cupidité ... si on pouvait éviter de sortir les adeptes du "tout le monde il est beau, tout le monde il est gentil".
Moi ce qui me ferait plaisir, c'est si on pouvait sortir du Forum tous les fans boys mono-Microsoft/Apple/Linux, qui crache sur logique, éthique et bon sens juste pour pouvoir rester assis sur leurs petits acquis liés à leur formation.
Ne jamais oublier que c'est parce que d'autres ne pense pas comme vous, que le monde évolue.
3  0 
Avatar de Neko
Membre chevronné https://www.developpez.com
Le 17/06/2011 à 13:15
Déjà connaissant MS. WebGL n'aurait pas eu d'accès direct mais serait probablement juste émulé via directX.
Ensuite ya pas moyen de sandboxer tout ça ?
3  1 
Avatar de tulipebleu
Membre régulier https://www.developpez.com
Le 17/06/2011 à 20:01
Je suis tout a fait d'accord avec LLB et stardeath.
WebGL est un énorme problème de sécurité.
Les pub voudront utiliser cet technologie, et comme ce sera codé avec le pied, une fois sur deux, cela fera planté la carte graphique.
Régulièrement, on entend qu'il y a un problème de sécurité avec Acrobat reader, ou avec IE, Firefox, ou d'autres logiciels. Avec webGL, il y aura aussi des problèmes de sécurité avec les drivers graphiques.

En plus, actuellement, que se soit NVidia ou AMD, leur driver sont fait pour être rapide, pas pour être sécurisé. Donc il faudrait qu'ils changent leur façon de faire des drivers, ce qui risque d'avoir un impacte sur les application graphique.

En fait, WebGL n'est rien d'autre qu'une nouvelle façons d'attaquer les PC à distance.

L'enfer est pavé de bonne intention.
4  2 
Avatar de CAML
Membre averti https://www.developpez.com
Le 20/06/2011 à 9:24
Il est vrai que ces derniers temps on voit apparaître de plus en plus de 'promesses' et nouvelle fonctionnalité pour nos navigateurs préférés. Le browseur ne se contente plus de visualiser de simple page web. Je n'ai rien contre de nouvelle fonctionnalité mais comme certains l'ont dit ci-dessus, il faudrait penser à 'sandboxer' tout cela. Parce que tout les plugins et API qui commence a se 'brancher' sur ces navigateurs m’inquiète pas mal.
2  0 
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 21/06/2011 à 11:13
Si Microsoft a dans l'histoire d'autres intérêts que la seule protection des utilisateurs, il n'empêche que leurs critiques me semblent fondées et que vu la surface d'attaque au niveau des drivers, il ne suffira pas de quelques vérifications ici ou là ou d'une "culture de la sécurité" de la part des constructeurs (au détriment des performances : chacun appréciera diversement). J'ai plutôt l'impression qu'on devrait jeter ce standard aux oubliettes et en refaire un autre.

Le problème c'est que je trouve l'attitude de la fondation Mozilla légère dans l'affaire. Un discours à coups de comparaisons hasardeuses et d'approximations, qui nous promet d'abord que tout va bien avant d'expliquer que, bon, oui, il y a des problèmes mais que tout ça finira par s'arranger une fois les drivers sécurisés (avant 2020 si possible, vu les antécédents des constructeurs). Pour le coup, l'image que j'avais d'eux s'en trouve sacrément écornée. Et je note le silence de Google, caché dans le fond, comme s'il voulait se faire oublier et laisser Mozilla prendre les coups. Pas de doute : Mozilla n'a pas le même budget com' que les deux autres.

En attendant, Chrome et Firefox offrent tous deux des moyens de désactiver le support webGL, avis aux amateurs.
3  1 
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 21/06/2011 à 17:37
@Djakisback
Il y a une grosse différence entre webGL et les Flash, Silverlight et compères : le premier autorise une manipulation bas-niveau de la CG (on cause presque directement au driver), les seconds reçoivent des objets de haut niveau (maillages et textures) définis en code managé et ce sont leurs moteurs qui se chargent de choisir les détails du procédé de rendu et les instructions à donner au driver. C'est beaucoup plus limité mais ça ne produit que des flots d'instructions relativement banals qui présentent moins de risques.

Alors si techniquement il est possible de faire reposer tout ça sur webGL, du point de vue sécurité ça n'apporte pas grand chose puisque ce n'est principalement pas webGL qui contiendrait les failles mais les drivers derrière. WebGL peut toujours se livrer à des vérifications ici ou là mais tout n'est pas vérifiable et ce qui l'est n'offre pas pour autant une garantie : conformité au standard ne veut pas dire inocuïté. Une séquence d'opérations peut être licite mais causer un bug dans le driver. C'est tout le problème de webGL : la sécurité repose beaucoup trop sur le driver.

Pour ta seconde question, c'est plutôt avant que les données n'atterrissent dans la VRAM que le bât blesse (le driver, toujours lui). Mais on peut toujours imaginer une faille qui causerait l'exécution de code malicieusement stocké comme donnée dans la VRAM et rapatrié ensuite pour finir exécuté par le CPU. On a bien vu des shaders contenir des codes malicieux de ce genre. Mais encore une fois ça repose sur un bug du driver.
2  0