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...
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
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...