une appli qui lit un buffer sur plusieurs sockets a la fois" Le probleme est la. tu as plusieurs sockets, mais un seul buffer pour stocker tout le monde a la fois ? on peux partir loin dans les implementations. On peux meme parler des forks et leurs limites.
Il y a plein d'implementations differentes oui tout a fait, c'est une des nombreuses raisons qui font que tu ne comprends toujours pas qu'eviter des BOFs est complique, parce qu'il y a 10'000 cas differents a gerer.
Si ton propos est de dire "appeler strcpy est simple dans 3 cas" super, mais ca on s'en fout pas mal, il reste 9997 cas a gerer.
•La stack non executable c est l un des mecanismes a mettre en oeuvre. Les ret2libc je connais bien ca aussi, c est la parade bien connue, mais plus difficile a maitriser car ils faut savoir pointer sur system(). On peux aussi complexifier le ret2libc via l ASLR, et surtout l ASLR sur un systeme 64bits, ou via noexec. On peux aussi utiliser certaines options de gcc comme -fstack-protection, le RELRO, et toutes ces joyeusetees. Il existe plusieurs projets tres sympa comme hardened gentoo/debian. Mais si on ne donne plus de contextes aux dialogues, on est pas pres de s arreter.
Moi je regarde les distribs dispo au grand public, et force est de constater qu'en tant que developpeur, tu n'as qu'un choix: eviter les BOFs dans ton code parce que les protections du systeme et du compilateur ne sont pas suffisantes pour te proteger.
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -4.
une appli qui lit un buffer sur plusieurs sockets a la fois" Le probleme est la. tu as plusieurs sockets, mais un seul buffer pour stocker tout le monde a la fois ? on peux partir loin dans les implementations. On peux meme parler des forks et leurs limites.
Il y a plein d'implementations differentes oui tout a fait, c'est une des nombreuses raisons qui font que tu ne comprends toujours pas qu'eviter des BOFs est complique, parce qu'il y a 10'000 cas differents a gerer.
Si ton propos est de dire "appeler strcpy est simple dans 3 cas" super, mais ca on s'en fout pas mal, il reste 9997 cas a gerer.
•La stack non executable c est l un des mecanismes a mettre en oeuvre. Les ret2libc je connais bien ca aussi, c est la parade bien connue, mais plus difficile a maitriser car ils faut savoir pointer sur system(). On peux aussi complexifier le ret2libc via l ASLR, et surtout l ASLR sur un systeme 64bits, ou via noexec. On peux aussi utiliser certaines options de gcc comme -fstack-protection, le RELRO, et toutes ces joyeusetees. Il existe plusieurs projets tres sympa comme hardened gentoo/debian. Mais si on ne donne plus de contextes aux dialogues, on est pas pres de s arreter.
Moi je regarde les distribs dispo au grand public, et force est de constater qu'en tant que developpeur, tu n'as qu'un choix: eviter les BOFs dans ton code parce que les protections du systeme et du compilateur ne sont pas suffisantes pour te proteger.