pasBill pasGates a écrit 16169 commentaires

Et tu crois qu'un BOF c'est quoi d'autre que "j'ecris n'importe quoi en RAM" ?

Si j'ecris n'importe quoi dans la variable contenant la taille du buffer a allouer
Si j'ecris n'importe quoi dans la variable contenant la taille a copier
Si j'ecris n'importe quoi dans la chaine de caractere definissant les parametres a ecrire du printf
etc...

Un BOF c'est TOUJOURS une erreur ou un gars fait une connerie quelque part. Le cas de threads ecrivant l'un apres l'autre n'est qu'un cas parmis bcp d'autres et il n'est en rien different d'une erreur dans le calcul de taille a allouer.

C'est pour ca que je te dis que tu ne te rends pas compte de quoi tu parles, des cas ou tu peux causer un BOF je peux t'en citer des dizaines auquel tu n'aurais jamais pense.

Pourtant il a raison. J'ai plusieurs fois regarde le marche du travail informatique en Suisse pour rentrer au pays et c'est triste a mourir.

J'ai un CV en beton arme, mais c'est con je trouves rien de correct:
- Soit c'est dans une banque/assurance a faire de la merde
- Soit c'est une petite/moyenne boite info qui va me diviser mon salaire par 2 avec une garantie de survie de la boite pas forcement tres elevee
- Soit c'est une SSII ou il faut mettre un costard et lecher le cul des clients et dire oui a toutes les conneries qu'ils demandent meme lorsque cela n'a aucun sens

C'est triste, mais les VRAIS jobs de developpeurs sur un produit un peu sur le long terme avec des conditions decentes c'est rare en Europe. Il y a Google(a Zurich) et quelque autres mais c'est tout.

Eviter les BOFs c est simple, il est facile d encadrer ce qu un soft recoit d un input clavier, d une lecture de fichier, d une socket.

Non c'est toujours et encore une enorme connerie.

Il y a des cas bien plus difficiles a gerer, comme des threads (deadlocks, acces concurrents) qui eux vont corrompre ta stack. Si ta stack est corrompue, tout peux arriver, ca peux etre un BOF

Je me demandes, tu comprends ce que c'est un BOF ? Le buffer overflow est l'action qui corrompt ta stack(en assumant que ton buffer est sur la stack), c'et pas la modification concurrente de ta variable de taille qui corrompt la stack.
Tout buffer overflow est le resultat d'une action precedente qui etait fautive : calculer une taille de buffer, mal gerer des acces concurrents a cette variable de taille, etc...

Dire qu'eviter les BOFs c'est simple, mais pas dans certains cas c'est contradictoire hein. Soit c'est simple dans TOUS les cas, et alors eviter les BOFs c'est simple, soit eviter les BOFs n'est pas simple.
Dire qu'eviter les BOFs c'est simple sauf dans les cas A, B, C, D, E, F, G, H, I, J, K, .... c'est pas serieux.

Exemple typique : une structure de vecteur a la base c'est dans les 20 bytes si mes souvenirs sont bons, quand t'ecris du code qui a besoin d'avoir une empreinte memoire faible, tu preferes souvent avoir un pointeur qui ne prend que 8 bytes, et si/quand t'as besoin du vecteur tu l'alloues.
On peut parler des perfs niveau cycles CPU aussi, car NRVO a ses limites, etc... Si tu ecris ton code de maniere 'academique' sans te soucier des perfs c'est sur que t'en as pas autant besoin, mais pour des softs ayant des contraintes ca change.

On sait tous les 2 ce qui corrompt les donnees : la mauvaise operation a la base (acces concurrent, mauvais calcul de taille, ...)

Et c'est ca qui fait que ton message "eviter les BOF c'est simple" est une horreur pour mes oreilles, il y a 10'000 manieres differentes de causer un BOF dans un soft, aucun developpeur sur cette planete n'a les capacites pour eviter tous ces cas de maniere garantie dans un soft non trivial.

Le probleme n est donc pas un BOF, mais un acces concurrent a une data, qui a pour consequence un BOF dans ce cas la (et qui fait que du coup on remarque le probleme). On en reviens donc tjs a la meme chose : Les buffers on sait les manipuler

Et quand tu te loupes dans ton calcul de taile a copier, c'est pas un BOF non plus alors, c'est un mauvais calcul mathematique qui a pour consequence un BOF.
Et puis un printf ou tu fais pas gaffe au format, c'est pas un BOF non plus, c'est une erreur de validation de la chaine de caracteres pour etre sur que l'user a pas mis de %s dedans
etc...

D'ailleurs en realite, l'erreur elle est toujours ailleurs, elle est dans le calcul d'un ou plusieurs parametres d'une fonction, qui au final amene un BOF. un BOF ca n'existe pas de lui-meme, il est toujours un resultat d'une mauvaise operation.

Non, c'est uniquement financier, ce n'est rien de technique.

Non justement, c'est technique aussi. Parce que si tu vends un soft et qu'il a le malheur d'avoir du succes, alors le jour ou une faille apparait, chose contre laquelle tu ne peux pas grand-chose et que tu dois payer tout le monde, tu es en faillite.

C'est très facile de faire la course aux fonctionnalités, par contre c'est extrêmement difficile de maintenir la qualité dans ces conditions. Très peu de choses sont faites par les éditeurs dans ce cas ou ça commence, mais doucement (et je sais que Microsoft fait des efforts particuliers pour redorer son image et c'est très bien, mais d'autres ne font toujours rien).

C'est extremement difficile de faire des softs sans failles point. Rien a voir avec course a la fonctionnalite ou pas. Tu sembles croire qu'il y a des failles parce que les developpeurs preferent passer du temps a rajouter des features qu'a faire les choses proprement, et tu as tout faux. Non pas que certains ne le font pas, mais nombre de societes font attention a la qualite, et malgre cela ont toujours des failles.

Je ne parle pas de fournir des logiciels sans bug, je parle de fournir une responsabilité financière auprès des éditeurs dans des cas bien précis, ceux où le système est infecté par un exploit distant ne nécessitant pas d'intervention utilisateur particulière.

Et dans le cas de MS qui a 30 millions de lignes de code installees chez 1 milliard de gens, tu esperes comment qu'on arrive a payer pour quelque failles sans etre en faillite ? A 2$ la faille en estimant qu'on ne paie que 50% des systemes, ca nous fait 1 milliard par faille, a 8 failles par an dans 30 millions de lignes MS perd de l'argent sur Windows.

N'insulte pas les administrateurs n'ayant pas choisi de solution uniquement Microsoft. Dovecot est le logiciel IMAP/POP de OS X Server et djbdns n'est pas un inconnu sur le marché des serveurs DNS.

Je me contentes de regarder les parts de marche, djbdns est un nain de jardin compare a BIND et autres, Dovecot est tout simplement non-existant et tu sais parfaitement que 3 pekins est probablement une estimation optimiste du nombre d'utilisateurs de Mac OS X en serveur.

Eeuuuhhh... il y a plein de tres bonnes raisons d'instancier des vecteurs dynamiquement, j'ai du mal a croire que tu n'en aie jamais vu...

T'as une variable qui definit la taille d'une structure globale a allouer.

T'as 2 requetes qui arrivent presque en meme temps, la 1ere definit une taille et ton thread bouge un peu plus loin pour allouer mais est preempte, pendant ce temps la 2eme requete passe, definit une nouvelle taille plus petite et est preempte, ton premier thread reprend, alloue un buffer plus petit que la structure de la 1ere requete, et paf lors de la copie il y a un buffer overflow.
La cause initiale est une race condition, le resultat final est un buffer overflow.

C'est un exemple basique que je t'ai cuit en 2 minutes. Tu vas me dire "ouais mais il suffit de XXX pour que ca n'arrive pas, le developpeur est un nul !", mais tu vois, la realite est que tu as certainement deja fait des erreurs de ce genre ou meme pire, parce que ca arrive a tout le monde quand le code devient un minimum complique, et crois moi un OS ca a des bouts codes incroyablement complexes avec du code s'executant en asynchrone un peu partout histoire d'avoir des performance correctes.

J'en ai plein d'autres si tu veux, les failles de securite ca a ete mon pain pendant plus de 6 ans sur une plateforme qui a ete probablement 10x plus testee que tous les bouts de code que tu as pu voir dans ta carriere, t'as pas idee de ce qu'il peut y avoir comme faille...

Je m amuse avec plusieurs outils, des valeurs extremes, des caracteres aleatoires ... mon but est que dans le pire des cas, ca remonte seulement une erreur. Il est facile de tester tous les caracteres possibles ainsi que des tailles depassant les buffers internes qui sont bornes. les soucis d archi, ca se passe a un autre niveau que ton code C (hormis la taille de certaines variables, mais c est connu et documente)
Et comme j ai dit, la problematique des BOFs t en as vite fait le tour. Il existe pire que cela.

Je peux te citer une ribambelle de developpeurs chez nous qui ont des annees et des annees d'experience, qui ont un niveau a faire rougir le plus baleze des developpeurs que tu connaisses, et pourtant j'ai trouve des failles dans leur code, malgre le fuzzing de leur equipe de test.

Encore une fois, croire que c'est simple est un aller simple pour le ravin. Si tu crois que le fuzzing c'est facile et qu'il suffit de tester tous les caracteres et tailles, crois-moi t'as encore rien vu, ca c'est les cas basiques de fuzzing. Il y a tous les cas de race conditions, de changement d'etat, etc... qui entrent en compte par exemple et qui peuvent te sortir un BOF la ou tu ne l'attendrais jamais.

Désolé... Moi je croyais qu'un logiciel prenant autant de place que deux DVD Debian n'avais pas besoin de plugin, puisque pour que ça prenne cette taille c'est que ça devait intégrer tout ce qui existait sur terre ...

Deux DVD Debian ? Marrant, mon install ne prend pas autant de place...

Et puis SVN ça va bien 5 minutes, et de ce que j'en lis, VS n'est pas adapté aux workflow des SCM distribués. On dirait Eclipse et son plugin pour Git, qui est complètement imbitable que même linus torvalds ne retrouverai pas ses petits.

Les SCM distribues j'en sais rien je les ai jamais utilises, pour les autres c'est totalement utilisable avec le plugin approprie, on ne fait que ca en interne.

Ça c'est quand c'est moi qui fait la config, et encore, c'est tellement chiant de devoir resélectionner toujours l'option que parfois j'oublie. Et si c'est pas moi, mais quelqu'un d'autre et qu'il ne fait pas gaffe ...
Franchement, ou est la justification du fait de séparer les deux complètement ? La conffe de développement est si différente de la conffe de prod ?

Absolument oui, par exemple :
- T'as des #define definis uniquement pour le mode DEBUG qui ralentissent le produit mais facilitent enormement le debuggage (cherche _ITERATOR_DEBUG_LEVEL dans STL pour un exemple)
- T'as pas forcement envie que les actions post-builds balancent tes binaires au meme endroit (machine de test, etc...)
- Si tu link des binaires entre eux avec interfaces C++, tes modes debug et release doivent cibler des binaires differents car ces binaires seront differents
etc...

Manifestement à l'époque ou je l'utilisait (y a 6 mois), je t'avais pas attendu pour trouver ce menu, puisque j'y vois un c++ et h++ dedans... Bien sur, après c'est reconnu comme source C++, mais ça veut pas pour autant le compiler. À la place ça me met une erreur bien flippante du genre "t'a tout merdé, réinstalle!". On sens le logiciel de qualité !

Une fois que tu m'auras montre que le probleme est situe dans le produit (c'est repetable, etc...) je penserais a cibler le produit, d'ici la je continuerai a penser, en ayant lu ce que tu connais de VStudio, que le probleme est sur la chaise...

J'ai passe plus de 6 ans a faire de la securite sur l'OS le plus utilise de la planete, ecrit par certains des meilleurs developpeurs C de la planete avec probablement un des meilleurs niveau de QA tous OS confondus, et j'ai vu nombre de problemes avec ces fonctions au point ou maintenant elles ont TOUTES ete remplacees par d'autres fonctions plus sures, bref on va dire que de l'exeperience niveau BOFs j'en ai jusqu'au cou.

Alos dis-moi donc, pourquoi un groupe comme le notre compose de gens pourtant tres solides niveau C, avec des outils d'analyse statique parmis les plus avances qui soient, avec une utilisation systematique du fuzzing, avons pris cette decision ? On avait envie pour le fun de virer ces appels partout ?

Parer des BOFs n'est PAS simple. C'est simple dans le cas simple et basic ou t'as un printf dans un hello world evidemment, mais c'est pas le cas de la majorite des printf dans des vrais softs un tant soit peu complexe.

A mon avis ces comparaisons n'ont pas trop de sens. L'IDE utilise va bcp varier selon le langage, bref t'auras plus une estimation des parts de langages qu'autre chose.

C++ ou C# ? A peu pres tout le monde utilise Visual Studio sous Windows
Java ? Ca sera Eclipse/netbeans, Visual Studio ne gere pas Java par defaut donc faudrait etre un peu dingue pour se faire chier a le customiser et l'utiliser la.

C'est dans le journal, pas de garanties.

Des garanties ? C'est TECHNIQUEMENT IMPOSSIBLE , comment veux tu qu'on donne des garanties lorsque c'est techniquement irrealisable ?

C'est dans le journal, j'ai cité dovecot et djdns.

Super ! Tu veux que je te trouves 2-3 composants dans Windows qui n'ont jamais eu de failles ? Sans probleme hein. Mais on parle d'un OS entier utilise par 1 milliard de gens donc cible privilegiee, pas de 2 softs utilises par 3 pekins.
Faudrait penser a comparer ce qui est comparable.

Et ? La responsabilité sera à qui de droit, je vois pas ce que tu veux dire là.

Et ? Tu trouves pas que proteger ta grand-mere est mieux que lui dire "facile, va te plaindre a Adobe !" ?

Ma critique n'est pas là, mais sur le fait que le réseau n'est pas fait pour assurer la sécurité des machines connectées. Le réseau est sensé être un simple tuyau.

Et rien n'a change, ces pages n'ont pas disparu du reseau, elles ont simplement ete evaluees comme ayant zero valeur pour les utilisateurs de Google. Tu vas peut-etre me dire que cette evaluation est mauvaise ?

Et c'est quel effort qu'on ne fait pas ?

Allez, donnes moi donc un exemple d'effort qu'on ne fait pas mais que cette fantastique communaute Linux (ou les entreprises autour) fait.

Appeler ce que Google fait une censure est, desole du terme, une grosse connerie. Esperer qu'un utilisateur avec des dizaines de softs & plugins installes sur sa machine en moyenne soit tout le temps a jour est une chimere, peu importe l'OS, sans parler du fait qu'enormement de malwares n'utilisent absolument pas une faille mais la credulite de l'utilisateur.

Partant de la que Google bloque un gros nid de malware sans aucune autre valeur est tout a leur honneur. Ca aidera enormement de gens s'y connaissant peu qui se feraient avoir sans cela, que leur OS soit sur et/ou a jour ou pas.

Tu me montres un soft qui fait du refactoring en C++ correctement ? Ah oui ca n'existe pas...

Et le refactoring de VStudio pour C#, t'en penses quoi ?

Tu n'as jamais eu de bug dans ton code ? T'as jamais eu un cas ou tu t'es rendu compte que t'as fait une connerie ?

Oui ? Ben bienvenue dans le monde de tous les developpeurs de cette planete. C'est comme ca que les failles se creent, dire "il suffit de" est juste un gag, parce que bon, je peux generaliser hein :

Il suffit de ne jamais faire d'erreur et c'est regle, c'est pourtant simple !

y avais aucune intégration avec git/mercurial, et je suis même pas sûr qu'il y avais ne serait-ce que cvs ou svn

Ce genre de truc se fait a travers des plugins, http://www.visualsvn.com/ par exemple.

et les options des projets restent comme d'habitude complètement imbitables (surtout sous windows ou linker est une vraie galère) et mal organisé avec encore leur séparation minable debug-release ou par défault tu n'en configure qu'un seul des deux.

Tu assumes totalement si tu n'en configures qu'un des deux, il est tout a fait possible de changer les parametres dans toutes les config a la fois d'un coup.

Sans parler de la gestion chiante des fichiers (impossible d'arriver à lui faire respecter l'arbo du système de fichier !)

Ca veut dire quoi ca ? J'ai rien compris, j'ai jamais eu de problemes a lui faire creer les fichiers la ou je veux ou lui faire ajouter des fichiers existants sans qu'il les recopie ailleurs.

et de l'importation (si tu veux importer 500 fichiers .h++/.c++ qui n'ont pas de projet ... ben t'est foutu. bonne chance pour lui faire bouffer du .c++/.h++ en tant que "source C++" et "header C++" sans devoir lui dire pour chaque fichier).

Tools -> Options -> Projects & Solutions -> VC++ Project Settings -> C/C++ File Extensions

On va dire que tu connais VStudio assez mal...

mouais, ça fait juste une vingtaine d'années que je programme en C et je n'ai participé qu'à une vingtaine de projets open source, windows ou unix. Je manque en effet un peu d'expérience. Il faudra aussi que je mentionne devant mes étudiants en informatique que je n'ai pas beaucoup d'expérience.

Desole mon cher, mais sortir une ineptie pareille donne l'image que j'ai decrite. Il suffit de regarder les failles trouvees pendant des annees pour voir que non, lire la doc ne suffit pas, l'erreur est humaine et certains cas sont plus compliques que tu ne le penses (il n'est pas evident que le texte vient de l'exterieur, etc...)

A la crade : le constructeur appelle une methode d'init statique...

Moi je te dirai plutot que tu n'as visiblement pas bcp d'experience du sujet.

Le nombre de failles causees par les fonctions type printf est enorme et nombre de gens s'y sont pris les pieds. Croire que seuls les developpeurs debiles se plantent et qu'il 'suffit' de lire la doc est un gros gag. Si c'etait si simple il n'y aurait jamais de bugs.

T'as pas compris, il n'y a pas de VM, le code est compile en natif et tourne directement sur le CPU.

Il y a un moment où il te faut une machine virtuelle. Soit elle est logicielle en langage machine (même si elle subit une ou plusieurs étapes de compilation), soit tu grave la machine virtuelle dans la CPU et le byte code peut s'exécuter directement dessus.

En fait... non, t'en as pas forcement besoin. cf. http://research.microsoft.com/en-us/um/people/larus/talks/cav08_invited_talk.pdf (cherches le mot Bartok)

Le code est verifie, puis compile en code natif.

Ce genre de projet (il en existe aussi pour Java), ne sont pas viable tant que la VM n'est pas gravé dans le silicium.

On va dire que tu sous-estime serieusement ce qu'il est possible de faire avec une architecture appropriee...

Je trouves scandaleux qu'il n'y ait aucune mention du the froid Migros sur la page Wikipedia, alors que c'est de tres loin leur produit phare !