Benoit Jacob a écrit 217 commentaires

Dans l'article:

² : EGL et GLES2 sont une surcouche à OpenGL qui permettent d'accélérer le rendu.

Ca n'a pas beaucoup de sens, ca. GLES2 est une abbreviation pour OpenGL ES 2, une version d'OpenGL. (Enfin d'OpenGL ES, la version portable pour appareils embarques, mais c'est une variante d'OpenGL).

EGL est l'interface entre OpenGL ES et le systeme de fenetrage. C'est ce qu'on utilise pour creer un contexte OpenGL ES. Disons que EGL est a OpenGL ES ce que GLX est a OpenGL sous X11. Sauf que EGL est universel, on l'utilise partout ou l'on utilise OpenGL ES.

Au cas où ça intéresserait des gens, voici un petit retour d'expérience sur le développement de Gecko (Firefox) / Linux et comment X est un gros boulet qu'on se traîne:

1. Les pixmaps X. Ce sont des images bitmap stockées du côté serveur X, c'est-à-dire des images en mémoire vidéo, comme les fameuses "textures" d'OpenGL. C'est très bien de stocker des images en mémoire vidéo, donc l'utilisation de pixmaps X a toujours été recommandée (en particuler en conjonction avec XRender mais pas seulement). Le problème vient justement de cette redondance entre pixmaps X et textures OpenGL. À partir du moment où l'on commence à utiliser OpenGL, on se trouve dans une situation où l'on a besoin de convertir efficacement des pixmaps en textures. C'est ce que fait l'extension texture_from_pixmap. Le problème est que les implementations de cette extension sont catastrophiquement buggées. En particulier dans les pilotes NVIDIA proprio et Intel libre. Conséquence: on ne peut pas activer l'accélération OpenGL du compositage dans Firefox tant qu'on ne se sera pas complètement débarrassés de l'utilisation de pixmaps.

2. XRender. C'était censé être une super API d'accélération 2D, une sorte de Direct2D avant l'heure. Le problème est que les performances des implementations de XRender varient si grandement qu'on ne peut pas savoir à quoi s'attendre. XRender peut être beaucoup plus rapide... ou beaucoup plus lent que du rendu logiciel.

3. Les erreurs X. C'est le cas d'école d'un système de gestion des erreurs raté. Les erreurs X sont asynchrones, donc pour obtenir le code d'erreur d'une fonction précise il faut synchroniser (XSync) juste après, et la synchronisation peut coûter extrêmement cher (surtout si le serveur X est ailleurs sur le réseau), donc on ne peut généralement pas se le permettre. Conséquence: on doit gérer les erreurs de façon vraiment asynchrone, ce qui veut dire que quand on reçoit une erreur, c'est généralement bien après qu'elle se soit produite... conséquence: il est alors généralement trop tard pour récupérer. Conséquence: les gestionnaires d'erreurs X consistent presque tous a simplement interrompre l'exécution du programme: boum, plantage! C'est le cas du gestionnaire d'erreurs X par défaut, de celui de GDK, et de celui de Mozilla. Il n'y a pas trop d'autre solution en général. Le pire est que les erreurs X peuvent se produire un peu n'importe quand, et ça dépend souvent de détails comme le pilote, le numéro de version du serveur... Une bonne partie des plantages "inexpliqués" de Firefox sous linux sont des erreurs X. (On peut le voir ici)

4. Gecko a besoin de savoir, avant de demander un contexte OpenGL, si c'est bien raisonnable: en effet, sur certains systèmes (problème avec un pilote, le serveur, etc), créer un contexte OpenGL résulte en un plantage ou une erreur X, ce qui revient au même (cf. point 3). Donc on veut implémenter une "liste noire" de systèmes/de pilotes où il faut éviter de toucher à OpenbGL. Le problème c'est que X est la seule plate-forme où on ne peut pas obtenir ces informations sans... créer un contexte OpenGL (et appeler glGetString)! On peut bien appeler glXQuery{Client|Server}String mais ça donne très peu d'informations. C'est la raison pour laquelle dans Firefox 4 et 5 il était difficile d'activer WebGL. On a résolu ça dans Firefox 6 en forquant un processus séparé qui crée un contexte OpenGL et obtient les informations, comme ça s'il planté c'est pas grave.

Ce qui n'implique absolument pas que la version ESR soit plus stable ou plus sure que la version standard. D'ailleurs les correctifs de simples plantages sont hors-sujet pour l'ESR, voir ci-dessous. Au contraire, comme seuls les correctifs de securite les plus importants seront apportes a l'ESR, et comme il y a souvent des compromis a faire entre reparer les bugs et preserver la compatibilite avec les contenus existants et que le biais de l'ESR est naturellement de preserver la compatibilite, il faut s'attendre a ce que l'ESR ait plutot plus de bugs que la version standard. Il est donc tres important de faire comprendre aux gens que la seule raison d'utiliser l'ESR c'est s'ils ont des imperatifs de compatibilite que le cycle en 6 semaines ne permet pas de satisfaire. Ce qui n'est le cas que d'organisations ayant des besoins tres specifiques (genre application ou extension interne).

C'est explique par exemple dans la FAQ dont j'ai mis le lien dans mon commentaire precedent. Citation:

Maintenance of each ESR, through point releases, is limited to high-risk/high-impact security vulnerabilities and in rare cases may also include off-schedule releases that address live security vulnerabilities. Backports of any functional enhancements and/or stability fixes are not in scope.

Par ici: http://www.mozilla.org/en-US/firefox/organizations/ qui va t'envoyer ici: http://www.mozilla.org/en-US/firefox/organizations/faq/

Mais assure-toi de bien lire les infos. Ca n'est utile qu'aux organisations qui ne peuvent pas suivre le cycle rapide de 6 semaines. Ca n'apporte aucun benefice ni en matiere de stabilite (au sens plantages) ni en matiere de securite, ce qui est la raison pour laquelle Mozilla avait initialement espere ne pas avoir a faire ca.

Je pense que tu n'as rien compris a pourquoi ces DoS sont difficiles a eviter. Bien sur que l'implementation peut imposer une limite. Mais quelle limite? Impossible de choisir une limite qui soit assez haute pour ne gener aucune application legitime, et en meme temps assez basse pour eviter les DoS sur tous les systemes, etc. Tout ce qu'on pourrait faire c'est couper la poire en deux, taper au milieu de la fourchette, dire "pas plus de 256 M de memoire par domaine pour les scripts" et on aurait encore tous les problemes: ca serait encore trop pour beaucoup de machines, et pas assez pour beaucoup de scripts specialises. Et quand un jeu Facebook buggerait a cause de ca, on recevrait des milliers de plaintes. Idem pour le bug avec beaucoup de grandes images. Et ca n'etait que 2 exemples...

Je pense que tu fais un enorme raccourci dans ta lecture de ce paragraphe que tu cites. Quand j'ecris "une majorité de ces bugs n'est probablement pas réellement exploitable", as-tu saute le "une majorite de"? Je n'ai pas dit "tous les bugs sont non-exploitables" comme tu essaies de me le faire dire. Du coup, sur l'ASLR et la DEP, je n'ai pas dit non plus que ca resolvait tous les problemes, donc tu es en train de repondre a quelque chose que personne n'a dit. Ensuite, je parlais des bugs de WebGL et pour ceux-ci, oui, meme pour les quelques bugs vraiment exploitables qu'on a eus, je confirme qu'on n'a pas vu d'exploit reellement utilise en pratique. Bien sur en interne on a construit quelques tels exploits theoriques, mais on a pu sortir le correctif avant de voir le bug exploite par les mechants.

Sur ton point 2, je dirais certes mais c'est une cause perdue, tout ce qu'on peut faire c'est resoudre les problemes qui font que des gens restent sur de vieilles versions (comme la compatibilite avec les addons, probleme en bonne voie de resolution).

Sur ton point 3, on sait bien que les failles exploitables se vendent tres cher sur le marche noir. On les devance en ayant toute une equipe de fuzzing et d'analyse statique, et en distribuant des primes genereuses a des gens de l'exterieur pour la decouverte de failles, et ca marche pas mal pour le moment.

De plus, quand le message de Paul a pris de l'ampleur journalistique, comme dit, à notre connaissance, l'employeur ne s'est pas désolidarisé, comme on dit, de la chose. Qui ne dit mot consent, surtout pour un employé dont une partie du boulot est de faire ce genre de phrase...

Ouhlala, mais c'est du delire ca. Vu la quantite de conneries que la presse dit autour de Mozilla chaque semaine, s'il fallait tout dementir il faudrait embaucher quelqu'un a temps plein juste pour ca (je n'exagere meme pas). En fait ce que tu viens de dire implique que n'importe quoi peut devenir "verite" si on le repete a suffisament d'endroits differents.

Et le concept de l'URL en blog.mozilla.com qui implique que c'est officiel, je ne connais pas non plus. Pour info et parce qu'il n'est jamais trop tard pour le dire, ce journal/article Linuxfr n'engage que moi et je ne me suis concerte avec personne avant de le publier.

plutôt que 3 bugs spécifiques au mieux au navigateurs au pire à firefox uniquement

A tous les navigateurs supportant WebGL. On pourrait facilement donner des liens vers des rapports de bug WebKit equivalents, mais j'ai pense que ca allait de soi vu la description des problemes en question, et je n'ai pas voulu insister sur "les autres aussi".

Justement, un point que je voulais souligner est que les navigateurs sont un domaine tres particulier en matiere de securite, avec des regles tordues mais qu'il faut absolument preserver. Par exemple, les regles d'utilisation de ressources provenant d'autres domaines, le fait que c'est la faute du navigateur meme si c'est la faute du driver de la carte graphique, etc.

Les applis implementant ces protocoles de messagerie (IMAP, etc) en question peuvent et doivent, contrairement au navigateur, etre nettement plus strictes sur les contenus autorises, par defaut. Par exemple, Thunderbird n'autorise pas (en tout cas par defaut) l'execution de JavaScript dans les mails HTML.

(La difference avec le navigateur etant bien entendu qu'avec le navigateur, tu vas ou tu veux, alors qu'avec la messagerie, on t'envoie ce qu'on veut)

La technique qui consiste a faire passer par des canaux encore consideres comme "non officiels" de la communication marketing, c'est pas nouveau,

En gros tu es en train d'accuser Mozilla de faire passer en douce son marketing d'entreprise dans des blogs personnels de developpeurs? C'est trop enorme, faux bien sur, et vraiment grave comme accusation. Quand Paul blogue sur son blog, c'est son blog. Quand Asa blogue sur son blog, c'est son blog aussi. Qu'importent les titres? Ils ont le droit a leur propre opinion independamment de leur role officiel. Si des journaux idiots les reprennent en les decrivant a tort comme des positions officielles de Mozilla, c'est de la faute de ces journaux.

Si tu veux eviter les DoS inherents a JS, tu ferais mieux d'installer NoScript. Si tu veux eviter les DoS inherents a l'acceleration par le GPU, Firefox (et les autres navigateurs) te permettent de desactiver ca (Firefox a meme une boite a cocher dans les prefs). WebGL peut aussi etre desactive dans about:config quoique NoScript s'en charge.

Il y en a au moins 2 dans mon journal, si tu le lis (allouer de la memoire en JS, et une simple page web avec beaucoup de grandes images, surtout sur un navigateur qui utilise le GPU).

Ca depend: un presuppose de ton raisonnement est que le pire des cas sans sandboxing est plus grave que le pire des cas avec sandboxing; je suppose que tu veux dire par la que par exemple installer un malware ou lire des fichiers sur la machine du client est plus grave que ce qu'on peut faire sans sortir du sandbox; je dirais plutot que c'est ni plus ni moins grave, les deux sont des dangers egalement mortels. Sans sortir du sandbox, l'attaquant a deja acces a mes donnees privees sur les sites ou j'ai une session ouverte, genre compte en banque et email, c'est deja assez enorme pour que je ne voie pas comment ca pourrait etre pire. Mais je comprends qu'en dehors du sandbox il y a d'autres possibilites d'exploitations interessantes (comme transformer la machine en zombie qui envoie du spam).

Oui bon, c'est un peu ambigu. D'une part WebGL a bien ete invente a Mozilla (par Vlad), donc en effet on ne peut pas se dedouaner, mais d'un autre cote il est tres clair a posteriori (vus, successivement, le projet de Canvas 3D d'Opera, O3D de Google, Flash 11, Silverlight 5, et NaCl) que si on ne l'avait pas fait, un concurrent aurait impose sa propre techno de 3D pour "le web" et on aurait du vivre avec. Comme WebGL est AMHA mieux que ces concurrents qu'il a ou a eus, je pense que la strategie de "suivre le vent sans attendre les autres" etait la bonne.

Ca m'interesserait de savoir pourquoi ce commentaire a ete moinsse a zero. S'il a ete compris comme agressif, ca n'etait pas l'intention.

Je ne penses pas que tu ecris ca serieusement, c'est trop trollistique et vague... et je suis certain que le marketing de Mozilla n'a jamais fait de commentaire sur IE9, au mieux tu confonds peut-etre avec le blog d'un individu?

Oui, comme je l'explique dans le journal, tu as des tas de DoS inherents a la plateforme web (html+js), dans tous les navigateurs, meme sans "html5". Je ne nie pas que c'est tres triste, mais en meme temps force est de constater que ca n'est jamais exploite en pratique, probablement parce qu'il n'y a rien a y gagner.

(pour cela il faut de l'information sur quels scripts correspondent à quels principaux)

Ca, ce n'est pas un probleme, le navigateur sait ca;

un compartiment donné pourra accéder à et corrompre la mémoire qui lui est propre

La je ne suis pas du tout. L'implementation des APIs DOM a besoin de pouvoir acceder a plein de choses. Par exemple, justement, toutes les variables qui rentrent en jeu pour decider si le script a le droit de lire les pixels de telle image: ca inclut les differents principaux en jeu, les drapeaux CORS, les clean-origin-flag des canvas 2D, etc. Donc on ne peut pas implementer ces APIs DOM (comme WebGL) sans leur laisser l'acces a ces variables. Donc, comment comptes-tu empecher un bug de debordement de tampon de reecrire ces variables, permettant ainsi au script de lire des informations provenant d'autres domaines?

Resultats concrets? Je dirais que les bugs corriges dans Firefox (publiquement visibles dans les depots hg, et dans bugzilla apres parfois un delai de securite) sont le resultat concret.

Mais, reutilisables par l'exterieur? La je ne sais pas, il faut que tu demandes directement aux gens qui font ca. Je suggererais de poser la question a security a mozilla.org.

Encore une fois, bien que j'ai utilise WebGL pour mes exemples, ces types de bugs se sont tous retrouves aussi dans des parties non liees a WebGL (WebGL n'est pas la seule partie a utiliser OpenGL/D3D, ni la seule partie a pouvoir permettre de lire le contenu d'images (avec restrictions de domaines), etc)

Si tu relis ce que j'ai ecrit, tu verras que je n'ai jamais dit que c'etait "totalement inefficace", j'ai meme dit que c'etait "extremement utile". Et l'ASLR, j'en ai parle ci dessus, Firefox aussi l'utilise.

Une autre reponse possible, plus specifique a ce que tu ecris sur les chaines de caracteres et debordements de tampons: il y a des gens qui bossent a temps plein avec des outils d'analyse statique pour decouvrir ces bugs dans Firefox (et dans tous les autres navigateurs). Certains payes par Mozilla, certains non. Et il y a aussi des gens qui en font autant avec des fuzzers. La encore, certains sont payes par Mozilla, d'autres non.

Juste pour dire que bien entendu que les opportunites connues de decouvrir/eviter d'un coup beaucoup de bugs, sont utilisees (ou, pour les techniques les plus recentes, envisagees), chez Mozilla comme chez les autres.

Ensuite, la realite est que malgre tout ca, des bugs de securite (non evites par les techniques en place) sont decouverts chaque semaine dans tous les navigateurs, et ceux-la on les resout au cas par cas.

Voila, j'espere que c'est clair comme ca. J'ai pas dit que Firefox etait ecrit en Turbo Pascal par 2 stagiaires en fin de classe de 3eme, non plus.

Je n'ai pas du tout nie l'existence de grandes familles de bugs. D'ailleurs, mon journal detaille 3 grandes familles de bugs que j'ai rencontres.

Je n'ai pas non plus nie que certaines techniques puissent etre utiles pour pas mal de bugs dans une famille donnee.

Mais de la a dire qu'elles puissent eliminer toute la famille en question, la, c'est non.

Par exemple tu mentionnes les debordements de tampons ("buffer overflow"). Selon les cas, un bug de ce type peut:
- soit permettre l'execution de code arbitraire, auquel cas les bonnes vieilles techniques dites ASLR et DEP (liens dans mon journal) limitent les possibilites d'y parvenir mais pas a 100%, et le sandboxing limite les possibilites pour du tel code d'agir sur le reste du systeme mais comme il y a deja plein de choses a manger a l'interieur du sandbox, c'est pas forcement un probleme pour l'attaquant.
- soit permettre aux scripts d'acceder en lecture ou en ecriture a de la memoire arbitraire, auquel cas aucune des techniques mentionnees ci-dessus n'est utile!
- soit conduire a un bete plantage, ce qui est un cas de deni de service, et la non plus aucune des techniques envisagees n'est utile.
- etc, etc.

Dire que l'exemple 1 de mon journal peut etre corrige par une architecture plus solide, desole, mais ca n'a pas de sens. L'exemple 1, fuite d'information d'un domaine a un autre, est le type meme de ce qui est entierement hors de portee d'une solution generique, meme specifique aux structures de donnees du Web.

Edit: un petit rajout ici: Par exemple, l'attaque que j'ai mentionnee dans l'exemple 1 etait du type timing attack, une attaque par mesure du temps d'execution d'une operation. A part cette vulnerabilite a la mesure du temps, tout etait nickel et sans faille, mais cette attaque a tout fichu en l'air... et je suis bien certain qu'il n'y a pas de solution generique pour ca.

Pareil pour l'exemple 3, en fait. Deja l'exemple du script qui alloue trop de memoire, je ne vois pas quelle solution envisager pour ca. Tu peux compartimenter la memoire comme tu veux, le probleme est que tu as une ressource en quantite finie a partager entre tout le monde et que tu n'as pas de regle valable pour decider combien un script merite d'allouer pour lui-meme.

Je n'ai pas dit que le sandboxing etait inutile, et je ne me plains absolument pas de la concurrence nous poussant dans cette direction. Ce dont je me plains c'est le marketing malhonnete qui consiste a prendre une fonctionnalite au pif parmi ce qu'on a de plus que la concurrence, et la presenter comme le truc qui tue dont personne ne peut se passer, qui plus est sur un mode "educatif".

Quand tu dis "les failles dont tu parles sont toutes des problèmes de compartimentation/isolation", c'est un enonce creux car on peut toujours dire ca de toutes les vulnerabilites, en elargissant les concepts. La question est de savoir si les techniques vantees par ces experts de la securite permettraient de s'en premunir, et la reponse est non.

Ne me fais pas dire ce que je n'ai pas dit: je ne risque pas de dire "ouin les gens de Chrome ils sont vilains" puisque tout au plus je le penserais de leur departement marketing seulement.

"vous proposez quoi sur le terrain technique ?" C'est bien simple: on resout les bugs au cas par cas. Je sais que vu de loin, comme ca, on prefere croire a des solutions miracles qui elimineraient d'un coup toute un classe de vulnerabilites. Mais dans la realite, pour la grande majorite des bugs, il n'y a pas de telle solution miracle. Chaque bug doit etre compris et repare separement.

Du coup, autre coup de gueule: les soi-disant experts de securite en question rendent un mauvais service aux gens en leur faisant croire au mythe de la solution miracle. Si ca peut conduire a un faux sentiment de securite, c'est contre-productif.

Les aspects que j'ai mentionnes ici dans le contexte de WebGL (deni de service, fuite d'into trans-domaine, lecture de memoire video) ne sont pas specifiques a WebGL et ont tous ete rencontres aussi en dehors de WebGL. Au moins pour le deni de service et la fuite d'info trans-domaine, j'en ai donne des exemples precis dans mon journal. Bref, tu fais la lecture que tu veux de mon journal en fonction de ce que tu veux y voir, mais ca en dit plus sur tes prejuges que sur WebGL.

Vous avez bien entendu raison sur le fond, mais le marche etant ce qu'il est, un projet comme Mozilla a le choix entre suivre la tendance ou devenir un dinosaure :-)

Ensuite pour les bugs dans les pilotes qui exposent de la memoire video, il faut bien voir que c'est deja un vrai probleme de securite pour les applications locales. Un peu comme si un processus pouvait lire dans l'espace d'adresses d'un autre.