tag:linuxfr.org,2005:/tags/ob%C3%A9sit%C3%A9/publicLinuxFr.org : les contenus étiquetés avec « obésité »2012-03-27T22:31:53+02:00/favicon.pngtag:linuxfr.org,2005:News/290452012-01-22T13:25:06+01:002012-01-28T16:31:44+01:00Quelques aspects de la sécurité qui n'ont rien a voir avec le « Sandboxing »<div><p>Ceci est une traduction de mon <a href="http://blog.mozilla.com/bjacob/2012/01/18/some-aspects-of-security-that-have-nothing-to-do-with-sandboxing-and-process-separation/">entrée de blog récente</a>. Quelques remarques avant de commencer :</p>
<ul><li>Mon biais : je travaille chez Mozilla Corporation sur WebGL ;</li>
<li>le titre original de mon entrée de blog était trop long pour la limite de longueur de titres. Il ne s'agit pas seulement de « Sandboxing » ;</li>
<li>la traduction est parfois un peu libre, un peu différente de l'original.</li>
</ul><p>D'autre part, comme ici on est chez les Français râleurs, je n'ai pas à prendre autant de pincettes que dans mon blog agrégé sur <a href="http://planet.mozilla.org/">Planet Mozilla</a>. Donc soyons clairs, ce texte se veut un coup de gueule. Il y a des soi-disant experts en sécurité qui prétendent que Firefox est vulnérable parce qu'il lui manque telle ou telle fonctionnalité présente chez tel concurrent. Sans vouloir nier l'utilité de ces fonctionnalités, j'ai pensé qu'il était temps de remettre les pendules à l'heure : la sécurité des navigateurs est un sujet trop vaste pour qu'une ou deux techniques en particulier puissent faire une grande différence au total, et ces « experts » et autres journalistes se ridiculisent en répétant, sans distance critique, le marketing d'une entreprise… avec laquelle je ne tiens pas à me brouiller, car si je critique son marketing, j'ai souvent eu à travailler avec ses ingénieurs dans les comités de standards, et ça se passe très bien.</p>
<p>Au fil de mon blog, j'ai largement dévié sur un autre sujet qui me tient à cœur : la sécurité de WebGL, qui a elle aussi été victime d'une campagne de dénigrement de la part, cette fois-ci, d'un autre concurrent, qui lui n'a vraiment <a href="http://blogs.technet.com/b/srd/archive/2011/06/16/webgl-considered-harmful.aspx">pas fait dans la dentelle</a> alors qu'ils avaient eux-mêmes une technologie <a href="https://connect.microsoft.com/VisualStudio/feedback/details/676134/dos-vulnerability-in-silverlight-5s-3d-similar-to-webgl-dos-vulnerability">avec les mêmes « failles »</a>.</p>
<p>Sur ce, la traduction de <a href="http://blog.mozilla.com/bjacob/2012/01/18/some-aspects-of-security-that-have-nothing-to-do-with-sandboxing-and-process-separation/">ce blog</a> se trouve en seconde partie</p>
<p><abbr title="Note des modérateurs">NdM</abbr> : merci à Benoit Jacob pour son journal.</p></div><ul><li>lien nᵒ 1 : <a title="http://linuxfr.org/users/bjacob/journaux/quelques-aspects-de-la-securite-qui-n-ont-rien-a-voir-avec-le-sandboxing" hreflang="fr" href="https://linuxfr.org/redirect/74840">Journal à l'origine de la dépêche</a></li><li>lien nᵒ 2 : <a title="http://blog.mozilla.com/bjacob/2012/01/18/some-aspects-of-security-that-have-nothing-to-do-with-sandboxing-and-process-separation/" hreflang="en" href="https://linuxfr.org/redirect/74841">Article sur le blog de Benoit Jacob</a></li></ul><div><h2 id="sommaire">Sommaire</h2>
<ul><li><a href="#toc_0">Traduction de l'article : Quelques aspects de la sécurité qui n'ont rien à voir avec le « Sandboxing » et la « séparation des processus »</a></li>
<li><ul><li><a href="#toc_1">Exemple 1 : fuite d'information entre domaines différents</a></li>
<li><a href="#toc_2">Exemple 2 : bugs du navigateur ou des drivers exposant de la mémoire vidéo</a></li>
<li><a href="#toc_3">Exemple 3 : déni de service sur le client</a></li>
<li><a href="#toc_4">Conclusion</a></li>
</ul></li>
</ul><h2 id="toc_0">Traduction de l'article : Quelques aspects de la sécurité qui n'ont rien à voir avec le « Sandboxing » et la « séparation des processus »</h2>
<p>Je ne connais pas grand-chose en matière de sécurité. C'est un vaste domaine, qui touche à presque tous les aspects de l'informatique, et je n'y suis confronté qu'occasionnellement, dans le cadre de mon travail sur WebGL.</p>
<p>Mais récemment, j'ai trouvé quelques articles parlant de sécurité des navigateurs (comme <a href="http://www.scrippsnews.com/node/66777">celui-ci</a> et <a href="http://www.accuvant.com/news/2011/12/09/accuvant-releases-web-browser-security-research-findings">celui-là</a>) qui brossent un tableau de la sécurité des navigateurs qui ne résiste même pas aux quelques exemples que j'ai personnellement rencontrés. <strong>En effet, ils tendent à réduire la sécurité des navigateurs à en gros deux aspects :</strong></p>
<ul><li>l'exécution de code arbitraire ;</li>
<li>la fuite d'informations entre différents onglets du navigateur.</li>
</ul><p>Ainsi, ils en viennent à juger de la sécurité des navigateurs sur la base de seulement quelques fonctionnalités tournant autour de ces aspects, tels que le <em>« sandboxing »</em> et la séparation en multiples processus.</p>
<p>Ces aspects de la sécurité sont certes très importants et intéressants, mais méritaient-ils vraiment d'être ainsi exacerbés au détriment d'autres aspects ?</p>
<p>Dans mon expérience limitée, dans le cadre de WebGL, ces aspects se sont effectivement manifestés dans certains bugs qu'on a corrigés, comme certains plantages avec corruption du tas. Nous les avons pris très au sérieux et les avons déclarés « critiques » parce que, en théorie, c'est bien ce genre de bugs qui conduit à de l'exécution arbitraire de code. Cependant, en pratique, pour autant que je sache, nous n'avons jamais vu d'exploitation de ces bugs, et pour de bonnes raisons : d'abord, une majorité de ces bugs n'est probablement pas réellement exploitable, à plus forte raison avec l'<a href="http://en.wikipedia.org/wiki/Address_space_layout_randomization">ASLR</a> et la <a href="http://en.wikipedia.org/wiki/Data_Execution_Prevention">DEP</a>. Mais surtout, ces bugs ont toujours été faciles à corriger, donc ils ont simplement été corrigés avant d'avoir pu être largement exploités.</p>
<p>Donc, ce dont je voudrais parler ici, c'est <strong>d'autres catégories de bugs que j'ai rencontrés autour de WebGL</strong>, qui n'ont pas été aussi faciles à corriger.</p>
<h3 id="toc_1">Exemple 1 : fuite d'information entre domaines différents</h3>
<p>Il y avait une faille dans la version 1.0.0 de la spec WebGL, que Firefox 4 suivait, qui a conduit à une <a href="http://hacks.mozilla.org/2011/06/cross-domain-webgl-textures-disabled-in-firefox-5/">vulnérabilité à la fuite d'information entre domaines différents</a>. Les détails sont donnés sur cette page ; disons simplement ici qu'elle permettait à des scripts vicieux provenant d'un domaine de lire des images provenant d'autres domaines, ce qui est très préoccupant ; cette vulnérabilité a été réparée dans Firefox 5, mais ça me fendait le cœur car le correctif consistait à interdire l'usage d'images d'autres domaines dans WebGL, ce qui a cassé la compatibilité avec des pages Web légitimes. Une solution pour ces pages Web a depuis <a href="http://hacks.mozilla.org/2011/11/using-cors-to-load-webgl-textures-from-cross-domain-images/">été implémentée</a>.</p>
<p>Il y a de nombreux exemples de vulnérabilités à la fuite d'information entre différents domaines ; elles sont un élément-clé du paysage du Web car elles décident souvent de ce qui est faisable et de ce qui ne l'est pas (<a href="http://robert.ocallahan.org/2011/09/risks-of-exposing-web-page-pixel-data.html">lisez ceci</a>). Par exemple, elles sont une raison majeure pour laquelle on ne permet pas aux pages Web normales de faire le rendu d'autres pages Web avec WebGL, et elles constituent le défi principal pour les <a href="https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html">CSS Shaders</a>. En plus de façonner les limites de nouvelles technologies Web, elles rendent aussi trop risqué l'usage de certaines optimisations, par exemple dans les implémentations du Canvas 2D.</p>
<p>Il peut être utile de souligner le fait que la fuite d'information entre différents domaines n'a, à peu près, rien à voir avec la fuite d'information entre différents onglets d'un navigateur, ce qui explique pourquoi la séparation en multiples processus est hors sujet ici. La vulnérabilité mentionnée ci-dessus pouvait être exploitée avec un unique onglet : en effet, le code de démonstration utilisait un unique canvas ; et même si un jour l'exploitation d'une vulnérabilité demandait deux canvas provenant de deux domaines différents, on pourrait encore le faire dans un unique onglet avec des iframes.</p>
<h3 id="toc_2">Exemple 2 : bugs du navigateur ou des drivers exposant de la mémoire vidéo</h3>
<p>Nous avons vu (et corrigé !) quelques bugs qui permettaient, via WebGL, d'accéder en lecture à des parties aléatoires de la mémoire vidéo.</p>
<p>Parfois c'était de notre faute (comme <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=659349">ici</a>) : nous ne programmions pas correctement le système graphique pour effacer le contenu de nouvelles surfaces, donc elles conservaient leur contenu provenant d'un usage antérieur de cette zone de mémoire.</p>
<p>Parfois c'était la faute du pilote (comme <a href="http://wahlers.com.br/claus/blog/talking-about-webgl-and-security">ici</a> et <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=631258">ici</a>), car bien que nous programmions correctement le système graphique, il s'emmêlait les pinceaux et vous vous retrouviez avec votre <a href="https://bug631258.bugzilla.mozilla.org/attachment.cgi?id=509819">fenêtre Terminal peinte dans une scène en 3D</a>. De toute façon, c'est la responsabilité du navigateur de garantir que ces bugs n'affectent pas l'utilisateur du fait de sa navigation. Ce dernier bug a été résolu en mettant Mac OS 10.5 sur la liste noire pour WebGL, mais l'autre affecte des OS plus récents que ça (quoique pas Linux), donc j'encourage tous les utilisateurs à s'assurer qu'ils utilisent la dernière version stable de leur navigateur, qui contourne le problème !</p>
<h3 id="toc_3">Exemple 3 : déni de service sur le client</h3>
<p>Les vulnérabilités de déni de service sont très préoccupantes pour les serveurs, car pour des gens mal intentionnés, il existe des motivations à attaquer un serveur ainsi. Dans le cas de clients (comme des navigateurs Web), la motivation d'une attaque par déni de service (DoS) est bien plus faible, voire inexistante dans beaucoup de cas. Nous ne rencontrons pas beaucoup de pages Web qui essayent de DoSer le navigateur, parce tout ce qu'elles auraient à y gagner… c'est qu'on ne les visiterait pas à nouveau.</p>
<p>L'existence de vulnérabilités DoS dans la plateforme Web a toujours été une réalité, et il n'y a pas trop de solutions pour éviter ça. Par exemple, un script peut allouer beaucoup de mémoire, ce qui « dénie » aux autres programmes sur votre ordinateur le « service » d'avoir cette mémoire à leur disposition. Et si le navigateur décidait de limiter la quantité de mémoire qu'un script peut utiliser, ça entrerait en conflit avec des cas d'utilisation légitimes, et il resterait encore bien d'autres vulnérabilités DoS ne faisant pas du tout intervenir de scripts. Exercice amusant : avec un navigateur effectuant le rendu sur la carte graphique (ce qui sera bientôt tous les navigateurs), essayez de saturer la mémoire vidéo avec une page Web contenant beaucoup de grandes images.</p>
<p>WebGL, comme toutes les APIs 3D depuis qu'OpenGL 1.1 a introduit en 1997 la notion de <em>« vertex arrays »</em>, a une vulnérabilité DoS bien spécifique : il permet de monopoliser la carte graphique (GPU), ce qui est particulièrement casse-pieds parce que les GPUs actuels sont non-préemptibles. Les OS modernes (oui, ça inclut Linux avec certains pilotes, je crois Mesa/Intel et NVIDIA au moins, mais on est en discussion avec des devs de pilotes au sujet de certains bugs) ont une fonctionnalité qui réinitialise automatiquement le GPU s'il est gelé depuis environ 2 secondes. Malheureusement, certains pilotes répondent encore assez mal à ça (sous Windows on a encore de beaux plantages bleus). C'est vraiment triste, mais on n'a pas vu beaucoup d'utilisateurs souffrir de ça dans le monde réel, et au moins ça amène à de bonnes conversations avec les fabricants de GPUs et les choses sont en bonne voie, même si ça prend du temps.</p>
<h3 id="toc_4">Conclusion</h3>
<p>Voici les trois pires sortes de vulnérabilités liées à WebGL que j'ai personnellement rencontrées. Les techniques de sécurité que certains considèrent comme l'Alpha et l'Omega de la sécurité des navigateurs ne peuvent rien contre ces vulnérabilités. Je ne veux pas dire que ces techniques (<em>« sandboxing »</em>, séparation en multiples processus…) sont inutiles en général : elles sont extrêmement utiles, mais elles sont inutiles pour les bugs sécurité qui ont été les plus inquiétants dans ma propre et humble expérience. Ceci veut au moins dire que la sécurité des navigateurs ne se résume pas à ces techniques, comme ces articles de sécurité que j'ai mentionnés au début voudraient le faire croire.</p></div><div><a href="https://linuxfr.org/news/quelques-aspects-de-la-securite-qui-n-ont-rien-a-voir-avec-le-sandboxing.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/89135/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/quelques-aspects-de-la-securite-qui-n-ont-rien-a-voir-avec-le-sandboxing#comments">ouvrir dans le navigateur</a>
</p>
Benoit JacobclaudexLucas Bonnethttps://linuxfr.org/nodes/89135/comments.atom