Aller plus loin
- le message sur securityfocus (11 clics)
La robustesse de nombreux navigateurs web mise en cause
20
oct.
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.
# Pour IE c'est le code VALIDE qui fait planter :D
Posté par nicoprog . Évalué à 10.
http://mapage.noos.fr/ccomb/testIE.html(...)
[^] # Re: Pour IE c'est le code VALIDE qui fait planter :D
Posté par Alexandre Beraud . Évalué à 5.
[^] # Re: Pour IE c'est le code VALIDE qui fait planter :D
Posté par samds . Évalué à 8.
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 . Évalué à -2.
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.
[^] # Re: Pour IE c'est le code VALIDE qui fait planter :D
Posté par golum . Évalué à 10.
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 (site web personnel) . Évalué à 6.
$ 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 . Évalué à 3.
$ 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 (site web personnel) . Évalué à 3.
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 M . Évalué à 3.
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 (site web personnel) . Évalué à 1.
[^] # Re: Pour IE c'est le code VALIDE qui fait planter :D
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 4.
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 . Évalué à 5.
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 . Évalué à -5.
« 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 <font size="+2"> IE</font> et <font size="-2"> les autres</font>, c'est qu'<b><u><blink>IE ne *crashe* pas.</blink></u></b>
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 . Évalué à 3.
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 . Évalué à -2.
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 . Évalué à 2.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 3.
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(...)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Pour IE c'est le code VALIDE qui fait planter :D
Posté par imalip . Évalué à 8.
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.
[^] # Re: Pour IE c'est le code VALIDE qui fait planter :D
Posté par walter orengo . Évalué à 1.
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 ^^
# Très bon travail
Posté par Cedric Cellier . Évalué à 7.
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 . Évalué à 4.
[^] # Re: Très bon travail
Posté par totoro . Évalué à 1.
[^] # Re: Très bon travail
Posté par Yann012 . Évalué à 4.
# Cool
Posté par Aurélien Bompard (site web personnel) . Évalué à 5.
# Attention quand même
Posté par peco . Évalué à -4.
Je dis ça, je dis rien...
[^] # Re: Attention quand même
Posté par pasBill pasGates . Évalué à 4.
[^] # Re: Attention quand même
Posté par peco . Évalué à -2.
[^] # Re: Attention quand même
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Attention quand même
Posté par Gniarf . Évalué à 1.
[^] # Re: Attention quand même
Posté par pasBill pasGates . Évalué à 10.
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 . Évalué à 1.
(je suis déjà dehors)
[^] # Re: Attention quand même
Posté par dinomasque . Évalué à 10.
(je comprend mieux le look Playskool de Windows XP maintenant)
[] -> je suis déjà dehors !
BeOS le faisait il y a 20 ans !
[^] # Re: Attention quand même
Posté par peco . Évalué à -2.
+ Googlecheck (tm)
[^] # Re: Attention quand même
Posté par pasBill pasGates . Évalué à 8.
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 . Évalué à 5.
[^] # Re: Attention quand même
Posté par Nelis (site web personnel) . Évalué à 9.
"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 (Mastodon) . Évalué à 7.
Ç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 . Évalué à 3.
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 (Mastodon) . Évalué à 8.
À vouloir trop faire passer ses interlocuteurs pour des cons, on finit par se faire remarquer...
[^] # Re: Attention quand même
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Attention quand même
Posté par Yusei (Mastodon) . Évalué à 5.
[^] # Re: Attention quand même
Posté par renoo . Évalué à 6.
[^] # Re: Attention quand même
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Attention quand même
Posté par Colin Leroy (site web personnel) . Évalué à 8.
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;
[^] # Re: Attention quand même
Posté par thecat . Évalué à -4.
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 (site web personnel) . Évalué à 4.
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 . Évalué à 3.
#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 -=[ silmaril ]=- (site web personnel) . Évalué à 3.
#define FREE0(x) {free(x); x = NULL; }
suffit.
[^] # Re: Attention quand même
Posté par hex . Évalué à 2.
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 . Évalué à 2.
#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.
[^] # Re: Attention quand même
Posté par imalip . Évalué à 4.
if (erreur)
FREE0(x);
tu as une belle fuite memoire...
[^] # Re: Attention quand même
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Pour ne pas casser l'indentation automatique (emacs, indent, etc ...) par exemple.
[^] # Re: Attention quand même
Posté par Philippe F (site web personnel) . É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.
[^] # Re: Attention quand même
Posté par pasBill pasGates . Évalué à 2.
{...};;
C'est equivalent a
{...}
<instruction vide>
;
<instruction vide>
;
Bref, du C parfaitement valide.
[^] # Re: Attention quand même
Posté par gc (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 3.
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. . Évalué à 1.
*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 . Évalué à 3.
Fab.
[^] # Re: Attention quand même
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
[^] # Re: Attention quand même
Posté par gros_rouge . Évalué à 1.
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 (site web personnel) . Évalué à 2.
#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 . Évalué à 1.
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 . Évalué à 4.
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 (site web personnel) . Évalué à 3.
# fermeture rapide!
Posté par nico1980 . Évalué à 1.
# Dommage...
Posté par David Sporn (site web personnel) . Évalué à 0.
# Ça picote...
Posté par arnaudus . Évalué à 7.
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 . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 1.
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 dinomasque . Évalué à 2.
BeOS le faisait il y a 20 ans !
[^] # Dès le début ?
Posté par nodens . Évalué à -1.
[^] # Re: Ça picote...
Posté par Yusei (Mastodon) . Évalué à 4.
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 . Évalué à 2.
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 . Évalué à 2.
[^] # Re: Ça picote...
Posté par Toufou (site web personnel) . Évalué à 5.
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 . Évalué à 1.
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 Anonyme . Évalué à 0.
> plantages "accidentels" sont beaucoup mieux contrôlés.
Il y a u problème avec ton raisonnement : ça colle pas avec Windows, par exemple.
# resultat
Posté par tfeserver tfe (site web personnel) . Évalué à 0.
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 (site web personnel) . Évalué à 3.
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 . Évalué à -3.
[^] # Re: resultat
Posté par Panda Voyageur (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: resultat
Posté par Bruno Muller . Évalué à -1.
- Si tu veux causer avec un serveur (web comme dans ton exemple), c'est netcat qu'il te faut.
[^] # Re: resultat
Posté par gc (site web personnel) . Évalué à 4.
[^] # Re: resultat
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 4.
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 . Évalué à -3.
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 (site web personnel) . Évalué à 4.
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 (site web personnel) . Évalué à 4.
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 . Évalué à -1.
[^] # Re: resultat
Posté par Bruno Muller . Évalué à -2.
[^] # telnet & netcat
Posté par _alex . Évalué à 4.
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 (site web personnel) . Évalué à 5.
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 (site web personnel) . Évalué à 2.
[^] # Re: resultat
Posté par oliv . Évalué à 1.
Et vive l'UDC!
[^] # Re: resultat
Posté par Ackira . Évalué à -1.
# C'est vraiment serieux moz ?
Posté par Guillaume Knispel . Évalué à -2.
Cela dit je les pardonne, c'est CHIANT de coder des tests :p
# hmm
Posté par Francois Revol (site web personnel) . Évalué à 3.
# Pfff on est vraiment nul
Posté par imr . Évalué à 9.
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 . Évalué à 2.
[^] # Re: Pfff on est vraiment nul
Posté par zgnouf . Évalué à 3.
[^] # Re: Pfff on est vraiment nul
Posté par GhZaaark3 . Évalué à 1.
Nada, pas Z'un plantage.
+
ps: ça donne quoi avec nautilus et ghtml?
[^] # Re: Pfff on est vraiment nul
Posté par gnumdk (site web personnel) . Évalué à 3.
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 . Évalué à 2.
[^] # Re: Pfff on est vraiment nul
Posté par Mathieu Pillard (site web personnel) . Évalué à 3.
https://linuxfr.org/~remat/14257.html(...)
[^] # Re: Pfff on est vraiment nul
Posté par Gérald Toussaint . Évalué à 1.
[^] # Re: Pfff on est vraiment nul
Posté par Mathieu Pillard (site web personnel) . Évalué à 3.
# Le bug
Posté par Nicolas Peninguy (site web personnel) . Évalué à 7.
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 . Évalué à 2.
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 . Évalué à 2.
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.
[^] # Re: Sécurité?
Posté par tene . Évalué à 2.
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 . Évalué à 3.
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).
[^] # Re: Sécurité?
Posté par tene . Évalué à 1.
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 . Évalué à 1.
[^] # Re: Sécurité?
Posté par tene . Évalué à 1.
- 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 . Évalué à 3.
J'aime beaucoup ;-)
# tant qu'on y est
Posté par M . Évalué à 3.
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 F (site web personnel) . Évalué à 4.
[^] # Re: tant qu'on y est
Posté par M . Évalué à 3.
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 . Évalué à 2.
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 . Évalué à 3.
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.
[^] # Re: Du nouveau
Posté par Aldoo . Évalué à 1.
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 . Évalué à 1.
Y'aura encore des bugs, mais moins flagrants ;)
Firefox rulez
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.