Ceci est une traduction de mon entrée de blog récente. Quelques remarques avant de commencer :
- Mon biais : je travaille chez Mozilla Corporation sur WebGL ;
- 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 » ;
- la traduction est parfois un peu libre, un peu différente de l'original.
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 Planet Mozilla. 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.
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 pas fait dans la dentelle alors qu'ils avaient eux-mêmes une technologie avec les mêmes « failles ».
Sur ce, la traduction de ce blog se trouve en seconde partie
NdM : merci à Benoit Jacob pour son journal.
Sommaire
Traduction de l'article : Quelques aspects de la sécurité qui n'ont rien à voir avec le « Sandboxing » et la « séparation des processus »
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.
Mais récemment, j'ai trouvé quelques articles parlant de sécurité des navigateurs (comme celui-ci et celui-là) 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. En effet, ils tendent à réduire la sécurité des navigateurs à en gros deux aspects :
- l'exécution de code arbitraire ;
- la fuite d'informations entre différents onglets du navigateur.
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 « sandboxing » et la séparation en multiples processus.
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 ?
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'ASLR et la DEP. Mais surtout, ces bugs ont toujours été faciles à corriger, donc ils ont simplement été corrigés avant d'avoir pu être largement exploités.
Donc, ce dont je voudrais parler ici, c'est d'autres catégories de bugs que j'ai rencontrés autour de WebGL, qui n'ont pas été aussi faciles à corriger.
Exemple 1 : fuite d'information entre domaines différents
Il y avait une faille dans la version 1.0.0 de la spec WebGL, que Firefox 4 suivait, qui a conduit à une vulnérabilité à la fuite d'information entre domaines différents. 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 été implémentée.
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 (lisez ceci). 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 CSS Shaders. 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.
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.
Exemple 2 : bugs du navigateur ou des drivers exposant de la mémoire vidéo
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.
Parfois c'était de notre faute (comme ici) : 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.
Parfois c'était la faute du pilote (comme ici et ici), car bien que nous programmions correctement le système graphique, il s'emmêlait les pinceaux et vous vous retrouviez avec votre fenêtre Terminal peinte dans une scène en 3D. 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 !
Exemple 3 : déni de service sur le client
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.
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.
WebGL, comme toutes les APIs 3D depuis qu'OpenGL 1.1 a introduit en 1997 la notion de « vertex arrays », 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.
Conclusion
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 (« sandboxing », 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.
Aller plus loin
- Journal à l'origine de la dépêche (175 clics)
- Article sur le blog de Benoit Jacob (65 clics)
# Oui, mais
Posté par gasche . Évalué à 8.
Il est tout à fait exactement que, dans les navigateurs webs, les attaques internes aux données du navigateur (cookies, scripting cross-domaine etc.) sont au moins aussi préoccupantes que les attaques contre le systèmes (exécution de code), car plus proches du domaine applicatif. Pour la même raison, elles sont plus difficiles à éviter par des mécanismes génériques; ça fait écho de la discussion sur les navigateurs dans la news sur seccomp (sandboxing dans Linux).
Cependant je trouve qu'il y a un peu de déni dans ta réaction. Certes, l'insistance des gens de Chrome sur le sandboxing a aussi des effets marketing; d'ailleurs ton message lui aussi est un message de communication, pas vraiment un message technique. Mais s'ils peuvent se permettre d'insister dessus de façon parfois exagérée, c'est parce que ce choix technique de fond est bon, et que Mozilla est à la traîne là-dessus. C'est un fait, et je trouve bien que les gens de Chrome vous mettent la pression (par des moyens qu'on peut critiquer) pour bouger sur ça : dans le fond c'est une vraie différence technique.
D'ailleurs les failles dont tu parles sont toutes des problèmes de compartimentation/isolation (même le DoS : pour gérer les attributions de ressources il faut avoir compartimenté au préalable). Dans l'architecture actuelle des navigateurs, elles ne correspondent pas forcément à des limites de processus et donc les techniques de sandboxing ne sont pas forcément utiles; par exemple si les cookies ou les objets de scripting vivent dans un espace de nommage global partagé, des attaques sont possibles. Mais dans le fond ça reste un manque de compartimentation, et des architectures différentes (par exemple le choix de multiprocessing de Chrome pour le rendu, ou pour aller plus loin une organisation plus "everything is a file" à la Plan9) pourraient rendre ça accessible aux techniques systèmes standard d'isolation.
Bref, pour moi ton message se lit comme un "ouin les gens de Chrome ils sont vilains, ils se font mousser sur leur sandboxing mais en vrai c'est pas la seule solution à tous les problèmes". Peut-être mais en attendant vous proposez quoi sur le terrain technique ? Les gens de Google poussent l'état de l'art en matière de sécurité sur les navigateurs (Google Caja, Capsicum, le travail de Mark Miller sur la standardisation de Javascript), ce ne sont pas les seuls, mais ils font du bon boulot. J'attends avec impatience que les gens de Mozilla fassent eux aussi des avancées dans le domaine, mais il faudra un peu plus qu'un simple "oui mais c'est que de la communication".
[^] # Re: Oui, mais
Posté par Benoit Jacob (site web personnel) . Évalué à 9.
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.
[^] # Re: Oui, mais
Posté par TImaniac (site web personnel) . Évalué à 4.
En terme de sécurité, se contenter de ça me paraît extrêment dangereux comme philosophie. Il faut anticiper, pas se contenter de sortir la lance à incendie quand on aperçoit les flammes.
Le sandboxing est une façon d'ajouter une barrière "globale" supplémentaire, qui limite l'impact des futurs bugs.
[^] # Re: Oui, mais
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Le sandboxing est une façon d'ajouter une barrière "globale" supplémentaire, qui limite l'impact des futurs bugs.
Oui, mais pas dans les cas réels rencontrés lors du dev de webgl.
"La première sécurité est la liberté"
[^] # Re: Oui, mais
Posté par TImaniac (site web personnel) . Évalué à 5.
Ben oui c'est bien le problème : WebGL en exposant des API trop bas niveau, rend difficile le sandboxing. La seule solution que je vois est d'exposer une API de plus haut niveau, sans doute moins puissante, mais beaucoup moins dangereuse.
[^] # Re: Oui, mais
Posté par gasche . Évalué à 10. Dernière modification le 22 janvier 2012 à 15:54.
Je ne suis pas du tout d'accord. Je ne suis pas un expert en sécurité mais je vois de temps en temps passer des annonces de failles de sécurité, et dans l'extrême majorité des cas on peut les classer dans des "grandes familles" de bugs qui pourraient être tout à fait éliminées par une architecture plus robuste.
L'exemple typique, ce sont les failles de buffer overflow permises par l'interface de manipulation de chaînes en C. C'est un cas typique, il y a eu des milliers de failles de ce genre et il en reste encore qu'on n'a pas détectées. "Résoudre au cas par cas" c'est la moindre des choses, mais utiliser d'autres outils pour manipuler les chaînes c'est encore mieux, et d'ailleurs le logiciel écrit dans des langages de plus haut niveau qui font de la vérification des accès aux chaînes/tableaux n'ont quasiment jamais ces failles. On a donc bien un changement d'architecture qui éradique complètement un problème de sécurité.
C'est encore la même chose pour les failles d'injection SQL, qui sont liées à une interface rétrograde choisie à la frontière entre le langage serveur et la base de donnée.
Les exemples 1 ou 3 dans ton billet sont typiquement des choses qui pourraient être corrigées si l'architecture était plus solide. Ce sont des exemples du fait que sur une page web, les principaux (au sens de la littérature de sécurité, les agents ayant des intérêts différents) ne sont pas bien identifiés. Avec une architecture ou les principaux sont identifiés, et les éléments de la page sont compartimentés selon le principal auquel ils appartiennent, le DoS ne serait pas un problème (il suffit de limiter les ressources par principal, et de laisser l'utilisateur décider en cas d'abus) et les attaques cross-domaines seraient beaucoup plus difficiles. Il y a des gens qui travaillent sur ça, par exemple le projet Google Caja que j'ai déjà cité.
Je ne dis pas que c'est un problème facile à résoudre, ce n'est pas du tout le cas, surtout avec l'architecture (assez faible) actuelle (des navigateurs, mais surtout des langages de contenu et de script) et les contraintes de standardisation et de compatibilité très fortes. Mais ce sont bien des erreurs au niveau architectural que l'on pourrait régler en très grande partie avec une meilleure organisation. Il y a des gens qui travaillent sur ça et qui font des choses intéressantes, qui ont des impacts sur l'industrie.
[^] # Re: Oui, mais
Posté par Benoit Jacob (site web personnel) . Évalué à 7. Dernière modification le 22 janvier 2012 à 16:30.
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.
[^] # Re: Oui, mais
Posté par gasche . Évalué à 3.
C'est vrai que les techniques d'isolation ne peuvent pas transformer une faille de sécurité en non-bug: un bug reste un bug et dégradera toujours localement la qualité du service. Cependant une compartementalisation assez fine peut souvent limiter les nuisances possibles; par exemple si un composant plante, on peut souvent faire un choix par défaut raisonnable et le relancer, sans mettre en danger l'ensemble du système; de même si la granularité est assez fine les "choses à manger" ne présentent pas de risque (par exemple on ne veut pas qu'une exécution arbitraire de code dans le code qui affiche des images puisse accéder aux mots de passe stockés en mémoire par le gestionnaire de clés du navigateur).
Si justement, une isolation assez fine (pour cela il faut de l'information sur quels scripts correspondent à quels principaux) permet de faire tourner des parties du système avec des droits restreints, et donc en particulier d'utiliser des protections mémoires pour éviter ces difficultés; un compartiment donné pourra accéder à et corrompre la mémoire qui lui est propre, mais si l'architecture est bien pensée on a seulement un échec local du compartiment, ou injection de résultats faux (ce qui peut contaminer les compartiments communicants en provoquant des erreurs de leur côté, ce qui est bien sûr toujours possible, mais c'est un cas plus rare).
[^] # Re: Oui, mais
Posté par claudex . Évalué à 0.
Le problème à trop vouloir isolé, c'est qu'on va se retrouver avec une consommation mémoire qui explose. Il suffit de voir la consommation de Chrome par rapport à celle de Firefox quand on a plusieurs onglets ouverts. Et les navigateurs essayent aussi de lutter contre ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Oui, mais
Posté par barmic . Évalué à 3.
Non. Dans le cas de capsium/seccomp ça ne consomme quasiment aucune espace mémoire supplémentaire le noyau tiens juste à jour une liste d'appels systèmes autorisé ou non. l n'est pas question de virtualisation, comme xen, kvm ou la jvm.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oui, mais
Posté par claudex . Évalué à 5.
Dans le cas de capsicum/seccomp, on parle de privilège par processus. Si tu veux découper finement, tu dois donc avoir beaucoup plus de processus, donc tu as plus d'occupation mémoire.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Oui, mais
Posté par briaeros007 . Évalué à 1.
pas forcément
1°) sur les unix, les process sont réentrant donc il y a du code partagé parmis tous les processus, donc ce n'est que le contexte qui prend de la place.
Si les process sont petit et bien ciblé, le contexte peut être relativement petit (pas besoin d'une stack prévu (en taille) pour le multithreads pour un simple calcul
2°) tu n'as forcément de tous le code tout le temps, voir pour un utilisateur précis, rarement besoin de tout le code.
Un noyau "générique" avec des modules consomme moins qu'un noyau "générique" avec tout compilé en dur ?
[^] # Re: Oui, mais
Posté par Antoine . Évalué à 3.
Par contexte, tu entends les données ? Ça fait quand même un sacré morceau sur des applis haut niveau comme un navigateur Web.
C'est quoi, une "stack prévu pour le multithread" ? Vu que chaque thread a sa pile séparée, je ne vois pas du tout ce que tu veux dire.
[^] # Re: Oui, mais
Posté par briaeros007 . Évalué à 1.
Lorsque l'on découpe en plusieurs process, on peut découper les fonctionnalités aussi.
Lorsque tu fais un thread, l'adressage mémoire prévu pour la pile de ton processus est découpé entre sa pile et celle du(des) threads.
Par exemple si tu as beaucoup de threads, tu peux être amené à diminuer la taille de la stack de chacun de tes threads, ou la placer autre part, parce que tu ne peux plus "découper" la pile de ton process.
Si tu sais que tu n'as pas besoin de de multithread, et que tu n'as pas besoin d'une grosse pile, tu peux (en théorie, je ne sais pas comment on peut le faire en pratique sur un process) définir une taille de pile plus petite (le tas étant définis à la volée, cela ne devrait pas non plus être trop consommateur).
[^] # Re: Oui, mais
Posté par Antoine . Évalué à 2.
Cela me semble étrange. Intuitivement, une nouvelle pile est créée pour chaque thread, il n'y a pas besoin d'un "adressage mémoire" a priori.
[^] # Re: Oui, mais
Posté par briaeros007 . Évalué à 1.
A confirmer par quelqu'un qui s'y connait mieux que moi sur "où" est crée la pile par défaut du thread, mais je peux t'assurer que lorsqu'on créé un nombre élevé de thread, il faut commencer à jouer sur la taille de leur stack( avec pthread_attr_setstack ).
De plus la stack disponible d'un processus threadé est moins importante qu'un processus monothreadé ( http://en.wikipedia.org/wiki/Stack_overflow :
)
Et je ne suis pas sur que par défaut il fasse un malloc pour créer une nouvelle stack (pour la mettre autre part).
Enfin, toujours à confirmer, j'avais entendu parler de possibilité d'écrire dans la stack d'un autre thread à partir d'un stack overflow.
[^] # Re: Oui, mais
Posté par ckyl . Évalué à 5.
Le seul problème c'est l'exhaussion de ton espace d'addressage. À chaque fois que tu créés un thread, une memory area (un bout de l'espace d'adressage de ton process) est créé pour contenir la stack. Quand la somme de ces zones mémoire dépasse la taille de ton espace d'adressage (module la fragmentation) bin ca marche plus. Tu peux voir ca comme quand tu fais un mmap.
Du coup quand tu joues avec la taille de la stack c'est juste pour réussir à faire rentrer toutes les zones dans l'espace d'addressage.
[^] # Re: Oui, mais
Posté par ckyl . Évalué à 3.
Si ca t'intéresse c'est fait dans cette fonction là: http://www.koders.com/c/fid9B67C6313A774473B77A39EBA3A1A7315754326C.aspx?s=queue#L336 et plus particulièrement là: http://www.koders.com/c/fid9B67C6313A774473B77A39EBA3A1A7315754326C.aspx?s=queue#L483
[^] # Re: Oui, mais
Posté par briaeros007 . Évalué à 1.
merci pour ces précisions ;)
(ça fait vraiment longtemps que j'avais plus vu de code avec des __ devant les noms de fonctions ;))
[^] # Re: Oui, mais
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
Ca, ce n'est pas un probleme, le navigateur sait ca;
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?
[^] # Re: Oui, mais
Posté par Benoit Jacob (site web personnel) . Évalué à 5. Dernière modification le 22 janvier 2012 à 16:46.
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.
[^] # Re: Oui, mais
Posté par gasche . Évalué à 7.
J'étais déjà au courant pour l'analyse statique par exemple, mais j'ai souvent l'impression que ce sont des efforts qui restent très internes, et on n'en entend pas beaucoup parler. Qu'est-ce que les gens de Mozilla ont publié comme résultats concrets, réutilisables par l'extérieur, de leur travail sur ces outils ?
C'est très intéressant, et c'est précisément ça que tu devrais répondre, à mon avis, aux arguments que tu trouves "marketing". Des points techniques concrets sur les méthodes de sécurité employées sur Mozilla et leur impact sur l'industrie en général. Par exemple, j'invente : "voilà, on a expérimenté les outils de Clang d'analyse statique pour notre refcounting, et voilà ce qu'on a pu faire et ce qu'on propose aux gens qui voudraient faire pareil".
Je suis bien conscient que ton domaine spécifique, WebGL, est une plaie parce que vous vous prenez dans les dents tous les défauts des couches graphiques et du manque d'isolation à ce niveau là, sur lesquels vous n'avez quasiment aucun contrôle. C'est un autre vrai argument de fond.
[^] # Re: Oui, mais
Posté par Benoit Jacob (site web personnel) . Évalué à 6.
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)
[^] # Re: Oui, mais
Posté par Benoit Jacob (site web personnel) . Évalué à 0.
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.
[^] # Re: Oui, mais
Posté par gasche . Évalué à 4.
C'est la magie des notes, il ne faut pas y faire trop attention. En tout cas je n'ai pas mal pris ton commentaire du tout.
(J'en profite pour placer un commentaire que j'aurais pu mettre ailleurs.)
Tu parles de la "randomization" des adresses mémoires (ASLR) pour empêcher l'exploitation des buffer overflow, mais je voulais insister sur le fait que c'est une technique défensive qui ne se fait pas au même niveau que le sandboxing. La logique de l'ASLR c'est "j'ai un bug, comment rendre difficile de l'exploiter comme une faille de sécurité". Si tout se passe bien le bug n'est pas exploitable, et dans les mauvais cas (ou si l'attaquant est trop malin, genre toboggan et compagnie) on a une exécution de code arbitraire. C'est donc une protection du style "tomber dans le pire cas moins souvent". Au contraire le sandboxing consiste à réduire au maximum les privilèges du processus, de façon à ce qu'en cas d'exploitant (indépendamment de la fréquence de tels événements) les conséquences néfastes soient limitées : c'est une protection du style "faire que le pire cas soit moins grave". Donc pour moi les deux sont complémentaires, mais je pense que la compartementalisation est une technique plus fondamentale et plus efficace, qui devrait être une brique de base de tout système bien conçu, alors que l'ASLR est plutôt un détail d'implémentation efficace en pratique mais ne donnant aucune garantie réelle dans l'absolu.
[^] # Re: Oui, mais
Posté par Benoit Jacob (site web personnel) . Évalué à 3.
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).
[^] # Re: Oui, mais
Posté par gasche . Évalué à 3.
Encore une fois, non, ça ne doit pas être possible et, si c'est le cas, ça veut dire que la granularité de la compartementalisation n'est pas assez fine. Si j'ai deux onglets ouverts, l'un sur le site de ma banque et l'autre sur un site louche, je veux avoir la garantie qu'une exécution de code arbitraire (ou lecture/écriture arbitraire en mémoire) sur la partie qui traite le site louche ne puisse pas avoir accès à mes données bancaires. C'est une garantie possible dans l'absolu, mais cela demande une architecture bien pensée du côté du navigateur -- et un système hôte efficace pour que les coûts ne soient pas trop élevés.
[^] # Re: Oui, mais
Posté par claudex . Évalué à 2.
Ça me semble impossible ce que tu décris. Quand j'utilise mon navigateur, j'espère bien que les informations sont partagés entre les onglets, c'est ce qui permet de se loguer sur Facebook et de pouvoir utiliser les avantages (ou inconvénient, en fonction du points) de Facebook sur les autres sites.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Oui, mais
Posté par Jux (site web personnel) . Évalué à 2.
En fait c'est le genre de truc qui devrait être configurable. On devrait pouvoir ouvrir certains onglets en mode isolés et d'autres pas.
Il me semble que sous Chrome, on peut arriver à ça en utilisant la navigation privée sur le site de la banque.
De manière plus générale, une UI simple et intuitive qui permettrait de savoir/contrôler ce à quoi un site accède serait la bienvenue. Mais j'imagine que c'est pas tout simple.
[^] # Re: Oui, mais
Posté par claudex . Évalué à 2.
Il y a déjà eu des journaux sur le sujet, notamment : http://linuxfr.org/users/mildred/journaux/et-pourquoi-pas-un-nouveau-mod%C3%A8le-de-s%C3%A9curit%C3%A9-pour-le-web
Mais ce que tu décrit est envisageable pour le site de ta banque mais pas pour un compte Paypal par exemple. Même si c'est en théorie possible de demander l'authentification à chaque fois, les gens n'aiment pas et choisiront plutôt le navigateur qui leur permet de ne pas devoir s'identifier à chaque fois.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Oui, mais
Posté par djano . Évalué à 2.
Je te conseille ce blog: http://blog.mozilla.com/tglek/
Regarde les tags Pork et Dehydra. Je sais, ce n'est pas du tout récent, mais il y avait de gros efforts faits la dessus a un certain moment, et Brendan Eich (l'inventeur de JavaScript) en parlait pas mal. Ensuite, Mozilla fait partie de l'initiative Coverity Scan.
Bref, il y a des choses de faites sur ce plan la, mais elles ne sont pas parvenues jusqu’à toi.
[^] # Re: Oui, mais
Posté par imr . Évalué à 3.
C'est parce que tu fréquentes pas assez linuxfr; c'est de plus en plus facile, sinon.
[^] # Re: Oui, mais
Posté par Antoine . Évalué à 2.
C'est parce que ces stagiaires sont aussi des lecteurs assidus de Linuxfr que l'on a droit, justement, à des informations de première qualité !
[^] # Re: Oui, mais
Posté par Guillaume Knispel . Évalué à 1.
C'est pas une solution miracle, mais faut pas non plus exagérer dans l'autre sens, tenter d'éliminer des classes de vulnérabilité et/ou élever des barrières génériques faisant monter la difficulté d'un attaquant n'est pas une approche totalement inefficace non plus. Dans le domaine des OS, les choses comme l'ASLR and co ne font pas vraiment débat quand au mieux que ça apporte en terme de sécu. Que quelques détails de Chrome ne constituent pas à eux seuls l'alpha et l'omega, c'est évident, mais on ne peut pas leur reprocher de les utiliser ni de communiquer sur le sujet. Après si la communication devient parodique, il en effet bon que quelqu'un comme toi essaye de ramener les gens à la raison et de leur dire "et oh ! c'est bien gentil mais c'est pas non plus une présentation parfaitement juste des choses"
[^] # Re: Oui, mais
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
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.
[^] # Re: Oui, mais
Posté par Littleboy . Évalué à 4.
Euh, c'est ce qu'a fait le departement marketing de Mozilla pendant des annees sur IE (et autant pour les versions 6-8 c'etait de bonne guerre, autant les derniers messages marketing sur la version 9 font un peu pitie). Mettre en avant ce que la concurrence n'a pas pour vendre son produit, c'est quand meme le ba-ba.
Apres avoir ete leader pendant des annees sur le technique, c'est sur que ca fait jamais plaisir de se reprendre ses messages marketing remplis de mauvaise foi dans la figure. Rappelons nous juste que si c'etait vous dans la position de Chrome, votre departement marketing ne se generait pas pour appuyer la ou ca fait mal...
[^] # Re: Oui, mais
Posté par Benoit Jacob (site web personnel) . Évalué à 0.
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?
[^] # Re: Oui, mais
Posté par Littleboy . Évalué à 8.
Bon, prenons cet exemple, puisque visiblement on a pas la meme vision des choses:
Is IE9 a modern browser? NO
La technique qui consiste a faire passer par des canaux encore consideres comme "non officiels" de la communication marketing, c'est pas nouveau, toutes les grosses boites le font. Venir dire apres que ca n'engage pas la boite elle-meme quand ca vient de personnes haut placees dans la hierarchie, c'est se moquer des gens.
Et notons quand meme que sur le coup, Paul a fait du tres bon boulot comme Technology Evangelist. Meme si on peut trouver son article discutable, ca a beaucoup fait parler de Mozilla et Firefox en bien avec la majorite des critiques sur des points techniques de son article.
[^] # Re: Oui, mais
Posté par Benoit Jacob (site web personnel) . Évalué à 1. Dernière modification le 23 janvier 2012 à 01:38.
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.
[^] # Re: Oui, mais
Posté par Littleboy . Évalué à 6.
Quand ton job, c'est de faire de l'evangelisme, que tu publies un article de communication (c'est pas un blog, c'est pas marque comme page perso ou opinion, c'est pas marque comme n'etant pas la comm' de son employeur) et que c'est repris partout, qu'a aucun moment ton employeur ne dit que ca n'est pas representatif de leur position, que c'est cite par plusieurs canaux au sein meme de Mozilla (blogs, newsletters, minutes des meetings de dev) j'ai tendance a penser qu'affirmer que c'est juste un truc perso est assez difficile.
Et comme dit dans mon post initial, c'est tellement utilise (dernier exemple passe ici, Opera qui se plaint d'Apple et ses brevets) qu'il n'y a pas vraiment de mal. Tout au plus ca permet de se justifier si le message passe mal dans les medias (ce qui n'a pas ete le cas ici, bien au contraire).
Et comme c'est pas un blog de developpeur, il n'y a ni accusation grave, ni en douce qui tienne. Paul fait son boulot en publiant des documents pour pousser l'utilisation de Firefox, je critique pas la demarche du tout.
En l'occurence, ca n'est pas un blog, c'est formate et prepare comme un article de communication, pret a distribuer aux gens.
Ca ressemble a un blog, vraiment?
https://people.mozilla.com/~prouget/ie9/ie9_vs_fx4.html
https://people.mozilla.com/~prouget/ie9/
Si c'etait sur son fil twitter que je me basais, je comprendrais ta reaction, mais ca ressemble pas a du blog perso avec des photos de vacances, la.
Quand Asa blog ou commente, generalement le departement marketing de Mozilla a des sueurs froides en se demandant quelle connerie il va faire :P
Dans la forme, c'est tout a fait a l'oppose, l'un fait de la pub pour Firefox avec la mise en forme d'une plaquette de pub, l'autre commente sur son blog pour dire que Thunderbird ca pue et qu'il utilise un logiciel d'une autre entreprise ou pour dire que Mozilla n'en a rien a battre des clients en entreprise. Bref, rien a voir.
Les journaux en question ont peut-etre assez vu de blogs pour faire la difference avec le cas qui nous occupe. Et ces memes journaux idiots sont assez en relation avec le departement PR de Mozilla pour que s'il y avait des rectifications a faire, cela aurait pu etre fait facilement.
Bref, pour revenir au sujet de depart, Mozilla a aussi communique sur les defauts d'un autre navigateur en prenant une liste des fonctionnalites manquantes, ce qui contredit un peu ton affirmation initiale.
[^] # Re: Oui, mais
Posté par Zenitram (site web personnel) . Évalué à 5.
Oui, ils ont le droit à leur opinion independamment de leur role officiel.
Quand ils l'écrivent bien, qu'on comprenne la différence.
Ici, dans l'exemple mis en avant, ce n'est pas le cas.
Faut arrêter de prendre les gens pour plus con qu'ils ne le sont (on est déjà assez con comme ça)
Je ne crois pas. Au contraire.
Mais déjà, reprenons l'URL:
people.mozilla.com/~prouget/ie9/
Ah, oui... Comment on peut savoir que c'est "perso" et pas son boulot?
Mais bon, l'adresse de ton post original, c'est quoi?
blog.mozilla.com/bjacob ...
Ah oui, aussi.
Une URL, ça compte, entre autre. Au moins Tristan Nitot, par exemple, écrit sur un blog à part, et avertit.
Ce qui énorme, c'est de croire que ça ne fait pas partie de son/vos boulots, quand tout est fait pour le faire penser, plutôt? 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...
Désolé, mais on donne un avis perso sur un produit de sa boite, généralement, on le dit, en gros, justement pour que ces "idiots de journalistes" ne se trompent pas. "Disclaimer" machin-chose. Dans le post ici, d'ailleurs, on sait que tu bosses pour Mozilla, mais on ne sait pas si c'est du boulot (entre guillemets : bref, "faire de la vente" pour ton employeur) ou un avis perso.
Trop facile la technique du "ah mais non, nous on dit rien, si on tape sur le concurrent c'est juste perso, mais on ne le dit pas explicitement, comme ça on adapte suivant les réactions, si ça cogne positivement on laisse faire, sinon on adapte".
Alors le journal/dépêche est intéressant, les réponses aux commentaires aussi, pour débattre, c'est super, mais certains n'oublient pas qui est l'employeur pour autant, pour faire la part des choses.
[^] # Re: Oui, mais
Posté par Benoit Jacob (site web personnel) . Évalué à -1.
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.
[^] # Re: Oui, mais
Posté par Littleboy . Évalué à 4.
Lorsque les commentaires d'Asa sur le support pour entreprises ont commence a faire la une des journaux, l'equipe PR de Mozilla (et l'equipe technique derriere) a reagi pour essayer de modifier la perception des choses (ie. rattraper la merde causee par Asa).
Je pense que c'est de ce genre de chose dont parle Zenitram. Evidemment, dans le cas present ca serait tres con de se desolidariser d'un message en votre faveur, surtout quand c'est repris de maniere globalement positive par la presse et les blogs et que ca fait le tour de Twitter (ce qui etait le but de Paul avec une joli infographie et un message simple a repeter).
Si tu vois pas pourquoi on fait la difference entre ton blog (toujours avec le theme par defaut), un article sur LinuxFR et la plaquette de communication sur IE9 avec ses jolis graphiques, je pense qu'on arrivera a rien.
[^] # Re: Oui, mais
Posté par barmic . Évalué à 3.
Il me semble normal de parler bien plus de solutions de sécurité :
plutôt que 3 bugs spécifiques au mieux au navigateurs au pire à firefox uniquement (non pas que les autres ne soient pas affecté mais que la résolution chez l'un ne puisse être réutilisée chez l'autre indépendamment des licences).
Après je te remercie de parler de ces bugs de sécurité, je pense que décortiquer un minimum des bugs de sécurité aide tout le monde à devenir plus vigilent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oui, mais
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
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.
# Pas réellement exploitable ?...
Posté par gdelugre . Évalué à 1.
En théorie ?...
Pas réellement exploitable ?...
Mozilla n'a jamais vu d'exploit réel pour son navigateur ? Sérieusement ?
Plusieurs points importants :
1. Certains bugs restent exploitables malgré l'ASLR et le DEP. Et oui ca s'exploite réellement (au cas où l'auteur en douterait).
2. Les vulns ont beau être corrigées rapidement, dans la vraie vie tous les navigateurs ne sont pas à jour pour autant.
3. Toujours dans la vraie vie, les attaquants ont en mains des vulnérabilités que vous ne possédez pas chez Mozilla. D'où l'intérêt de porter la sécurité en amont et de sandboxer le navigateur dans un processus non-privilégié, au cas où l'attaquant parviendrait à ses fins.
"Pas exploitable", franchement faudrait atterrir...
[^] # Re: Pas réellement exploitable ?...
Posté par coïn . Évalué à -2.
Je suis d'accord, mais dans la vrai vie, tu parles de quel bug en particulier ?
Parce que le sandbox, ca donne une impression de sécurité mais ce n'est pas absolue, autant qu'un airbag en fait, ca n'empêche pas l'accident, et c'est parfois mortel.
[^] # Re: Pas réellement exploitable ?...
Posté par gdelugre . Évalué à 2.
On est d'accord, ce n'est pas la protection absolue. Et en soit se dire qu'on va bétonner au cas où un attaquant obtient l'exécution de code, c'est même plutôt mauvais signe.
Mais ça part d'un constat : les navigateurs sont régulièrement soumis à des vulnérabilités de ce type, et suivant les cas ces vulnérabilités seront exploitables par un attaquant. Et il y en aura encore à l'avenir, c'est la que la sandbox entre en jeu, pour tenter de limiter l'impact d'un futur attaquant sur le système. Il y a une vraie idée de la sécurité derrière, c'est pas juste une opération de comm...
Je ne reproche pas non plus à Firefox de ne pas avoir de sandbox. Si on me disait que c'était pas la priorité du moment, ou qu'il faudrait plus de développeurs ou autre, je comprendrais. Mais de là à dire que les vulnérabilités ne sont pas exploitables, non, là c'est ridicule.
[^] # Re: Pas réellement exploitable ?...
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
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.
[^] # Re: Pas réellement exploitable ?...
Posté par cowboy . Évalué à -7. Dernière modification le 23 janvier 2012 à 14:24.
Ce commentaire montre bien ton incompréhension de la sécurité, tu dis toi même que tu n'y connais pas grand chose, et cela transparaît.
Ton commentaire sur le point numéro 3 est particulièrement révélateur : bien qu'il soit louable de chercher à détecter les failles en amont et à inciter les gens à reporter les failles, par exemple contre rémunération, ceci n'est absolument pas suffisant et il se trouvera toujours des personnes suffisamment motivées pour trouver des failles exploitables.
Certes DEP et ASLR aident, mais clairement ces mécanismes sont contournables et régulièrement contournés.
Chrome a clairement pris l'approche la plus proactive en matière de sécurité : faire en sorte que toute exploitation ne porte pas à de grave conséquences sur le système. Tu dis qu'il est aussi grave qu'un exploit permette d'accéder aux données de la session de navigation en cours. Certes ce n'est pas génial, mais la sandbox permet d'éviter (normalement) toute persistance de l'attaque, évite que le système entier soit compromis (et puisse donc servir de relai pour du spam ou d'autres attaques).
Alors oui effectivement Google utilise cette étude pour communiquer, mais il est indéniable que Chrome est beaucoup plus sécurisé que Firefox. Pas uniquement au niveau de la sandbox, mais également au niveau de TLS, des certificats etc.
Comment ne pas interpréter ton post comme une réaction puérile de la part de Mozilla qui se voit dépassé et qui, au lieu de réagir et de renforcer la sécurité, critique la communication ?
[^] # Re: Pas réellement exploitable ?...
Posté par Zenitram (site web personnel) . Évalué à 5.
Euh... Chrome ne gère toujours pas TLS 1.2 (spec de 2008!) à ma connaissance. Alors que IE 9 (le truc critiqué si souvent...) et Opera le supportent, eux. Alors qu'on commencer à voir les failles dans TLS 1.0 être utilisées (et patchées à coup de bidouilles, du coup)
Donc bon : Chrome, bof, il y a certes le sandboxing pour éviter qu'un site malvéillant foute le bordel, mais ils oublient quand même (tout comme Mozilla) l'accès par un tiers sur le chemin... Ce qui est quand même un peu surprenant pour des éditeurs qui disent faire attention à la sécu, non? (2 navigateurs proprio sont en avance, les navigateurs libres à la ramasse...)
Chrome et Firefox, 0 partout sur TLS.
[^] # Re: Pas réellement exploitable ?...
Posté par gasche . Évalué à 10.
Je trouve que tu vas un peu loin; Benoît Jacob fait un commentaire sur son domaine spécique, WebGL, qui est assez jeune et où les pratiques de sécurité sont naissances et les failles inattendues (franchement la timing attack sur les rendus de pixel, personne ne l'avait vue venir...). Il reconnaît bien volontiers ne pas être un expert (moi aussi d'ailleurs), mais tes propos peuvent quand même être blessants.
Je ne vois rien de "puérile" dans sa réaction et je ne pense pas que ça ait de sens de lui faire un procès d'intention en parlant de "réaction de Mozilla" alors qu'il s'agit de son avis personnel; il a un positionnement affectif vis-à-vis de son entreprise et réagit en prenant à cœur des critiques qu'il ne juge pas méritées, je pense qu'on peut comprendre ça sans tirer sur le messager.
Au contraire, je pense que son effort pour donner son ressenti de la situation est louable, et que c'est une bonne idée d'apporter ce genre de contenus à LinuxFR. C'est très bien qu'il y ait un débat, mais c'est encore mieux s'il se fait de façon détendue et qu'il motive les vocations d'autre gens voulant porter leur avis ici.
# hors-sujet²
Posté par bubar🦥 (Mastodon) . Évalué à 2. Dernière modification le 23 janvier 2012 à 23:11.
Bonsoir, je profite de cette dépêche pour deux remarques. La première sur WebGL : chezmoiçamarche(tm), donc merci :-) L'affichage du cube, site khronos, est parfait. Celui de get.webgl est en fil de fer, et nombreuses "expériences" webgl fonctionnent très très bien :-) (Firefox 9 sur fed 16) Tandisque Chrome, même en lui passant l'option spécifique, refuse de m'afficher quoi que soit en webgl ... Bref, vous avez l'air d'avoir pris de l'avance sur le sujet, pour les petites configs (i915) du moins :-)
La seconde remarque concerne les cookies. Actuellement firefox propose une interface plus facile à utiliser que celle de chrome, mais toujours la même depuis des années. Or le contenu explose, le stockage local de ce types d'éléments (cookie, dso, j'en passe certainement..) aussi, logiquement. Si je comprends que des navigateurs à vocation "plus commerciale" ne puisse pas faire autrement, peut être que firefox le pourrait... Actuellement tous proposent soit une effacement général (entrainant des désagréments de navigation) soit un effacement pièce à pièce (particulièrement laborieux) Cela serait pas mal de disposer d'une fonction inversée à celle actuellement proposée. Disposer d'un marqueur à contenu permettant de dire "ceux là je souhaite les garder, et tout le reste sera effacé systématiquement". Ça serait vraiment bien bien pratique, ça : une fonction visible, facilement accessible, de "marqueur" ou de "coffre" à cookies qu'on souhaite garder, et tout le reste, zou... Voilà Voilà ;) Mes deux cents.
[^] # Re: hors-sujet²
Posté par Zenitram (site web personnel) . Évalué à 2.
https://bugzilla.mozilla.org/request.cgi ?
(en tant que développeur, je trouve pas du tout pratique les gens qui mettent leur demande sur 100 sites différents, la où ils squattent parce que c'est plus pratique, mais qui n'est pas celui du logiciel, et dans leur langue en plus, le développeur de la fonctionnalité x n'étant pas forcément le français qui développe la fonctionnalité y demandée lors d'une discussion sur la fonctionnalité x. Ce genre de demande est tout simplement ignorée, déjà que quand c'est sur le tracker ça peut attendre des lustres)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.