Chine : une faille 0 Day d‘Internet Explorer utilisée contre Google

J'ai une question à poser aux connaisseurs de sandbox, en espérant ne pas être trop HS. Il y a peu, j'ai installé le logiciel Sandboxie (la version gratos) sur mon XP et j'aimerais savoir si, lorsqu'on fait tourner un navigateur dedans (IE, Fx, Opera, etc), on est en totale sécurité lorsqu'on tombe sur un site piégé exploitant une faille de sécurité (quel que soit son niveau et quel qu'elle soit) ?
J'avais lu que ce genre de soft était efficace, mais j'aimerais savoir ce qu'il en est réellement. Et j'aimerais savoir s'il y a notamment des limites dans la protection (style certains types de failles qui sont susceptibles d'outrepasser la sandbox).

Merci.

@ link385:

Je ne faisais pas réellement la distinction entre "proprio" et "open source" sur le plan de la visibilité du code source, mais sur le fonctionnement de l'éditeur du logiciel (dans le cas open-source, on travaille plus souvent en "communauté", ce qui implique un fonctionnement différent. Maintenant, p-e que certains logiciels proprios fonctionnent comme Firefox ou que certains logiciels open-source fonctionnent comme IE).
Tu soulignes toi-même cette différence en faisant remarquer que le rapport "failles corrigées en interne"/"failles corrigées en externes" était différent entre Firefox et IE.

Je suis d'accord sur le raisonnement:
-début: peu de failles
-début du succés: bcp de failles
-ensuite: moins de failles
(et encore: que se passe-t-il si on subdivise le logiciel en ses différentes parties: Gecko est utilisé depuis bcp plus longtemps que TraceMonkey. Donc, à l'introduction de TraceMonkey, Gecko est à la 3éme étape tandis que TraceMonkey est à la 2éme. Quel est le bilan global ?)
Or, je ne suis pas d'accord avec le raisonnement:
"nombre de failles passées du logiciel A < nombre de failles passées du logiciel B" implique "nombre de failles futures du logiciel A < nombre de failles futures du logiciel B", ce qui était le point de départ de la discussion.

Par exemple, aujourd'hui, Firefox et IE sont au même point (la différence de failles entre les 2 est sans doute due au fait que MS ne communique pas sur les failles trouvées en interne et investit plus de moyens là-dedans), et à part madame Soleil, je ne vois pas comment on pourrait prévoir lequel sera le plus sensible dans le futur.

(sinon, concernant le financement (qui reste bien largement inférieur aux moyens que peut investir MS, donc, mon argument tient), je ne vois pas pourquoi Mozilla investirait plus dans une équipe de chasseurs de failles en interne, vu que ce travail est fait en externe. Ce serait plus judicieux de l'investir là où il y a des manques plus flagrant (et il y en a))

en théorie, oui, un logiciel comme sandboxie est sensé jouer le meme role que la sandbox d'IE sous vista, c à d ça n'empeche pas l'exploitation des failles, mais ça empeche l'installation d'un malware sur ta session ou ton ordi en cas d'exploitation de la faille, puisque la sandbox permet (en gros) d'empecher le malware d'écrire sur le disque dur. Par contre sous xp ça nécessite que le disque dur soit formaté en NTFS. (et les clefs usb formatées en fat peuvent se faire infecter si un malware exploite une faille au moment où la clef est branchée)

Par contre il faut etre conscient que si tu n'as appliqué aucune maj de sécurité à ton systeme, il est théoriquement possible d'exploiter des vieilles failles du noyau windows pour outrepasser cette protection. Mais ça reste assez improbable.

si le nouveau code a été codé avec de bonnes pratiques, il ajoute peu de nouvelles failles, ce qui ne devrait pas changer la tendance de maniere significative.

cela dit mozilla a la particularité d'utiliser du code source d'autres projets... par exemple pour html5, ils ont incorporé du code source venant d'un autre projet pour supporter theora, et suite à cela des failles ont été découvertes dans ce projet (du fait de son exposition suite à son intégration dans firefox). Donc si les projets non développés par mozilla ne sont pas développés avec de bonnes pratiques, ça peut également augmenter le nombre de failles découvertes de maniere significative.



comme je l'ai déjà dit, meme en supposant que microsoft corrige des failles discretement sans le signaler (je doute que ce soit le cas), si tu élimines les failles découvertes en interne chez mozilla (1tiers des failles), ça donne toujours 80 failles par an, contre 30ans IE.

de toutes façons peu importe le nombre de failles, il reste nettement plus sécurisé d'utiliser IE sous vista puisqu'il tourne en sandbox (et les plugins à risque comme flash et adobe reader aussi). Les deux navigateurs ayant de grandes chances d'etre touchés par des failles 0day (que ce soit les leurs ou celles de leurs plugins), il est domage que firefox ne suive pas la même voie que IE et chrome (bien que chrome ne sandboxe pas encore les plugins)




difficile de savoir combien de personnes cherchent des failles dans un projet donné.
donc compter sur eux pour trouver les failles, c'est risqué, d'autant plus qu'un chercheur de failles externe n'est pas forcément bienveillant.

La recherche en interne AVANT sortie du produit est donc largement plus sécure. Et ça ne coute pas si cher que ça, ça ne coute pas des millions de $, mais c'est vrai que c'est un travail difficile et long.
Concernant mozilla, pour une question de réactivité (sortir le produit plus vite), ils publient un produit un produit quelques jours ou heures après sa finalisation. Ca ne laisse pas vraiment le temps de faire un audit de sécurité comme le fait microsoft sur ses produits (cela dure plusieurs semaines, en plus de l'audit continu effectué pendant les betas).

@ link385:

Donc, d'après toi, si je crée from scratch avec les bonnes pratiques, la courbe des failles est inapplicable. C'est bien ce que je voulais prouver: se baser sur les failles pour évaluer la sécurisation, c'est vraiment n'importe quoi.

Notons qu'incorporer du code source d'autres projets peut également être un atout en matière de sécurité. Imaginons l'inverse: un logiciel a besoin d'un moteur de navigateur suffisamment souple qui fonctionne dans son programme (pour x ou y raisons, utiliser directement le moteur de rendu ne fonctionne pas ou n'est pas suffisant). Dans ce cas, mieux vaut qu'il reprenne le code tout-fait de Mozilla (ou MS) plutot que de coder from scratch dans un domaine (sécurité sur le web) qu'il ne maitrise pas forcement.
Qui s'y connait le mieux pour garantir la sécurité lorsqu'il s'agit d'exploiter une subtilité d'un contenu multimédia ? La team qui bosse sur theora, qui sont experts en multimédia, ou la team de firefox, qui sont expert en sécurité sur le web ?
Dans le cas que tu cites, cela s'est averré négatif, mais de là à en conclure que c'est tjrs négatif, de nouveau, tu sembles manquer d'abstraction et tu crées des pseudo-lois sur des informations mal dégrossies (ne m'en veux pas, mais c'est réellement à ça que tu me fais penser, sans resentiment de ma part. Pour la plupart de tes exemples, tu conclus trop vite alors que des contre-exemples existent ou qu'on peut très facilement imaginer un cas où cela ne fonctionne plus).

Concernant le nombre de failles, j'ai dit: "et investit plus de moyens là-dedans".
En d'autres termes:
IE: en interne X1 failles, en externe Y1 failles
FF: en interne X2 failles, en externe Y2 failles
Il existe une solution mathématique pour:
X1+Y1 = X2+Y2 avec:
MS investit plus dans la correction interne: X1>X2,
Il y a plus de failles de FF corrigées en externe: Y2>X2,
Il y a plus de failles public chez FF que chez IE: X2+Y2>Y1
(essaie par exemple 50+30=20+60, ce qui donne: FF: X2+Y2=80 failles par an, IE: Y1=30 failles par an)

Je suis entièrement d'accord pour les sandbox: cela fait partie de mon deuxième critère (message 147, 3 jours plus tôt !! Tout ça pour en revenir là).

Notons finallement que Mozilla sort son produit en beta, ce qui signifie ce que ça signifie en terme de sécurité. La version stable (où la version stable + 1 mois, si tu penses qu'elle mérite plus de retour) de Mozilla a déjà été au moins partiellement testé (si pas completement. A priori, rien n'empêche FF d'être même plus testé que IE, dont l'équipe de test est limité au revenu dédié à cette tâche par MS et auquel les externes font suffisamment confiance pour être moins précausionneux qu'avec FF).
Ensuite, Imaginons que Mozilla attende qu'il y a assez de retour sur les failles de la beta pour témoigner d'une "traque aux failles" suffisante, en quoi est-ce différent de MS qui fait ses tests en interne ?
Notons aussi que si un externe est malhonnête et ne fait pas de retour, il y a autant de chance pour qu'un externe honnête la trouve et la corrige. La situation est totalement identique avec MS: dans les 2 cas, on a une équipe qui teste le logiciel. Le fait que la beta soit public ou non ne change rien, car les failles qui sont laissées passées par les testeurs externes sont équivalentes aux failles laissées passées par les testeurs internes de MS.


Edité par j-c_32 le lundi 18 janvier 2010 à 20:49

sauf qu'en pratique, les gros logiciels qu'on utilise aujourd'hui ont tout démarré à une époque où les pratiques de dev sécurisé étaient quasi inexistantes, et même encore aujourd'hui un petit projet a de fortes chance de démarrer avec des pratiques de sécurité assez limitées (et le developpeur du projet risque de penser que c'est suffisant car personne n'a encore découvert de failles dans son code)

du coup le phénomene que je décris reste applicable à de nombreux projets, à condition qu'ils connaissent une phase de succès massif.



oui tout à fait, il est généralement admis que réinventer la roue n'est pas une bonne chose en info

cela dit, si on crée une appli qui a besoin d'un moteur HTML et qu'on sait qu'on ne pourra pas le mettre à jour (rapidement ou pire, jamais) en cas de faille (inconvénient lorsqu'on utilise autre chose qu'IE), du coup dans cette situation là créer un moteur html limité (comme sous java) aux fonctionnalités dont on a besoin peut etre plus secure (surtout s'il est écrit en code managé), et si faille il y a, selon la faible popularité du projet, il se peut que personne ne les trouve, alors qu'utiliser un moteur courant non mis à jour est très dangereux. Bref, il n'y a pas de solution miracle universelle... il y a des cas où la sécurité par l'obscurité ça marche (pas en masquant son code source, mais en s'appuyant sur la faible popularité d'un programme), bien sûr comme je l'ai déjà dit c'est une sécurité "ressentie", et non une sécurité fondamentale.



je comprend que tu mettes en doute mon raisonnement (qui est pourtant partagé par bien des experts), mais il est souvent valable, mais évidemment pas dans toutes les situations.

en tout cas concernant les libs de décodage video, je me doute depuis des années qu'elles vont devenir la prochaine cible des hackers.
la création d'une lib de décodage video/audio ne débute en général pas sur des impératifs de sécurité... à tort puisque lorsqu'une lib de video se retrouve incluse dans un navigateur (comme theora sous firefox) ou accessible au navigateur via un wrapper (c à d tous les codecs directshow installés sur le systeme sont accessive via WMP sous IE), alors elle devient un vecteur d'attaque potentiel. C'est ce qui s'est produit avec IE et le parseur de fichiers mov inclu dans XP l'an dernier. Et ça va se produire de plus en plus souvent sous IE (via wmp) comme firefox.

Les libs de video open source sont peut etre très stables et performantes, mais je suis certain qu'elles ne sont absolument pas sécurisées et leur intégration dans les navigateurs web modernes va occasionner la découvertes d'un certain nombre de failles qui n'avaient pas été découvertes jusque là, faute d'exposition suffisante.
Idem pour les codecs directshow closed source ou non.




c'est quoi le but? prouver que les developpeurs d'IE produisent autant de failles que les devs de firefox avec des équations, et inventer des chiffres basés sur aucun fait pour que ça colle?



pourtant mozilla ne semble pas de cet avis. Quelque chose semble les retenir... une trop grande confiance en la qualité de leur code peut etre?

un test effectué par des utilisateurs != un test mené par des équipes de review de sécurité pendant des semaines après que le code soit finalisé (pour le rattraper en cas de soucis majeur).

IE a lui aussi ses phases de beta/RC.
remarque qu'il est fréquent que mozilla corrige rapidement des bugs dans les fonctionnalités de firefox après la sortie d'une nouvelle version majeure (plantages, fonctions qui ne marchent pas correctement)

Avec IE7/8 il n'y a pas eu ce besoin (beaucoup d'entreprises utilisent d'ailleurs IE6/7/8 rtm sans aucun patch, et sont satisfaites de sa stabilité)



sur un code de plusieurs millions de ligne, sachant qu'une faille découverte aujourd'hui a des chances d'etre là depuis des années, si quelqu'un de malveillant trouve une faille, il y a des chances que la failles en question reste "secrete" pendant des années. C'est valable pour tous les logiciels complexes.



attention, le développement sécurisé, ce n'est pas que du test. C'est prendre les mesures nécessaires pour mitiger les risques futurs à l'avance pour diminuer l'impact des failles. Par exemple les dernieres versions d'office contiennent un module qui vérifie qu'un fichier est bien formé avant de l'ouvrir dans office (c'est totalement transparent pour l'utilisateur), et ça marche, car cela a permis d'éviter l'exploitation dans office 2007 de failles existant depuis plusieurs versions d'office.
Bref, le developpement sécurisé, c'est pas juste du test, ce n'est pas non plus la tentative (perdue d'avance) d'éliminer toutes les failles, c'est avant tout une maniere de faire en sorte que l'architecture d'une appli soit plus robuste en validant mieux les entrées de données, et en évitant qu'un contenu malveillant puisse atteindre les parties du logiciel les plus complexes et sur lesquelles on a le plus de doutes niveau sécurité.

Edité par link385 le lundi 18 janvier 2010 à 23:36

Raisonnement absurde, maintes et maintes fois démonté ! Déjà, on pourrait, si on voulait rester chez M$, utiliser IE5-16bits sur Wfw3.11.
Aussi, on pourrait quitter le monde d'XP, on ferait déjà l'économie d'un antivirus sur chaque poste de travail. Egalement, monter une architecture robuste, avec un serveur qui contient le système en readonly, monté au boot par chaque poste client, puis ensuite le /home local monté en noexec. Bonne chance pour implanter un malware dedans. Bon, on pourra toujours tenter un dépassement de buffer dans une appli web, tu me diras. N'empêche que malgré toutes les *box, tous les routeurs, et les 2 tiers des hébergements web en pas-M$, on attend toujours le virus-de-la-mort-qui-tue genre worm-klez, blaster, et le post est trop court pour en écrire 1000000...

Sauf qu'on parle d'IE6, le cauchemard de tous les webmasters. Tu es hors sujet jeune padawan !