lundi 22 mars

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Articles

Liens connexes

le message sur securityfocus (3659 clics)

Dépêche modérée par

Ragnagna

Articles : La robustesse de nombreux navigateurs web mise en cause

Posté par Troy McClure (page perso, ). Modéré le 20 octobre 2004.

Michal Zalewski a développé un petit script capable de générer du code html invalide, dans le but de tester la robustesse des principaux navigateurs (Mozilla, IE, Opera, lynx,..). Comme il l'explique dans ce message sur securityfocus , la majorité des navigateurs a pu être mis en difficulté très rapidement (plantages, explosion de mémoire.. un certain nombre de ces plantages pouvant bien sûr conduire à une faille de sécurité), à l'exception notable de Internet Explorer.

le message sur securityfocus (3659 clics)

> Lire les commentaires (125 commentaires, moyenne: 2,7).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Pour IE c'est le code VALIDE qui fait planter :D

Posté par nicoprog () le 20/10/2004 à 06:39. (lien). Évalué à 10.

Pour IE c'est le code VALIDE qui fait planter :D

http://mapage.noos.fr/ccomb/testIE.html(...)

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

Posté par Alexandre Beraud () le 20/10/2004 à 07:48. (lien). Évalué à 5.
En attendant, cet article semble mettre IE au dessus du lot. Pas tres bon pour Mozilla/Firefox qui se targue de posseder moins de failles que son grand concurrent.
- [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par samds () le 20/10/2004 à 07:59. (lien). Évalué à 8.
 D'un autre coté, maintenant que c'est dit, le problème va être réglé et on en parlera plus. Alors que pour IE ....... on connait tous la suite. Enfin, la pas de suite justement :)
 
 Des bugs Mozilla ou Firefox y en a des tonnes, comme pour IE. La différence c'est que nous [la communauté du libre] prennont le soin de les corriger [rapidement].
 - [+] [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par walter orengo (page perso, ) le 20/10/2004 à 11:06. (lien). Évalué à -2.
 je cite " D'un autre coté, maintenant que c'est dit, le problème va être réglé et on en parlera plus. Alors que pour IE ....... on connait tous la suite. Enfin, la pas de suite justement :)
 
 Des bugs Mozilla ou Firefox y en a des tonnes, comme pour IE. La différence c'est que nous [la communauté du libre] prennont le soin de les corriger [rapidement]. "
 
 je vais pas chercher à troller ni à défendre M$, je suis utilisateur de IE et de firefox, ce dernier il est vrai est + respectueux du w3c, et je me bute quotidiennement à des sites optimisés ie et qui ressemblent à rien sous firefox ...
 
 Mais ... justement la différence entre IE et mozilla, c'est que l'un fait plus parti du monde du libre et profite donc de sources intarrissables de gens qui sont là pour faire vivre et evoluer la chose, ie c'est windows, pas linux, c'est un produit commercial finit et dans un état x à un moment donné qui malgré de nombreux patch correctifs, est sortit d'une société , l'autre est en constante évolution au fur et à mesure de son utilisation ... pour moi on ne peut pas comparer les 2, c'est comme comparer linux et windows ! enfin je sais pas si tu vois ce que je veux dire. mais selon moi tjrs sans vouloir troller, linux et windows ne sont pas comparable ... on voit tjrs sur les forums des gens cracher sur M$ pour différentes raison mais la pluspart du temps ce sont de fausses raisons... M$ n'est qu'une société ... et ils les font leurs correctifs ...
 
 une chose qui bouge c'est la part de marché de IE, qui ne cesse de diminuer ... c'est bien ... mais il reste encore largement majoritaire ...
 
 ce qu'il y a c'est que l'article est pas terrible, on parle de test de code invalide, alors qu'ie déjà gobe du code non w3c, en gros tout et nimpk, donc le résultat ne m'étonne guère ... modifier firefox pour ne plus planter sur ce test bidon ça veut dire le rendre capable de gober n'importe quoi, comme ie, et de se foutre du w3c .... hors le but de ce navigateur est de se targuer de cela ...
 
 ou alors je me gourre completement.
 
 --
 HéHéHé
 - [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 Posté par golum () le 20/10/2004 à 11:15. (lien). Évalué à 10.
 
 modifier firefox pour ne plus planter sur ce test bidon ça veut dire le rendre capable de gober n'importe quoi, comme ie, et de se foutre du w3c .... hors le but de ce navigateur est de se targuer de cela ...
 
 Euh ... excuses moi là, ne pas gober du code mal formaté est une chose mais crasher et provoquer un trou de sécurité n'est pas le top.
 
 Ce qu'on demande à firefox c'est de nous avertir poliment que la page n'est pas conforme, la bloquer ou s'il en est capable et qu'on l'y autorise de l'afficher du mieux qu'il peut.
 
 Ca serait pas mieux ça ... et on peut compter sur l'équipe Mozilla pour régler ça ;-)
 - [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par Matthieu Moy (page perso, ) le 20/10/2004 à 14:12. (lien). Évalué à 6.
 C'est clair. Y'a une différence entre
 
 $ gcc toto.c
 toto.c:3: syntax error
 
 et
 
 $ gcc toto.c
 Internal compiler error
 Please submit a full bug report bla bla bla
 
 ;-)
 
 [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par Christophe Chailloleau-Leclerc (Jabber id, page perso, ) le 20/10/2004 à 14:57. (lien). Évalué à 3.
 J'aurais plutôt comparé à :
 
 $ gcc toto.c
 #
 
 (en considérant évidemment que $ représente un prompt utilisateur, et # un prompt root).
 
 [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par Matthieu Moy (page perso, ) le 20/10/2004 à 15:27. (lien). Évalué à 3.
 Euh, pas vraiment. Si quelque chose dans un programme (non set-uid) te permet de passer root, c'est qu'il y a une faille dans ton noyau aussi.
 
 Là, on parle de bugs & trous de sécurité dans le navigateur. Par contre, on pourrait avoir :
 
 $ gcc toto.c
 Installing backdoor in current user's account ... done
 Removing important information in users's account ... done
 Sending personnal data to my master ... done
 Thank you for compiling toto.c
 $
 
 [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par Matthieu C () le 20/10/2004 à 15:41. (lien). Évalué à 3.
 Oui alors faire ce qui etait possible de faire avec les anciennes versions de gcc : creer un pipe sur toto.s lors du processus de compil et lui faire generer un fichier objet verrolle...
 
 Apres ca peut devenir interessant si root s'en sert...
 
 [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par Alban Crequy (Jabber id, page perso, ) le 20/10/2004 à 20:27. (lien). Évalué à 1.
 Tiens, on dirait qu'on a assisté ai même cours ;)
 
 [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par Da Scritch (page perso, ) le 20/10/2004 à 19:26. (lien). Évalué à 4.
 Le souci est que la version binaire de Windows est compilée avec Visual C ! Donc le problème vient bien de la mpanière de parser du code au kilomètre. Et si MSIE laisse passer un nopmbre incroyable d'erreur de validations, c'est à son honneur.
 
 Je m'explique : au moment où MSIE est développé (jusqu'en 2000), les normes ne sont absolument pas respectées, ni même parfaitement codifiées On ne compte pas à ce moment là, le nombre de sites écrits à la va-vite, sans vérifier syntaxiquement son exactitude (mea culpa). Or, si Microsoft voulait imposer son navigateur face à c elui qui déetnait l'absolue majorité du marché de l'époque (Netscape), il doit la jouer plus rotaliste que le Roi ! Plus compatible que la réféernce Netscape. Plus facile à faire rendre une image que n'importe quel navigateur pour séduier les développeurs. Qui du coup, codent à la cochonne. Et parfois mettent du code incompatible pour se montrer "mieux que l minble sous Netscape". Vous vous souvenez quand MSIE introduisait les styles, que Netscape ne comprenait pas ?
 
 Que le projet Mozilla décide de pondre un moteur constitués de plusieurs parseurs qui respectent STRICTEMENT la norme, c'est un choix que je respecte. Mais en 1996, ils l'auraient fait, cela eusse été suicidaire. En 2004, coder un site comme un porc est inexcusable.
 
 Ceci dit, le moteur de MSIE est loin de ne pas être bouché, entre le CSS (@/*#) certaines vbasic, des fonctions mal documentées (<!--[If IE]), un dom objet sûrement mal bouché,... ça doit merder à mort. Sauf que le SP2 a été, pour une fois, compilé avec le minimum e tolérance à l'exécution... en virant sûerment quelques compatibilités propres à MS qui doivent faire chier de nombreux "webmestres" qui étaient, y'a 4 ans, spécialisés dans les sites "MSIE only".
 
 [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par pasBill pasGates () le 20/10/2004 à 20:53. (lien). Évalué à 5.
 Sauf que le SP2 a été, pour une fois, compilé avec le minimum e tolérance à l'exécution... en virant sûerment quelques compatibilités propres à MS qui doivent faire chier de nombreux "webmestres" qui étaient, y'a 4 ans, spécialisés dans les sites "MSIE only".
 
 Non, rien dans le parsing du HTML n'a change dans SP2(a part peut-etre des bug fixes, mais il parse le meme HTML qu'avant).
 
 La difference ici entre IE et les autres, c'est qu'IE ne *crashe* pas. Il va peut-etre afficher le HTML, peut-etre pas, mais dans tous les cas testes il ne crashe pas/gonfle en RAM/..., il va jetter l'eponge si le HTML est trop bordelique mais c'est tout, alors que les autres browsers ont semble-t-il des problemes a traiter du HTML invalide sans planter.
 Mozilla/Opera/... est libre de rejeter tout ce qui est non conforme w3c, mais il ne devrait pas crasher pour autant, il devrait afficher une page d'erreur/blanche/autre
 
 [+] [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par gnujsa () le 20/10/2004 à 22:51. (lien). Évalué à -5.
 Ça faisait un moment qu'on te voyait plus trop, tu as l'air de t'éclater aujourd'hui...
 
 « La difference ici entre IE et les autres, c'est qu'IE ne *crashe* pas. »
 
 Mais personne n'a dit le contraire !
 
 Tu aurai pus l'écrire comme ça:
 La difference ici entre IE et les autres, c'est qu'<blink>IE ne *crashe* pas.</blink>
 
 Attention aux racourcis:
 Il s'agit de 5 pages qui font planter 4 navigateurs. Apparement, il y a d'autre navigateur que IE qui ne plante avec ces pages (konqueror). Et IE plante avec d'autres pages (<input type crash>, etc...)
 
 P.S. désolé aux fans du xhtml/css pour mes tags « old school »
 
 [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par pasBill pasGates () le 20/10/2004 à 23:05. (lien). Évalué à 3.
 C'est amusant, toujours a mettre le focus sur la partie qui t'obsede, ou me vois tu protester que les gens pensent l'inverse ?
 
 Mon post expliquait simplement qu'un browser qui n'affiche que du code valide w3c ne doit pas pour autant crasher quand il recoit du code invalide, et qu'afficher du code invalide n'avait rien a voir avec le fait d'etre plus solide de ce cote la, c'est juste une histoire de code ecrit de maniere defensive ou pas. Maintenant pour je ne sais quelle raison tu pars dans un trip MS encore une fois.
 
 [+] [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par gnujsa () le 21/10/2004 à 09:56. (lien). Évalué à -2.
 « Mon post expliquait simplement qu'un browser qui n'affiche que du code valide w3c ne doit pas pour autant crasher »
 
 Oui, evidement. Maintenant un browser qui n'affiche que du code valide w3c, j'en connais pas (amaya peut-être ?).
 
 « c'est juste une histoire de code ecrit de maniere defensive ou pas. »
 
 Vu toutes les techniques différentes qui font planter IE avec du code valide ou invalide, ça n'est apparement pas de cette manière qu'est écrit IE.
 
 [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par pasBill pasGates () le 21/10/2004 à 10:09. (lien). Évalué à 2.
 « c'est juste une histoire de code ecrit de maniere defensive ou pas. »
 
 Vu toutes les techniques différentes qui font planter IE avec du code valide ou invalide, ça n'est apparement pas de cette manière qu'est écrit IE.
 
 Eh hop, encore un petit delire pour mettre IE et MS dedans.
 
 T'as une obsession la dessus mon pauvre, faudrait penser a aller voir un psy.
 
 [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par gnujsa () le 21/10/2004 à 11:08. (lien). Évalué à 1.
 Tu as des hallucinations, j'ai jamais parlé de MS !
 Et si je parle de IE, c'est parce que je repond a ton commentaire ou tu met en relief le fait que IE ne crashe pas.
 
 Il ne crashe pas pour ces tests mais comme il crashe pour d'autres, ça n'est pas un exemple à suivre. Ça n'enlève rien aux problèmes de gecko, links et lynx.
 
 [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par dawar (page perso, ) le 21/10/2004 à 09:15. (lien). Évalué à 3.
 Non, rien dans le parsing du HTML n'a change dans SP2
 Ben heureusement. Franchement, par son quazi monopole sur les navigateurs, MS ne peux pas se permettre de changer le parsing d'IE, imaginez la révolution, si toutes les bidouilles pour faire que ça s'affiche bien dans IE, Opera et Mozilla/netscape ne fonctionnaient plus après une mise a jour d'IE.
 
 Le pire cauchemard du developpeur : qu'IE rendent correctement les marges des boites CSS avec le SP2, obligant a encore plus de hack css ou de css multiples suivant la version d'IE...
 
 [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par Infernal Quack (Jabber id, page perso, ) le 21/10/2004 à 10:03. (lien). Évalué à 3.
 es fonctions mal documentées (<!--[If IE]),
 
 Bof. Je trouve au contraire que la documentation de Internet Explorer est beaucoup plus complète que celle de Mozilla.
 
 Pour ceux qui ne connaissent pas les "Conditionnal Comments" : http://msdn.microsoft.com/workshop/author/dhtml/overview/ccomment_o(...)
 Et au passage l'attribut CSS behavior propriétaire de Microsoft : http://msdn.microsoft.com/workshop/author/dhtml/reference/propertie(...)
 - [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par imalip (page perso, ) le 20/10/2004 à 11:27. (lien). Évalué à 8.
 modifier firefox pour ne plus planter sur ce test bidon ça veut dire le rendre capable de gober n'importe quoi, comme ie, et de se foutre du w3c
 
 Ca n'a rien a voir. Ce qui est mis en avant sur ce test, c'est la stabilite et la robustesse du navigateur, ca n'a rien a voir avec l'affichage. Sur ces pages, un navigateur devrait afficher une "page" incomprehensible, ou pas de page du tout, ou un message du genre "ce code est pourri, j'en veux pas", mais en aucun cas planter.
 
 Lorsqu'il y a une erreur, on la gere et on applique un comportement defini. On ne considere pas que "ce cas n'est pas cense arriver, donc je ne gere pas, c'est pas mon probleme si ca plante"; surtout si on a a traiter des donnees venant de sources exterieures.
 
 --
 "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
 - [^]Re: Pour IE c'est le code VALIDE qui fait planter :D
 
 Posté par walter orengo (page perso, ) le 21/10/2004 à 08:47. (lien). Évalué à 1.
 ah mais je n'ai jamais dit le contraire ! je suis tout à fait d'accord :! je ne vais pas re citer le message de Da Scritch que je trouve très bien mais il est en plein dans le mile !
 
 un navigateur ne doit pas planter, il doit afficher une page, celle qu'on visite, ou au moins prévenir si le webmaster un fait un taf de porc.
 
 mais effectivement, jadis on codait des sites entier dans notepad, aujourd'hui il y a des tonnes d'outils pour déployer un site web ... même pour les kevin 12 ans !... il y a des erreurs, des sites d'une lourdeur incommensurable, même avec un haut débit et une bonne machine certains sites sont hyper long à s'afficher ... je parle pas des sites qui sont buggés là mais des sites tout simplement mal mis en oeuvre mal codé mal fait ... c'est sur que si on visite une page qui n'est pas uen page web .... bah le navigateur est moyennement pas censé l'afficher ... maintenant ie lui permet de voir presque tout et n'importe quoi ... car il est moins regardant sur la qualité du code, moisn rigoureux, ceci dit entre ne rien afficher et planter ya un monde tout de même ... c'est dommage je n'ai plus les adresses en tête, mais j'avais des sites sur le quel mozilla fermait tout simplement ou restait bloqué comme çà ........ et de même d" autre ou c'était le cas avec ie ....
 
 le probleme numéro un c'est que même si la tendance diminue, 90% des sites sont optimisés IE car 90% des gens l'utilise, donc les webmaster utilise par exemple 'bgsound' au lieu de 'embed' ... par exemple ...
 
 après sur un site sophistiqué ya toujours des pb liés au plugins et autres... mais là on parle plus d'html ... mais un site avec du java/javascript, xml, php, perl etc tous les languages ..., video, musique, même css, et bien si l'ordinateur n'a pas ce qu'il faut , et bien tu as des pbs ... tu dois DL un truc, la page s'affiche pas - error - ton navigateur plante ! etc ... il faut bien dissocier les erreurs de html et les erreurs de la page lié à autre chose ... de toutes façon avec bientot l'impossibilité d'avoir des ouvertures automatique de liens de fenetre (cause popups, double target and co) les webmaster vont devoir revoir nombre de leurs sites ...
 
 tout va évoluer, et biensur les navigateurs aussi ... la preuve firefox montre qu'enfin on peut avoir un mozilla viable càd des pages qui mettent pas 1 heure à s'afficher ! ...
 
 ceci dit perso je trouve que iexplore plante assez souvent (je parle pas du test mais de mon expérience perso) faut dire que je vais sur des sites de ouf mais bon ... qd même ...
 
 il est dommage que l'aveuglement des geeks anti-M$ et des QUE-M$ nuise à l'avancé d'un web propre, etc .. à chaque fois on essaye de comparer ce qui n'est pas comparable de troller en parlant de la guerre imaginaire monde du libre/billgates ... guerre que sans ces mêmes protagonistes il n'y aurait pas.
 
 bref pour en revenir au sujet, que ce soit ie ou moteur gecko ou autre, tout ce qu'on demande en tant que web-surfer, bah c'est justement de se ballader peinard sur le web, quelque soit le navigateur, les néophytes et infomaticien utilise forcément pas les mêmes 'outils' que l'utilisateur lambda de base qui a 50 berges et vient d'acheter un pc à ses gosses, sans craindre virus, spyware, ou plantage de machine ou de navigateur .... mais bon le coup des spyware et virus c'est un autre débat ^^
 
 --
 HéHéHé

Très bon travail

Posté par Cedric Cellier (page perso, ) le 20/10/2004 à 06:56. (lien). Évalué à 7.

Quand j'ai vu la source de mozilla_die1.html, je n'y croyait pas.

J'ai cliqué avec mon firefox 0.9.3, et bin c'est ce qu'il y a de plus rapide pour fermer l'application :-)

[^]Re: Très bon travail

Posté par Gniarf () le 20/10/2004 à 08:03. (lien). Évalué à 4.
non, c'est mozilla_die2.html, et de loin

--
The greatest trick the Google Devil ever pulled was convincing the world he did no evil.
- [^]Re: Très bon travail
  
  Posté par totoro () le 20/10/2004 à 15:58. (lien). Évalué à 1.
  Oui mais encore faut-il que tu ais activé le javascript ....
  
  --
  dyslectics have more fnu

[^]Re: Très bon travail

Posté par Yann012 () le 20/10/2004 à 15:01. (lien). Évalué à 4.
J'ai regardé la source de mozilla_die1.html à l'éditeur hexa et il y a un octet nul entre le T de INPUT et le premier A ... En gros, On peut pas recréer cette page sur un forum avec HTML ou autre...

--
Mon JID est yannbng@jabber.fr

Cool

Posté par Aurélien Bompard (Jabber id, page perso, ) le 20/10/2004 à 07:17. (lien). Évalué à 5.

Excellent ! Un grand bravo et merci à l'auteur de ce script, ça va permettre d'améliorer grandement la stabilité et l'occupation mémoire des navigateurs libres et d'Opéra !

[+] Attention quand même

Posté par peco () le 20/10/2004 à 07:44. (lien). Évalué à -4.

Attention quand même, le gars a travaillé pour Microsoft depuis DOS 4. Je ne dis pas que le code ne fait pas planter Firefox, mais seulement que s'il ne fait pas planter IE, il y a peut-être une raison.

Je dis ça, je dis rien...

[^]Re: Attention quand même

Posté par pasBill pasGates () le 20/10/2004 à 07:48. (lien). Évalué à 4.
Le gars ne bosse pas pour MS.
- [+] [^]Re: Attention quand même
  
  Posté par peco () le 20/10/2004 à 07:57. (lien). Évalué à -2.
  Relis mon post. J'ai dis "a travaillé". Au passé.
  - [^]Re: Attention quand même
    
    Posté par pasBill pasGates () le 20/10/2004 à 07:59. (lien). Évalué à 1.
    Et d'ou sors tu cette info comme quoi ce serait un ancien employe ?
    - [^]Re: Attention quand même
      
      Posté par Gniarf () le 20/10/2004 à 08:02. (lien). Évalué à 1.
      la Kabale (qui n'existe pas) Sait Tout.
      
      --
      The greatest trick the Google Devil ever pulled was convincing the world he did no evil.
      - [^]Re: Attention quand même
        
        Posté par pasBill pasGates () le 20/10/2004 à 08:04. (lien). Évalué à 10.
        Ben il est baleze le gars, parce que : http://lcamtuf.coredump.cx/(...)
        
        Il a 23 ans, si il a commence a bosser chez MS lors de DOS 4, il avait alors moins de 10 ans quand ils l'ont engage...
        
        [^]Re: Attention quand même
        
        Posté par Larry Cow () le 20/10/2004 à 08:52. (lien). Évalué à 1.
        C'était Gilbert?
        
        (je suis déjà dehors)
        
        [^]Re: Attention quand même
        
        Posté par Aurélien Girard () le 20/10/2004 à 09:23. (lien). Évalué à 10.
        Microsoft c'est vraiment des ordures, ils font bosser des enfants !
        (je comprend mieux le look Playskool de Windows XP maintenant)
        
        [] -> je suis déjà dehors !
        
        --
        BeOS le faisait il y a 10 ans.
    - [+] [^]Re: Attention quand même
      
      Posté par peco () le 20/10/2004 à 08:04. (lien). Évalué à -2.
      Slashdot http://it.slashdot.org/article.pl?sid=04/10/19/0236213&tid=113&(...)
      + Googlecheck (tm)
      - [^]Re: Attention quand même
        
        Posté par pasBill pasGates () le 20/10/2004 à 08:06. (lien). Évalué à 8.
        Larry Osterman bosse chez MS depuis DOS 4.
        
        Larry Osterman est le gars qui a mis un lien sur l'article BugTraq dans son blog.
        
        L'auteur de l'article sur BugTraq n'est pas Larry Osterman.
      - [^]Re: Attention quand même
        
        Posté par Erwan (page perso, ) le 20/10/2004 à 08:11. (lien). Évalué à 5.
        C'est Larry Osterman qui est "Microsoftie" depuis DOS, cad qu'il bosse sur des produits MS.
      - [^]Re: Attention quand même
        
        Posté par Nelis (page perso, ) le 20/10/2004 à 08:11. (lien). Évalué à 9.
        Voici la phrase de /. :
        
        "While reading Larry Osterman'a blog (He's a long time Microsoftie, having worked on products dating back to DOS 4.0), I ran across this BugTraq entry on web browser security. Basically, the story is that Michael Zalewski started [...]"
        
        Moi je comprends qu'il parle de Larry Osterman lorsqu'il dit qu'il a travaillé chez MS, pas de Michael Zalewski. Et le fait que M.Z. ait 24 ans me conforte, comment aurait-il pu bosser sur DOS 4.0 ?
        
        De plus, ce serait même un ancien employé de MS qui aurait fait ces tests, ça ne change rien : heureusement qu'ils ont été fait, ça va permettre aux développeurs des browsers touchés de corriger des bugs.

[^]Re: Attention quand même

Posté par Yusei () le 20/10/2004 à 08:08. (lien). Évalué à 7.
Si j'ai bien compris en survolant un peu l'annonce, il s'agit de tests de force brute. L'argument selon lequel Mozilla serait plus sûr que IE se base en partie sur le fait que "avec assez d'yeux, tous les bugs sont apparents", mais les bugs mis en évidence ici ne nécessitent pas d'yeux, mais juste une batterie de tests automatisée.

Ça ne me semble pas surprenant que MS ait fait un minimum de tests de ce genre, ce qui me semble plus surprenant c'est que les développeurs de Mozilla ne l'aient pas fait. En toute logique, c'est l'étape juste avant la sortie de la v1, ça.

Mais bon, une remarque quand même, le monsieur parle de sécurité, mais il n'a trouvé que des bugs qui font planter les navigateurs, pas de vraies failles de sécurité qui ont des conséquences plus graves, comme on en voit régulièrement sur IE. La grande question est donc: les bugs qu'il a découvert peuvent-ils être utilisés "intelligemment" ?
- [^]Re: Attention quand même
 
 Posté par pasBill pasGates () le 20/10/2004 à 08:11. (lien). Évalué à 3.
 Mais bon, une remarque quand même, le monsieur parle de sécurité, mais il n'a trouvé que des bugs qui font planter les navigateurs, pas de vraies failles de sécurité qui ont des conséquences plus graves, comme on en voit régulièrement sur IE.
 
 Ca tu n'en sais rien, faut analyser ce qu'il a trouve comme faille.
 
 Perso, quand je vois que Mozilla *crashe*, ca veut dire qu'il y a probablement eu un acces memoire non autorise, bref, potentiellement un buffer overflow.
 
 C'est ca que les gens qui utilisent Mozilla regulierement ont un peu de mal a comprendre, si ils surfent sur un site et que Mozilla plante, c'est un bug oui, mais potentiellement c'est aussi une faille de securite selon le type de crash(et c'est valable pour IE aussi donc)
 - [^]Re: Attention quand même
 
 Posté par Yusei () le 20/10/2004 à 08:14. (lien). Évalué à 8.
 Je peux savoir pour quelle raison tu as coupé ta citation juste avant la phrase où je me demandais si ces failles étaient exploitables pour faire des choses méchantes ?
 
 À vouloir trop faire passer ses interlocuteurs pour des cons, on finit par se faire remarquer...
 - [^]Re: Attention quand même
 
 Posté par pasBill pasGates () le 20/10/2004 à 08:18. (lien). Évalué à 2.
 Ben quand j'ai lu pas de vraies failles de sécurité qui ont des conséquences plus graves, j'en ai conclu que La grande question est donc: les bugs qu'il a découvert peuvent-ils être utilisés "intelligemment" ne signifiait pas "buffer overflow", sinon la 1ere phrase n'aurait pas de sens vu qu'un buffer overflow a la lecture d'une page c'est une vraie faille de securite aux consequences graves. Je croyais que tu faisais reference a d'autres techniques genre cross-frame, etc...
 - [^]Re: Attention quand même
 
 Posté par Yusei () le 20/10/2004 à 08:27. (lien). Évalué à 5.
 Bon, je me reprend alors. Ce que je voulais dire c'est que souvent dans les annonces de failles on voit des gens qui ont cherché une faille exploitable, et qui sortent un exemple d'exploitation de cette faille. Lui il n'a rien cherché de particulier, il a juste obtenu des plantages sur certains types de codes, donc ses exemples tels quels ne sont pas dangereux. Bien sûr, rien ne garantit qu'il n'est pas trivial de faire une exemple dangereux à partir de ça (d'ailleurs j'avais mal lu l'annonce, il en parle lui même au sujet de mozilla_die1).
 - [^]Re: Attention quand même
 
 Posté par renoo () le 20/10/2004 à 08:23. (lien). Évalué à 6.
 Pas sur ca peut planter par ce que tu dereferences le pointeur nul 0, donc pas necessairement un buffer overflow, donc pas forcement de trous de sécurité. Il faut analyser plus finement.
 - [^]Re: Attention quand même
 
 Posté par pasBill pasGates () le 20/10/2004 à 08:24. (lien). Évalué à 2.
 D'ou l'usage du mot *potentiellement* dans ma phrase
 - [^]Re: Attention quand même
 
 Posté par Colin Leroy (page perso, ) le 20/10/2004 à 09:13. (lien). Évalué à 8.
 les pointeurs nuls ne causent pas de trous de sécurité en général. Un pointeur nul, c'est propre. ça segfaulte, et pouf. Libérer un pointeur null est ok avec la plupart des libcs, ça fait juste un no-op.
 Les problèmes plus graves, sont par exemple les buffer overflows, où l'on va écrire trop long dans la mémoire (ie, 100 caractères dans un buffer fixe de 50) et donc écraser d'autres trucs. ça mène à un exploit si on peut écraser l'adresse de retour de la stack, en général. Les double-free() peuvent être assez méchants car eux aussi écrasent de la mémoire. Par exemple, on libère un pointeur vers une structure de 64 octets... On fait d'autres trucs, dont des allocations, qui pourront réutiliser ce bloc libéré... On se trompe et on re-libère le pointeur -> les nouveaux trucs alloués sont détruits.
 C'est pourquoi
 a) on initialise toujours ses pointeurs à NULL comme ça on plante proprement
 b) on n'utilise pas de buffers statiques, où alors on vérifie toutes les longueurs sur les copies et écritures dedans. Mieux vaut utiliser des buffers dynamiques (et les allouer à la bonne taille, bien sûr)
 c) quand on libère un pointeur, on le nullise après pour être sûr de pas pouvoir le réutiliser: free(stuff); stuff = NULL;
 
 --
 Claws Mail - it bites!
 - [+] [^]Re: Attention quand même
 
 Posté par thecat () le 20/10/2004 à 10:04. (lien). Évalué à -4.
 Vous savez j'ai entendu une voix qui m'a dit qu'un gars hyper balaise (je crois que sont pseudo c'est "garbage_collector") faisait tout cela et même en mieux! Peut-etres qu'ont devrait lui proposer de travailler dans les logiciel libres non?
 
 ps: Une autre voix m'a dit aussi que C++ c'etait le Cobol des années 90 (et mantenant 2000). Mais bon la c'est sûr, c'etait un troll ...
 - [^]Re: Attention quand même
 
 Posté par gc (page perso, ) le 20/10/2004 à 10:46. (lien). Évalué à 4.
 Sais-tu comment écrire une fonction qui fait (c) ? Je me suis cassé une fois les dents dessus. Si j'écris :
 
 void free_(void ** ptr)
 {
 free(*ptr);
 *ptr = NULL;
 }
 
 alors tout va bien pour libérer un void * mais si c'est un char * j'obtiens warning: passing arg 1 of `free_' from incompatible pointer type. Il semble que seul le cast vers void * soit correct pout tout pointeur, alors que le cast vers void ** n'est permis que pour un pointeur de pointeur sur void.
 
 [^]Re: Attention quand même
 
 Posté par Guillaume Knispel () le 20/10/2004 à 11:30. (lien). Évalué à 3.
 faire un define :
 
 #define FREE0(x) do { free(x); x = NULL; } while(0)
 
 Pas très dangeureux car on n'utilise pas (ou de toute manière on devrait pas) utiliser d'effet de bord dans un free :p
 Et très pratique...
 
 [^]Re: Attention quand même
 
 Posté par -=[ Benoit Plessis ]=- (page perso, ) le 20/10/2004 à 12:48. (lien). Évalué à 3.
 Un simple
 #define FREE0(x) {free(x); x = NULL; }
 
 suffit.
 
 --
 Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libr
 
 [^]Re: Attention quand même
 
 Posté par hex () le 20/10/2004 à 14:50. (lien). Évalué à 2.
 Le while c'est une astuce pour pouvoir écrire :
 
 FREE0(p);
 
 Note le point virgule.
 
 Avec le while, la macro devient :
 do { free(x); x = NULL; } while(0);
 ce qui est syntaxiquement correct.
 
 Sans le while :
 { free(x); x = NULL; };
 ce qui est syntaxiquement incorrect : on ne peut pas avoir de point virgule après une fermeture d'accollade. Donc ca compilera pas.
 
 Tout bon kernel hacker sait cà voyons ;-)
 
 [^]Re: Attention quand même
 
 Posté par Ramso (page perso, ) le 20/10/2004 à 15:55. (lien). Évalué à 2.
 Mais pourquoi pas tout simplement
 
 #define FREE0(x) free(x); x = NULL
 
 Sans ces accolades dont l'apport m'échappe et sans le point-virgule final. Et pourquoi vouloir absolument mettre un point-virgule derrière une macro ? L'écriture en capitales me paraît assez explicite pour savoir que c'est une macro.
 
 --
 Groar !
 
 [^]Re: Attention quand même
 
 Posté par imalip (page perso, ) le 20/10/2004 à 16:12. (lien). Évalué à 4.
 parce que si a un moment tu as dans ton code :
 
 if (erreur)
 FREE0(x);
 
 tu as une belle fuite memoire...
 
 --
 "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
 
 [^]Re: Attention quand même
 
 Posté par Matthieu Moy (page perso, ) le 20/10/2004 à 17:06. (lien). Évalué à 2.
 > Et pourquoi vouloir absolument mettre un point-virgule derrière une macro ?
 
 Pour ne pas casser l'indentation automatique (emacs, indent, etc ...) par exemple.
 
 [^]Re: Attention quand même
 
 Posté par Philippe Fremy (page perso, ) le 21/10/2004 à 10:18. (lien). Évalué à 2.
 <<
 { free(x); x = NULL; };
 ce qui est syntaxiquement incorrect : on ne peut pas avoir de point virgule après une fermeture d'accollade. Donc ca compilera pas.
 >>
 
 Tu pourrais me citer tes sources ? Ca compile sous gcc meme en etant strict:
 
 #include <stdlib.h>
 
 int main()
 {
 int a;
 int *x;
 
 { a=1; };
 a=2;;
 
 { free(x); x = NULL; };
 return 0;
 }
 
 philippe@werewindle ~/c/tests $ gcc -Wall -ansi -pedantic bracket_colon.c
 philippe@werewindle ~/c/tests $ gcc --version
 gcc (GCC) 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice)
 Copyright (C) 2002 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions. There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
 D'apres mes souvenirs, un ';' est une instruction parfaitement valide. En revanche, il y aurait certains compilateurs sur lesquels ca poserait probleme.
 
 --
 phil.freehackers.org
 
 [^]Re: Attention quand même
 
 Posté par pasBill pasGates () le 21/10/2004 à 10:24. (lien). Évalué à 2.
 Un ; n'est rien d'autre qu'un separateur en C, on peut en mettre 20'000 a la suite si on veut et a peu pres partout aussi.
 
 {...};;
 
 C'est equivalent a
 
 {...}
 <instruction vide>
 ;
 <instruction vide>
 ;
 
 Bref, du C parfaitement valide.
 
 [^]Re: Attention quand même
 
 Posté par gc (page perso, ) le 21/10/2004 à 10:52. (lien). Évalué à 2.
 Un ; n'est rien d'autre qu'un separateur en C
 
 Non c'est un terminateur. C'est en Pascal que c'est un séparateur.
 
 En C tu dois mettre un point-virgule après la dernière instruction d'un bloc.
 
 [^]Re: Attention quand même
 
 Posté par chl (page perso, ) le 21/10/2004 à 13:37. (lien). Évalué à 2.
 Non c'est un terminateur. C'est en Pascal que c'est un séparateur.
 
 C'est a dire ? Je ne vois pas la difference entre un terminateur d'instruction C, et un separateur entre 2 instructions C. Pour moi ca revient au meme, mais si tu consideres que c'est pas pareil, j'aimerai bien en savoir plus.
 
 En C tu dois mettre un point-virgule après la dernière instruction d'un bloc.
 
 Comme ca ? :
 
 { // debut de bloc
 int i,j
 i++
 j++
 printf("%d\n",i); // ici c'est la derniere instruction d'un bloc alors il doit y avoir un point-virugle.
 } // fin du bloc
 
 Je sais pas pourquoi mais je pense pas que gcc aprecie beaucoup ce genre de bloc :)
 
 PS: // est valide pour un commentaire d'apres C99.
 
 [^]Re: Attention quand même
 
 Posté par gc (page perso, ) le 21/10/2004 à 15:47. (lien). Évalué à 3.
 C'est a dire ? Je ne vois pas la difference entre un terminateur d'instruction C, et un separateur entre 2 instructions C. Pour moi ca revient au meme, mais si tu consideres que c'est pas pareil, j'aimerai bien en savoir plus.
 
 C'est juste deux notions différentes, et pour la grammaire du langage ça fait une différence, par exemple. Ça a à peu près le même look, surtout que les langages où point-virgule est un séparateur (Pascal, Perl) permettent les instructions vides donc il n'est pas rare de voir la dernière instruction d'un bloc "terminée" par un point-virgule.
 
 Comme ca ? :
 
 Oui ton exemple illustre bien le concept, en tous cas pour ce que je voulais dire, c'est à dire ce qu'on trouve avant l'accolade fermante. En Pascal ou en Perl le point-virgule avant l'accolade fermante serait inutile.
 
 Bien sûr le code est invalide car tu as omis les point-virgules pour les trois premières "instructions". Je le mets entre guillemets car je ne sais pas si c'est le terme correct. Il me semble qu'en anglais le terme correct est "statement" mais je ne sais pas pas le traduire en français.
 
 En tous cas, en C le point-virgule est un terminateur de "statement". "Instruction" si c'est bien la bonne traduction, ce qui n'est pas gagné.
 
 [^]Re: Attention quand même
 
 Posté par Fabien F. () le 23/10/2004 à 23:12. (lien). Évalué à 1.
 
 a peu pres partout
 
 *A peu pres* partout, peut-etre, mais pas partout. Exemple:
 
 #define A { printf("a"); printf("b"); }
 main() { if(0) A; else printf("c"); }
 
 alors que:
 
 #define A do { printf("a"); printf("b"); } while(0)
 main() { if(0) A; else printf("c"); }
 
 marche...
 
 [^]Re: Attention quand même
 
 Posté par gros_rouge () le 22/10/2004 à 08:27. (lien). Évalué à 3.
 http://clips.imag.fr/commun/bernard.cassagne/Introduction_ANSI_C/no(...)
 
 Fab.
 
 [^]Re: Attention quand même
 
 Posté par Matthieu Moy (page perso, ) le 22/10/2004 à 17:18. (lien). Évalué à 2.
 Ca n'explique toujours pas l'intérêt du do {...} while à la place d'une simple paire d'accolades.
 
 [^]Re: Attention quand même
 
 Posté par gros_rouge () le 22/10/2004 à 18:07. (lien). Évalué à 1.
 « Ca n'explique toujours pas l'intérêt du do {...} while à la place d'une simple paire d'accolades. »
 
 C'est ce qui est expliqué au bas de la page pointée par mon lien (recommandation).
 
 Fab.
 
 [^]Re: Attention quand même
 
 Posté par Matthieu Moy (page perso, ) le 23/10/2004 à 17:57. (lien). Évalué à 2.
 J'ai bien lu, effectivement,
 
 #define F(x) if (!f(x)) { printf("erreur\n"); exit(1); }
 
 est dangereux, mais je ne vois pas le problème avec
 
 #define F(x) {if (!f(x)) { printf("erreur\n"); exit(1); }}
 
 L'argument donné plus haut était que le `;' n'était pas autorisé après les accolades, mais c'est totalement faux.
 
 [^]Re: Attention quand même
 
 Posté par gros_rouge () le 23/10/2004 à 22:32. (lien). Évalué à 1.
 Je viens (enfin) de réaliser pourquoi nous n'étions pas d'accord. Désolé, c'est de ma faute, j'ai répondu au mauvais commentaire.
 Mon commentaire s'adressait à Hervé Cauwelier [1] et j'ai répondu à Benoit Plessis [2]. Le temps de fouiller dans mes bookmarks et je n'étais déjà plus dans la course...
 
 Toutes mes excuses Matthieu.
 
 Fab.
 
 [1] : https://linuxfr.org/comments/487223,1.html(...)
 [2] : https://linuxfr.org/comments/487101,1.html(...)
 - [^]Re: Attention quand même
 
 Posté par Olivier MARTIN () le 20/10/2004 à 13:28. (lien). Évalué à 4.
 les pointeurs nuls ne causent pas de trous de sécurité en général. Un pointeur nul, c'est propre. ça segfaulte, et pouf. Libérer un pointeur null est ok avec la plupart des libcs, ça fait juste un no-op.
 Les problèmes plus graves, sont par exemple les buffer overflows, où l'on va écrire trop long dans la mémoire (ie, 100 caractères dans un buffer fixe de 50) et donc écraser d'autres trucs. ça mène à un exploit si on peut écraser l'adresse de retour de la stack, en général. Les double-free() peuvent être assez méchants car eux aussi écrasent de la mémoire. Par exemple, on libère un pointeur vers une structure de 64 octets... On fait d'autres trucs, dont des allocations, qui pourront réutiliser ce bloc libéré...
 Et après on ose cracher sur Java et sa gestion dynamique de la mémoire?
 
 [^]Re: Attention quand même
 
 Posté par Colin Leroy (page perso, ) le 21/10/2004 à 06:45. (lien). Évalué à 3.
 Où ça?
 
 --
 Claws Mail - it bites!

fermeture rapide!

Posté par nico1980 () le 20/10/2004 à 08:05. (lien). Évalué à 1.

Le code de mozilla_die1.html est stupéfiant !

Dommage...

Posté par David Sporn (page perso, ) le 20/10/2004 à 08:41. (lien). Évalué à 0.

...Je n'ai pas les capacités d'écrire un patch...

Ça picote...

Posté par arnaudus () le 20/10/2004 à 08:47. (lien). Évalué à 7.

Bien sûr, on savait tous que nos logiciels préférés recelaient certains bugs. Maintenant, ce genre de test sonne d'une manière particulièrement cruelle, surtout que IE s'en sort indemne (manipulation? mauvaise foi? réalité?).

L'autopersuasion fonctionne pas mal dans le monde des logiciels libres, et finalement, ce genre de données concrètes force un certain retour sur Terre. Si seulement Microsoft pouvait employer de tels arguments! Ça aiderait certainement de nombreux logiciels à progresser, et surtout, ça serait tellement moins discutable que leurs FUDs et leurs sous-entendus... Je trouve incroyable qu'ils ne soient pas fichus de sortir des arguments concrets alors qu'ils existent, la preuve...

[^]Re: Ça picote...

Posté par Ant () le 20/10/2004 à 09:00. (lien). Évalué à 2.
Effectivement, qu'il y ait des bugs dans mozilla qui le fassent planter, ce n'est pas vraiment un scoop, je connais une tripotée de sites qui le font planter.

C'est malheureusement un peu représentatif de beaucoup de logiciels libres et c'est ce qui les différencie du logiciel propriétaire : on donne la priorité aux fonctionnalités, alors quelques bugs qui font planter, ce n'est pas *mal*, ce qui est mal, ce sont les corruptions de données ou les failles de sécurité.
Pour le propriétaire, les apparences comptent beaucoup plus, donc les plantages "accidentels" sont beaucoup mieux contrôlés.
Voilà, c'est l'explication que je me donne au fait que IE semble se sortir beaucoup mieux du test que nos chers LL.
- [^]Re: Ça picote...
 
 Posté par pasBill pasGates () le 20/10/2004 à 09:06. (lien). Évalué à 2.
 Et qu'est ce qui te dit qu'un plantage n'est pas du a une faille de securite ?
 
 Le premier symptome d'un buffer overflow ou stack overflow, c'est le plantage du soft. Ensuite, tu tires avantage de l'overflow pour qu'au lieu de planter, le soft fasse ce que tu veux.
 
 Faut arreter de croire qu'une faille de securite c'est autre chose qu'un plantage, dans bcp de cas un plantage _est le signe_ d'une faille de securite.
 - [^]Re: Ça picote...
 
 Posté par arnaudus () le 20/10/2004 à 09:34. (lien). Évalué à 1.
 Faut arreter de croire qu'une faille de securite c'est autre chose qu'un plantage, dans bcp de cas un plantage _est le signe_ d'une faille de securite.
 
 Quoi qu'il en soit, c'est signe d'un manque de robustesse. Sans vouloir lancer un troll, c'est peut-être directement lié au mode de développement des logiciels libres : si quelqu'un propose un patch, il va essayer de produire le minimum de code pour une fonctionnalité, parce que d'une part il n'a pas forcément le temps de coder 10000 lignes de gestion des erreurs, et d'autre part si son patch est refusé, bah c'est du boulot pour rien.
 
 Maintenant, Mozilla est codé en C++, et le C++ intègre tout de même un certain nombre de fonctionnalités qui permettent de réduire ce type d'erreurs à l'exécution (exceptions, gestion automatique de la mémoire pour les chaînes de caractère et les tableaux...). Je ne me considère pas comme un spécialiste, mais il me semble qu'il est tout de même plus difficile de faire un buffer overflow dans un prog C++ que dans une application C, à condition de programmer de manière "moderne". Le corrolaire à ça, c'est que les problèmes sont certainement plus facilement modifiables dans Mozilla que dans les applis qui utilisent strcpy, memcpy etc. en routine.
 - [^]Re: Ça picote...
 
 Posté par Aurélien Girard () le 20/10/2004 à 09:51. (lien). Évalué à 2.
 C'est bien fait pour eux. Ils n'avaient qu'à lire GLHMF et sa série fleuve d'articles sur le thème "eviter dès le début les failles de sécurité dans ses applications".
 
 --
 BeOS le faisait il y a 10 ans.
 - [+] [^]Dès le début ?
 
 Posté par nodens (page perso, ) le 20/10/2004 à 11:18. (lien). Évalué à -1.
 En même temps, avec le code de Netscape 4.x comme base c'est difficile de tout refaire propre :)
 
 --
 Clément Hermann (nodens)
 - "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?"
 Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/
 GPG : pgp.mit.edu - 0xEBD1399D
 - [^]Re: Ça picote...
 
 Posté par Yusei () le 20/10/2004 à 09:57. (lien). Évalué à 4.
 «il me semble qu'il est tout de même plus difficile de faire un buffer overflow dans un prog C++ que dans une application C, à condition de programmer de manière "moderne".»
 
 Si on programme "de manière moderne" en C, on utilise une bibliothèque qui permet d'éviter les buffer overflow, de même que dans les autres langages. Par exemple la glib fournit tout ce qu'il faut pour manipuler des chaînes de manière souple et plus sûre, via ses GStrings.
 - [^]Re: Ça picote...
 
 Posté par Jean Canazzi () le 22/10/2004 à 17:56. (lien). Évalué à 2.
 Je ne suis vraiment pas certain que le C++ limite les erreurs de pointeurs. On peut faire des erreurs vraiment vicieuses avec l'héritage multiple. Un petit exemple : supposons qu'on ait une classe AB qui dérive d'une classe A et d'une classe B. Soit le code suivant :
 
 AB* p_ab = NULL;
 AB& ab = *p_ab;
 B& b = static_cast<B&>(ab);
 if (&b != NULL)
 {
 // LE TEST RETOURNE VRAI !
 }
 
 Eh bien oui dans l'exemple ci-dessus le test "if (&b != NULL)" est vrai. Pourtant, on pense avoir une référence sur un pointeur null, non ? Ce à quoi on ne pense pas, c'est que le static_cast a augmenté l'adresse de la référence de sizeof(A) octets. Par conséquent si "p_ab" était bien null, "&b" ne l'est plus. C'est pas vicieux ça ?
 - [^]Re: Ça picote...
 
 Posté par Cali_Mero () le 20/10/2004 à 10:33. (lien). Évalué à 2.
 Pas d'accord : http://linuxfr.org/comments/481812.html#481812(...)
 
 --
 #define MAGIC 0xdefaced /* I should've patented this number -cliph */
 - [^]Re: Ça picote...
 
 Posté par Toufou (page perso, ) le 20/10/2004 à 12:24. (lien). Évalué à 5.
 Mouais je trouve ces définitions plutot discutables et l'argumentation particulierement mal vue.
 
 Pour ma part, je dirais que :
 - un bug c'est une erreur de programmation (parfois de paramétrage) qui amène un comportement non prévu par les concepteurs du logiciel (pas obligatoirement un plantage brutal, c'est souvent moins flagrant).
 - et une faille de sécurité, c'est la possibilité d'exploiter une particularité d'un dispositif informatique (dont les bugs) a des fins malhonnètes : les coordonnées perso ou la copie de la RAM dans un .doc, l'exécution systématique d'un .vbs dans un mail ne sont pas des bugs (puisque c'est fait exprès) pourtant, ce sont des failles de sécurité (et encore, ça dépend du contexte).
 
 Et puis, le plantage brutal d'une application est suffisement rentré dans les moeurs de l'utilisateur moyen pour ne plus être considéré comme un comportement anormal mais seulement gènant : "zut, mon XXXXX a encore planté, il va falloir que je recommence".
- [^]Re: Ça picote...
 
 Posté par scylla (page perso, ) le 20/10/2004 à 10:30. (lien). Évalué à 1.
 Pour le propriétaire, les apparences comptent beaucoup plus, donc les plantages "accidentels" sont beaucoup mieux contrôlés.
 
 Opera n'est pas libre, et il est sujet à ce type de plantages aussi. De plus, rien ne dit que ce script ne permettra pas de révéler un problème dans IE aussi ; on sait uniquement qu'il est moins sensible. Ça laisse néanmoins supposer que le parser utilisé dans IE est écrit assez proprement, contrairement à ses concurrents. Les exemples fournis sont assez édifiants sur ce point.
 
 Ce script est globalement révélateur des problèmes qui surviennent quand on veut accepter des entrées non valides, ce qui est généralement difficile (et non souhaitable, mais allez savoir pourquoi au début des navigateurs web on a laissé passer tout et n'importe quoi, ça a crée de mauvaises habitudes).
 
 Moralité, faites du XHTML lu en mode strict, le navigateur vous jette quand il y a un problème.
 - [^]Re: Ça picote...
 
 Posté par Aurélien Le Provost - Ribaltch (page perso, ) le 21/10/2004 à 15:23. (lien). Évalué à 0.
 > Pour le propriétaire, les apparences comptent beaucoup plus, donc les
 > plantages "accidentels" sont beaucoup mieux contrôlés.
 
 Il y a u problème avec ton raisonnement : ça colle pas avec Windows, par exemple.
 
 --
 Encryption is not magic pixie dust to sprinkle on things to make them more secure.

resultat

Posté par tfeserver tfe (page perso, ) le 20/10/2004 à 09:36. (lien). Évalué à 0.

IE c'est plein de failles
Mozilla bug partout
Opera de même
Lynx plante aussi
Links de meme

Il nous reste que telnet, ca veut dire ça ?

[^]Re: resultat

Posté par Benoît Sibaud (Jabber id, page perso, ) le 20/10/2004 à 09:49. (lien). Évalué à 3.
> Il nous reste que telnet, ca veut dire ça ?

DSA-569-1 netkit-telnet-ssl -- invalid free(3)
http://www.debian.org/security/2004/dsa-569(...)

DSA-556-2 netkit-telnet -- invalid free(3)
http://www.debian.org/security/2004/dsa-556(...)

DSA-529-1 netkit-telnet-ssl -- Format de chaîne de caractères
http://www.debian.org/security/2004/dsa-529(...)

[+] [^]Re: resultat

Posté par oliv () le 20/10/2004 à 09:51. (lien). Évalué à -3.
Euh, telnet c'est pas sécurisé. Il me semble que ssh l'a remplacé depuis belle lurette dans toutes nos distributions préférées.
- [^]Re: resultat
  
  Posté par Panda Voyageur (page perso, ) le 20/10/2004 à 09:55. (lien). Évalué à 3.
  Euh, du ssh pour lire une page web je suis pas sûr que ça donne grand chose! Alors qu'un telnet linuxfr.org 80... ;)
  - [+] [^]Re: resultat
    
    Posté par Bruno Muller (Jabber id, page perso, ) le 20/10/2004 à 10:06. (lien). Évalué à -1.
    - telnet c'est fait pour faire du telnet et c'est pas secure !
    - Si tu veux causer avec un serveur (web comme dans ton exemple), c'est netcat qu'il te faut.
    - [^]Re: resultat
      
      Posté par gc (page perso, ) le 20/10/2004 à 10:53. (lien). Évalué à 4.
      telnet c'est très répandu et c'est dans 95% des cas suffisant par rapport à nc pour établir une connexion cliente TCP/IP, envoyer et recevoir des données.
    - [^]Re: resultat
      
      Posté par LupusMic (page perso, ) le 20/10/2004 à 13:41. (lien). Évalué à 4.
      Il faudrait arrêter de confondre le protocole telnet, et le programme telnet.
      
      Ici, on parle du programme telnet pour ouvrir une chaussette sur un port 80 distant. Conceptuellement, il n'y a aucune différence avec la connection d'un navigateur web.
      
      Alors arrêté de dire n'importe quoi ! Et allez lire les RFC, et découvrez le modèle OSI.
      - [+] [^]Re: resultat
        
        Posté par Bruno Muller (Jabber id, page perso, ) le 20/10/2004 à 14:15. (lien). Évalué à -3.
        mdr...
        
        Je pense que n'as pas répondu au bon commentaire...
        
        Pour preciser ma pensée : il faut utiliser le bon outil. Pour ouvrir une chausette, c'est netcat, pas telnet.
      - [^]Re: resultat
        
        Posté par chl (page perso, ) le 20/10/2004 à 16:52. (lien). Évalué à 4.
        Il faudrait arrêter de confondre une chaussette (sock) et une douille (socket). [1]
        
        Ici, on parle du programme telnet pour ouvrir une douille sur un port 80 distant.
        
        Alors arrêtez de dire n'importe quoi ! Et allez lire de l'anglais, par exemple les RFC ou le modèle OSI.
        
        [1] http://www.google.com/language_tools?hl=fr(...)
    - [^]Re: resultat
      
      Posté par Éric (Jabber id, page perso, ) le 20/10/2004 à 14:05. (lien). Évalué à 4.
      Tu viens m'expliquer en quoi faire un "telnet linuxfr.org 80" est moins "secure"(*) qu'un netcat ?
      Tu confond l'ouverture d'un shell disant via telnet (qui effectivement n'est pas sûre vu que le mot de passe est en clair) et l'utilisation de telnet de manière générique sur un socket (qui passe autant en clair avec mon outil que le tien).
      
      (* c'est quoi ce mot ? "sûr" me parait bien plus adapté, pourtant je n'ai habituellement vraiment rien contre les mots anglais dans l'informatique)
      - [+] [^]Re: resultat
        
        Posté par Bruno Muller (Jabber id, page perso, ) le 20/10/2004 à 14:20. (lien). Évalué à -1.
        http://packages.debian.org/unstable/admin/harden-clients(...) te suffit ou tu veux plus de détails ?
        
        [+] [^]Re: resultat
        
        Posté par Bruno Muller (Jabber id, page perso, ) le 20/10/2004 à 14:24. (lien). Évalué à -2.
        bon, ca n'apparait pas dans le lien que je viens de mettre, mais harden-clients "conflicte" avec x2vnc, svncviewer, telnet et ftp-upload.
        
        [^]telnet & netcat
        
        Posté par _alex () le 20/10/2004 à 14:43. (lien). Évalué à 4.
        Crénon de saperlipopette : protocole différent de programme.
        
        http://www.onlamp.com/pub/a/onlamp/2003/05/29/netcat.html(...)
        As a basic point of view, Netcat is a telnet program.
        
        et harden vire telnet, ce qui est en cause c'est l'utilisation du protocole et non pas l'utilisation du programme.
        
        [^]Re: resultat
        
        Posté par Éric (Jabber id, page perso, ) le 20/10/2004 à 21:22. (lien). Évalué à 5.
        C'est un choix de ta distrib pour éviter qu'un admin du dimanche utilise un shell par telnet sans en connaitre les implications. Ils virent le binaire telnet pas parce que c'est un protocole idiot, mais parce qu'il sert le plus souvent à se connecter à un shell distant en clair (et *ça* c'est mal, parce que le mot de passe est en clair).
        Que tu veuilles ouvrir une connexion HTTP, SMTP ou autres à la main via le binaire telnet n'est absolument pas en cause et n'a rien à voir avec la phrase souvent répétée du "telnet c'est mal".
        Que tu utilises un beau programme du nom "telnet" ou un "netcat", c'est *exactement* la même chose qui passe sur le réseau, *exactement* la même sécurité, que ce soit d'un point de vue extérieur/réseau ou d'un point de vue intérieur/système.. L'un n'est pas plus sûr que l'autre. Si tu veux m'annoncer que c'est moins bien je t'attend de pied ferme toi et ton argumentation.
- [^]Re: resultat
  
  Posté par gc (page perso, ) le 20/10/2004 à 10:52. (lien). Évalué à 2.
  Dis-moi, #56, tu dis ça au second degré hein ?
  - [^]Re: resultat
    
    Posté par oliv () le 20/10/2004 à 12:09. (lien). Évalué à 1.
    Absolument pas, je suis sérieux. Je suis administrateur système d'un parc de 42 machines sous Suse, et pour des raisons de sécurité, les utilisateurs doivent naviguer sur le web via ssh. Les power-users et les managers ont droit à une dérogation et peuvent utiliser wmcoincoin pour ne pas nuire à leur productivité.
    
    Et vive l'UDC!

[+] [^]Re: resultat

Posté par Ackira () le 20/10/2004 à 16:31. (lien). Évalué à -1.
Netcat!

[+] C'est vraiment serieux moz ?

Posté par Guillaume Knispel () le 20/10/2004 à 10:31. (lien). Évalué à -2.

Ils attendent que les autres developpent des batteries de tests à leur place les devel de moz ou quoi ? ;)

Cela dit je les pardonne, c'est CHIANT de coder des tests :p

hmm

Posté par Francois Revol (page perso, ) le 20/10/2004 à 10:40. (lien). Évalué à 3.

bizarre, aucun des tests me fait planter opera, mm pas opera_die, par contre la page de cette news me l'a fait planté 3 fois de suite :)))

Pfff on est vraiment nul

Posté par imr () le 20/10/2004 à 10:58. (lien). Évalué à 9.

Nous les utilisateurs de konqueror.
Pas une seul de ces pages qui le fait planter.
Personne n'essaie jamais de trouver des failles pour notre navigateur, jamais, personne.

[^]Re: Pfff on est vraiment nul

Posté par imr () le 20/10/2004 à 11:02. (lien). Évalué à 2.
ah si, sur le cgi une des pages l'a planté.
- [^]Re: Pfff on est vraiment nul
  
  Posté par zgnouf () le 20/10/2004 à 11:21. (lien). Évalué à 3.
  Laquelle, ici aucun plantage...
  - [^]Re: Pfff on est vraiment nul
    
    Posté par GhZaaark3 () le 20/10/2004 à 13:45. (lien). Évalué à 1.
    Zut ce teste a prouvé la robustesse de Konqueror mais on n'en parle pas! :)
    
    Nada, pas Z'un plantage.
    
    +
    
    ps: ça donne quoi avec nautilus et ghtml?
    
    --
    moué...
- [^]Re: Pfff on est vraiment nul
  
  Posté par gnumdk (page perso, ) le 20/10/2004 à 14:52. (lien). Évalué à 3.
  Wai, je confirme, un plantage avec le cgi au bout de 5 onglets.
  
  Bon, en meme temps, l'a j'ai 40 onglets d'ouvert et aucun plantage donc j'en déduis que khtml roxor :)
  - [^]Re: Pfff on est vraiment nul
    
    Posté par Ramso (page perso, ) le 20/10/2004 à 15:57. (lien). Évalué à 2.
    Par contre maintenant, pour afficher un vrai site correctement...
    
    --
    Groar !

[^]Re: Pfff on est vraiment nul

Posté par Mathieu Pillard (page perso, ) le 20/10/2004 à 20:06. (lien). Évalué à 3.
Bah, konqueror on les trouve sans meme chercher:
https://linuxfr.org/~remat/14257.html(...)
- [^]Re: Pfff on est vraiment nul
  
  Posté par Gérald Toussaint () le 21/10/2004 à 08:24. (lien). Évalué à 1.
  Konqueror 3.3.1 ne Crash pas sur cette page, il y as donc eu correction !
  - [^]Re: Pfff on est vraiment nul
    
    Posté par Mathieu Pillard (page perso, ) le 22/10/2004 à 03:03. (lien). Évalué à 3.
    C'est ce qui apparait dans le rapport de bug, oui. Ce qui est marrant c'est que on ne sait ni d'ou venait le bug, ni d'ou est venue la correction. Enfin, tant qu'il revient pas et que tout le monde met a jour...

Le bug

Posté par Nicolas Peninguy (page perso, ) le 20/10/2004 à 11:08. (lien). Évalué à 7.

https://bugzilla.mozilla.org/show_bug.cgi?id=264944(...)

Voir la liste des dépendances. Sur les 5 bugs, 2 sont sans doute des problèmes de sécurité...

Sécurité?

Posté par tene (page perso, ) le 20/10/2004 à 15:17. (lien). Évalué à 2.

3 chtits remarques en passant:

1. cool c'est du concret, et "facile" à tester... on peut espérer améliorer ça...
2. bcp de gens parlent de sécurité: je trouve ça un chtit peu rapide comme vision, perso la sécurité je m'en fous!! si si je vous jure ;) Sérieux, le problème de sécurité est ce qu'on arrive à exploiter, les données qu'on va me "voler", le temps qu'on va me faire perdre, etc... bref: le problème n'est pas la sécurité dans l'absolu, mais les problèmes engendrés par les trous de sécurité... Il est je trouve alors intéressant de réaliser qu'un browser qui plante peut me faire perdre du temps... tout comme une attaque de type DOS...
3. Patch? vous avez dit patch? Un truc m'inquiète un peu, dans les articles anglais, on parle de QA... on est en où dans la QA des browsers libres? quels sont les procédure mise en place? Par exemple, mozilla est bcp plus gourmand en mémoire qu'IE (chargez des pages avec plein d'image, ça bouffe un chtit peu plus qu'IE, surtout ça rame bcp bcp plus vite), faut croire que ça n'a pas fait partie des scénarios de test de mozilla... (ça ne le rend pas mauvais pour autant, c'est juste dommage). Petit problème avec IE cependant: on a aucune idée si ça fait partie de leur test de qualité... mais le résultat est là, coup de bol ou volonté, ça se passe mieux...

Bref, si qq a des infos sur les procédures de test en place pour mozilla (et les autres, même IE ça doit être intéressant), je suis demandeur. J'espère que ces "plantages" seront corrigés, quitte à refaire une partie du design de gecko (et des autres)... et pas violemment patchés à la "si html=truc_qui_fait_planter alors plante_pas". J'ai un peu peur j'avoue quand je vois la nature de certains patch...

Sur ce ... je vais m'occuper de la QA de mon app :p

[^]Re: Sécurité?

Posté par Gniarf () le 20/10/2004 à 17:07. (lien). Évalué à 2.
pour le 2 : un plantage, ce n'est rien à coté d'une page qui ferait au final éxecuter du code en local : ce dernier pourrait être un rm -rf ~ ou un exploit quelconque.

sinon, la technique du "shit in, shit out" est connue depuis longtemps, très longtemps. la relative difficulté est de trouver un générateur un peu plus intelligent qu'un simple /dev/random qui fera statiquement beaucoup moins planter le programme. là, c'est le cas.

au passage, de nombreux autres projets ou librairies similaires méritent ce genre d'inspection, comme libxml ou OpenOffice. tout ce qui contient un parser, en fait.

--
The greatest trick the Google Devil ever pulled was convincing the world he did no evil.
- [^]Re: Sécurité?
  
  Posté par tene (page perso, ) le 20/10/2004 à 18:08. (lien). Évalué à 2.
  "un plantage, ce n'est rien à coté d'une page qui ferait au final éxecuter du code en local : ce dernier pourrait être un rm -rf ~ ou un exploit quelconque."
  
  Oui et non, généralement je suis d'accord avec toi évidemment, entre un truc qui plante et un gros virus tout pourri, je préfère le truc qui plante...
  
  Cependant, le problème reste: il faut s'intéresser à l'effet du trou, pas au trou dans l'absolu, à lire certains passages, on se dit presque que peu importe le code, les fonctionnalités du produit, etc... faut que ce soit secure avant tout. Je ne suis pas d'accord. Et c'est d'ailleurs cet aspect "non-feature" de la sécurité qui rend une politque sécuritaire foireuse...
  - [^]Re: Sécurité?
    
    Posté par Gniarf () le 20/10/2004 à 18:36. (lien). Évalué à 3.
    à lire certains passages, on se dit presque que peu importe le code, les fonctionnalités du produit, etc... faut que ce soit secure avant tout.
    
    c'est bien, c'est que le message est presque passé.
    
    ouh-ouh ? on parle de code arbitraire executé sur ta machine, là. (pas tout de suite, mais pour bientot).
    
    --
    The greatest trick the Google Devil ever pulled was convincing the world he did no evil.
    - [^]Re: Sécurité?
      
      Posté par tene (page perso, ) le 21/10/2004 à 10:13. (lien). Évalué à 1.
      > on parle de code arbitraire executé sur ta machine, là.
      
      NON! on parle de possibiltié de code arbitraire exécuté sur ma machine... par rapport à un plantage qui lui est bien réel.
      
      Tu sais que sans fonctionnalité, tu n'as pas de trous :p
      - [^]Re: Sécurité?
        
        Posté par Jean Canazzi () le 22/10/2004 à 18:25. (lien). Évalué à 1.
        Tu préconises donc de ne colmater les failles potentielles qu'après qu'une personne les ait réellement exploité, afin d'éviter de salir le code ?
        
        [^]Re: Sécurité?
        
        Posté par tene (page perso, ) le 25/10/2004 à 08:54. (lien). Évalué à 1.
        Bien sûr que non, je conseille de se concentrer sur l'ensemble du produit:
        - fonctionnalité
        - utilisabilité
        - sécurité
        - etc...
        
        Et si ça salit le code, ton design est à revoir period.
        
        Je préconise de se poser des questions de fond sur les bugs, plutôt qu'un rush sur une faille potentielle de sécurité: Un parseur correct ne doit pas produire ce genre de chose, les corriger à la va vite sans tenir compte de ton design posera des problèmes de régression (toute corrections de bug pose des problèmes de régression entre, dans les meilleurs cas, autour de 5%, autrement dit sur 20 correction 1 introduit un nouveau bug).
        
        En fait, je pense qu'on est d'ailleurs, ce que j'aime pas en fait, c'est l'attitude: on tape le mot "sécurité" et ça devient hyper critique... c'est idiot: c'est un point important, qui n'est pas à négliger, mais ce n'est pas tout... pour l'utilisateur final, qu'il perde son doc à cause d'un virus ou d'un plantage ne change rien: il a perdu son doc, perdu du temps, de l'argent, etc... (y'a un américain pour le moment qui parle pas mal de sécurité nationale :p)
        
        Enfin si tu regardes la pratique, 99% des attaques réussies, réussissent "grâce" (à cause...) à une erreur humaine... et non a une faille du produit utilisé (mes chiffres date un peu, et ça ne tient compte que du monde de l'entreprise). Le social engineering reste la méthode la plus efficace (et crois moi ça fonctionne bien...). Si tu suis ce raisonnement, il serait ptêt plus rentable (niveau taux d'attaque réussies) de coder une fonctionnalité d'assistance à l'utilisateur et de formation que colmater un bug. (ce qui ne veut pas dire qu'il ne faut pas les corriger, au contraire, mais ne pas se faire d'illusion sur le fait que ça empêchera toute attaque).
        
        Enfin bref...

[^]Re: Sécurité?

Posté par Jean Canazzi () le 22/10/2004 à 18:09. (lien). Évalué à 3.
"le problème n'est pas la sécurité dans l'absolu, mais les problèmes engendrés par les trous de sécurité"

J'aime beaucoup ;-)

tant qu'on y est

Posté par Matthieu C () le 20/10/2004 à 19:13. (lien). Évalué à 3.

http://it.slashdot.org/article.pl?sid=04/10/20/1344208&tid=172&(...)

Je sais pas si on aura un jour un navigateur secure. Je crais qu'il faudrait repartir from scratch .....

[^]Re: tant qu'on y est

Posté par Philippe Fremy (page perso, ) le 21/10/2004 à 10:25. (lien). Évalué à 4.
N'importe quoi. C'est justement en repartant from scratch que tu auras le maximum de vulnerabilites. Konqueror, Mozilla, Opera, IE beneficient de milliers d'heures de travail et de tests. Ils resistent deja a des centaines d'attaques.

--
phil.freehackers.org
- [^]Re: tant qu'on y est
  
  Posté par Matthieu C () le 21/10/2004 à 21:10. (lien). Évalué à 3.
  oui, mais il n'ont pas ete developper en prennant compte reellement de la secu.
  
  Si un logiciel est developper proprement dans un but secure, le nombre attaque doit rester proche de 0 tout au long du developpement.
  Donc c'est plutot ton argument qui est _n'importe quoi_ car tu suppose que tout nouveau produit est forcement vulnerable...
  
  Apres je veux bien qu'on dise qu'il y a des heures de boulot pour inclure toute les fonctionnalites de ces navigateurs, mais ce n'est pas forcement le but d'un navigateur secure...

Et IE ? C'est des foutaises !

Posté par Thomas B. (page perso, ) le 22/10/2004 à 15:39. (lien). Évalué à 2.

Excusez moi si j'ai mal compris, mais Internet Explorer ne plante pas à ses tests ?

Il n'a pas du chercher bien loin : http://www.entreparenthese.net/articles/internet-explorer-une-fiabi(...) (partie crashs-test)

Du nouveau

Posté par Ramso (page perso, ) le 22/10/2004 à 17:47. (lien). Évalué à 3.

Le bug ouvert pour l'occasion sur le bugzilla de Mozilla est maintenant marqué comme corrigé :

https://bugzilla.mozilla.org/show_bug.cgi?id=265027(...)

« Fix checked in to trunk, 2004-10-22 10:32 -0700.
Fix checked in to AVIARY_1_0_20040515_BRANCH, 2004-10-22 10:33 -0700.
Fix checked in to MOZILLA_1_7_BRANCH, 2004-10-22 10:33 -0700. »

Vu le nom de la dernière branche, on peut s'attendre à voir la correction dans la prochaine version de Mozilla 1.7, Firefox 1.0 et Mozilla 1.8 évidemment.

--
Groar !

[^]Re: Du nouveau

Posté par Aldoo (Jabber id, ) le 31/10/2004 à 15:44. (lien). Évalué à 1.
Bon, effectivement ça a l'air d'être corrigé dans Firefox 1.0rc1.

C'est pas beau, mais ça ne plante pas ;-) (bref, conforme à ce qu'on attendrait de la spec de Firefox pour du code invalide)
- [^]Re: Du nouveau
  
  Posté par Deyx (page perso, ) le 01/11/2004 à 11:30. (lien). Évalué à 1.
  Tu m'étonne ils ont un gros coup à jouer chez Mozilla, ils peuvent pas laisser traîner ce genre de mochetés dans la version finale de leur nouveau bébé :)
  Y'aura encore des bugs, mais moins flagrants ;)
  Firefox rulez

Revenir en haut de page

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Articles : La robustesse de nombreux navigateurs web mise en cause

Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[+] [^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[+] [^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[+] [^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

[^]Re: Pour IE c'est le code VALIDE qui fait planter :D

Très bon travail

[^]Re: Très bon travail

[^]Re: Très bon travail

[^]Re: Très bon travail

Cool

[+] Attention quand même

[^]Re: Attention quand même

[+] [^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[+] [^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[+] [^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

[^]Re: Attention quand même

fermeture rapide!

Dommage...

Ça picote...

[^]Re: Ça picote...

[^]Re: Ça picote...

[^]Re: Ça picote...

[^]Re: Ça picote...

[+] [^]Dès le début ?

[^]Re: Ça picote...