"Je suis sur qu'il doit bien rester un octet en mémoire."
On ne peut jamais en être sûr et certain ... je pense plutôt que dans l'exemple, le codeur "sait" que le systeme lui alouera plus que ces 8 octets (sizeof(int) * 2) pour des raisons d'alignement mémoire (32, 64 ...) et qu'à priori, ils resteront "réservés" ...
Ceci dit, je te rejoints complètement sur ton experience de buffer overflow ... je dirais même que le comportement que tu décris et le plus souvent produit.
En effet, un programme peut modifier ses octets partout où il le souhaite sans générer un seul SIGSEGV tant qu'il reste dans sa plage de mémoire réservée par le système ; par contre, par la suite, le programme a en effet de forte chances de planter à un moment ou à un autre parce que ces octets modifiés vont modifier aléatoirement son comportement ... Et on aura notre SIGSEGV parce qu'aléatoirement, on a plus de chance de taper hors sa zone mémoire que dedant :-)
Tiens, ca me rappelle des "challenges informatiques" ... Par exemple, sur un noyau minimum permettant un accés illimité à l'ensemble de la mémoire pour les processus, le but étant de créer un processus capable de corrompre les autres processus tout en assurant sa protection.
Tous les processus sont déclenchés ex-equo et le survivant faisait gagner son codeur.
[^] # Re: Un milliard?!
Posté par Guinns . En réponse au journal 306 bugs dans FreeBSD. Évalué à 1.
On ne peut jamais en être sûr et certain ... je pense plutôt que dans l'exemple, le codeur "sait" que le systeme lui alouera plus que ces 8 octets (sizeof(int) * 2) pour des raisons d'alignement mémoire (32, 64 ...) et qu'à priori, ils resteront "réservés" ...
Ceci dit, je te rejoints complètement sur ton experience de buffer overflow ... je dirais même que le comportement que tu décris et le plus souvent produit.
En effet, un programme peut modifier ses octets partout où il le souhaite sans générer un seul SIGSEGV tant qu'il reste dans sa plage de mémoire réservée par le système ; par contre, par la suite, le programme a en effet de forte chances de planter à un moment ou à un autre parce que ces octets modifiés vont modifier aléatoirement son comportement ... Et on aura notre SIGSEGV parce qu'aléatoirement, on a plus de chance de taper hors sa zone mémoire que dedant :-)
Tiens, ca me rappelle des "challenges informatiques" ... Par exemple, sur un noyau minimum permettant un accés illimité à l'ensemble de la mémoire pour les processus, le but étant de créer un processus capable de corrompre les autres processus tout en assurant sa protection.
Tous les processus sont déclenchés ex-equo et le survivant faisait gagner son codeur.