pasBill pasGates a écrit 16059 commentaires

Bien c'est cool, comment tu fais pour juger de la compétence de quelqu'un ?

Je lis ce qu'il ecrit et tant que ca a un minimum de sens c'est qu'il a un minimum de competence.

Enfin tout ça pour dire que jouer à celui qui a le plus gros et le plus beau CV qui travaille dans l'entreprise la plus grosse et ayant les meilleurs développeurs du monde (et qu'en plus tu es capable de corriger !), tu peut le garder pour draguer à la plage (par exemple).

Le but est pas de dire que j'ai la plus grosse, je pense pas forcement que les dev/testeurs ici sont plus forts que chez Google, Oracle ou autres entreprises de ce style, mais force est de constater que ces gens ont une experience de developpement de gros softs largement utilises qui doivent tenir la route. Quand a trouver des bugs dedans, le point est justement de dire que meme si t'es bon, il y a toujours des bugs dedans, j'ai jamais dit qu'ils etaient super dur a trouver et que j'etais un genie pour ca.

Je rajoutes des contraintes quand ca m'arrange ? Je t'ai donne un exemple typique plus haut : gestion du protocole TCP

Explique moi quel OS a une stack TCP mono-thread, ou quel soft serveur est mono-thread et lequel de ces softs peut se permettre un pool non-performant...

Si tu te contentes de faire un push_back, alors tu auras des reallocations frequentes plutot qu'une allocation, sachant que la taille moyenne est de 10, le moyen pour regler ca est de faire un reserve(10) a la 1ere insertion, mais dans ce cas, autant creer le vecteur a la 1ere insertion aussi.

Tu crois qu'un vecteur vide est forcement rare, c'est pas forcement le cas, ca depend du scenario, il y a plein de cas ou t'as besoin d'une structure pour gerer un tableau a taille dynamique mais qu'il se peut que tu n'aies jamais d'elements.

Prend un protocole avec une liste d'options par exemple (TCP par exemple), a chaque connection tu veux garder la liste des options et leur parametres. Il y a de fortes chances que tu n'aies aucune option, mais il se peut tout a fait que tu aies plusieurs options aussi

Un pool à multiples blocs, typé et réutilisable, c'est grosso-modo 20 lignes de code, sans aucun impact sur le reste si on surcharge new/delete dans la structure bob. Ou est le problème ?

20 lignes ? J'aimerais bcp voir un pool en 20 lignes qui marche et qui est efficace (temps d'allocation, support multithread,...)

J'ai un peu de mal à cerner le genre de programme auquel tu fais référence : on a besoin d'un maximum de performances (on descend jusqu'au lignes de cache), mais d'un autre coté on alloue de nombreux objets de petite taille, avec cycle de vie court (la performance des ctor/dtor a été évoquée), et on ne peut pas faire de pré-allocation massive parce qu'il faut aussi réduire l'empreinte mémoire globale...

Un OS ou soft serveur, ces jouets la typiquement on besoin de controle sur leur empreinte memoire et doivent etre rapide.

Non c'est pas moi, tu m'as vu faire ca ou ?

Perso je consideres que l'experience d'une personne a de la valeur tant qu'il n'est pas incompetent.

Dis-moi, c'est quelle partie de la phrase

Attackers can exploit this issue to execute arbitrary code with superuser privileges, facilitating the complete compromise of affected computers

que tu as rate ?

a) GRSEC n'est de loin pas present sur tous les kernels, de tres loin meme
b) C'est pas une protection a 100%, il y a des manieres de passer outre (cf. http://jon.oberheide.org/blog/2011/04/20/stackjacking-your-way-to-grsec-pax-bypass/ )

Serieusement, je te suggeres de te renseigner un peu plus sur ce champs avant d'affirmer des choses comme tu le fais. La securite c'est vraiment pas le bon champs pour prendre des decisions sans comprendre de quoi il en retourne.

Gni ? L'implémentation de std::vector n'est pas obligée de faire une préallocation si on ne donne pas de capacité initiale. Si le constructeur par défaut le fait quand même, c'est un problème de qualité d'implémentation de std::vector.
Si dans ton cas particulier le vector contient généralement 10 elements, rien ne t'empeche de faire un reserve(10) avant la premiere insertion, que le vecteur soit alloué dynamiquement ou non.

Si tu dois de toute facon avoir du code avant la 1ere insertion, pourquoi alors te taper ces 12 bytes additionels tout le temps ?

Un simple pool de char[sizeof bob] obtenues via l'allocateur est suffisant.

Et il a quelle taille ton pool ? Tu alloues un gros bloc bien enorme qui mange la RAM et qui a l'effet oppose(je te rappelles que l'objectif est minimiser l'utilisation memoire hein) ou tu alloues plusieurs blocs a la demande auquel cas il te faut gerer les allocations/deallocations des blocs complets avec tracking, etc... ?

Cadeau : http://www.securityfocus.com/bid/48538/discuss

Serieusement, tu n'as absolument aucune idee des risques et consequences de diverses erreurs de programmation en matiere de securite visiblement.

Vaut mieux ca que coder en C en croyant qu'eviter les BOF est simple. Au moins ca evitera que le systeme se mette a executer du code externe.

Dans son cas, il a deux threads, et deux variables, ou il pose ses mutex sur une variable apres l autre, ce qui provoque cette corruption entre le size_t et la vraie taille memoire du char *. Le soucis est de ne pas avoir ecrit ses threads correctement (deux erreurs de conception) ca n a rien a voir avec une gestion de char *.

Ben donnes moi un exemple ou l'erreur est dans le traitement du char* alors, c'est quoi l'erreur ? Il s'est trompe de variable et a passe le mauvais char* comme parametre ?
Non la plupart des cas sont dus au fait que la taille de buffer (a lire, a allouer, a ecrire, ...) est fausse pour une raison X ou Y. X ou Y peut etre une erreur de calcul, un integer overflow/underflow, une race condition, etc...

Un hacker aura bien du mal faire expres de foirer les threads comme decrit alors que tout fonctionne autrement, pour une raison tres simple : le probleme ne vient pas d une attaque!

Tu es naif mon cher, tu crois que je l'ai invente de toute piece ce scenario ? Je te rappelles que j'ai passe 6 ans a bosser sur des failles dans un OS de 30 millions de lignes hein, le hacker il va simplement constamment te lancer 2 requetes en simultane et attendre qu'une fois ca declenche la faille toute simplement...

Ce n est donc pas plus un probleme de securite lie a un BOF potentiel.
De plus, je rappelle que pour des serveurs ou il faut de la securite, y a un mec qui s appelle Spender et qui produit des patchs kernels plus qu interessants.

Moi je te suggeres de te demander si tu devrais prendre en compte l'avis de quelqu'un dont la securite a ete le boulot pendant 6 ans plutot que balancer cela par dessus l'epaule comme ca...

Quel est le cout d'un constructeur / destructeur pour un vecteur vide ? Si le cycle de vie de la structure est un probleme de performance, ca ne viendrait pas plutot de l'allocateur ?

Ca depend du cas comme pour tout, si par defaut ton vecteur a une taille allouee de 10 objets (parce que dans le cas usuel ou le vecteur contient quelque chose il en a 10), ton constructeur va faire une allocation a chaque fois par exemple.
Si ton vecteur est cree uniquement lorsque un objet va etre ajoute, ben tu sauves cette allocation pour tous les cas ou aucun objet n'est ajoute.

En ce qui concerne la taille de la structure et les performances d'un allocateur "standard" par bloc, cela n'est pertinent que si tu alloue tes structures unitairement avec cet allocateur (un gros tableau de structures n'est pas concerné).Si tu as vraiment des problèmes de performance liées a ton allocateur, pourquoi ne pas en prendre un autre, puisque le langage le permet facilement ?

Je vais te donner un tres bon exemple de pourquoi: L'allocateur standard dans Windows a tout un tas de features pour eviter qu'un buffer overflow dans la heap ne se transforme en vulnerabilite (c'est pas une garantie a 100% mais il rend la chose vraiment compliquee pour le hacker), je ne connais a peu pres aucun allocateur 'custom' qui a ces features.

on parle bien de "ouais mais le C/C++ c est trop complique, car t as des BOFs partout quand tu manipules des char *", et toi tu viens avec un probleme de gestion des threads, pas un probleme de gestion de char *. la source du probleme n est pas du tout la meme.

Non tu n'as visiblement pas compris le probleme. En C++ tu peux meme utiliser std::string si ca te chante est t'es dans le meme cas que Java, la seule difference c'est qu'en C++ si t'as un acces hors buffer rien ne t'arrete, tu vas aller ecrire sur les structures de la heap, sur la stack, etc... alors qu'en Java tu vas prendre une belle exception dans la tete. C/C++ te permet de faire de l'arithmetique de pointeur et aller lire/ecrire ou tu veux, et c'est ca l'enorme difference avec des langages type C# ou Java, avec eux t'as beau avoir une variable modifiee sans le savoir par un autre thread, tu n'auras jamais de BOF car la VM ne te laissera jamais lire ou ecrire hors du buffer.

Tu ne parles pas de probleme de gestion de debordement memoire comme ca a ete le cas au debut, tu parles de probleme de gestion des threads sur un acces concurrent, qui donnent une corruption de la data qu aucun langage ne va corriger pour toi.

Si c'est un probleme de gestion de debordement memoire, et justement un langage comme Java te protege de cela alors que C/C++ non.

En ayant un pointeur :

a) J'evites le cout du constructeur / destructeur si le vecteur n'est pas utilise
b) J'economises 12 bytes sur la taille de la structure qui peuvent faire une sacree difference selon l'utilisation et qui notamment:
- peuvent faire la difference entre entrer dans une ligne de cache ou pas par exemple qui a un impact plutot gros selon les cas
- ca peut aussi te permettre d'economiser pas mal de RAM si tu passes ta structure d'une taille d'un peu plus de 64 bytes a moins de 64 bytes par exemple du fait du fonctionnement de l'allocateur standard (il prendra l'allocation sur la liste des blocs de 64 bytes plutot que 96 ou 128)

Dans les cas ou le vecteur n'est utilise que dans certains cas, ca peut avoir une valeur absolument significative

Je parles d'un tableau ? Non je parles d'un vecteur qui est conceptuellement membre d'une structure largement utilisee.

public struct bob { vector<int> *MonVecteur; plein de bordel supplementaire}

Ben tout depend des structures a gerer, quand la vitesse n'est pas l'element le plus important mais l'espace memoire l'est, faut faire des choix. Tu passes de 20 bytes a 8, t'as 60% de gain, c'est consequent. en plus ca peut permettre de faire rentrer ta structure dans une ligne de cache, etc... qui amenera des gains non negigeables en vitesse.
Maintenant est-ce que ces vecteurs seront le plus souvent utilises ou pas ? De nouveau ca depend du probleme, dans certains cas oui dans d'autres non. Evidemment que si ils sont le plus souvent plein alors c'est pas rentable.

Le test de non-nullite supplementaire c'est 1 cycle, c'est genre 0 comme cout. Quand au new+delete en plus, tu peux toujours avoir un systeme de cache de vecteurs dispo si tu veux qui t'evite ce cout la(si t'en as besoin, de nouveau c'est selon les besoins).

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.