buffer underflow - Page 1

Salut

Je ne m'y connais pas beaucoup en programmation, c'est pas du tout ma formation initiale mais je m'y intéresse quand même un peu.
J'entends beaucoup parler de bugs dus à des "buffers overflow". De quoi s'agit il? J'ai cherché un peu sur wiki mais je comprends pas trop. D'après ce que j'ai compris, ça consisterai à écrire dans une zone de la mémoire qui n'est pas appropriée. De plus, il semblerait que de nombreux pirates utilisent le "buffer overflow" pour contourner certaine choses : par exemple, le firmware de la PSP.

Quelqu'un peut m'en dire plus?

Edited_3648

Les buffers overflows les plus dangereux sont ceux qui sont sur la pile d'exécution, parce que ça peut réécrire les adresses de retour des fonctions (et exécuter le code qu'on veut)... mais les buffers overflows sur le tas peuvent mener à pas mal de conneries aussi (corruption de mémoire => crash ou parfois exécution de code arbitraire).

En général, la zone de la pile se présente approximativement de la façon suivante:
... zone mémoire en-dessous du pointeur de pile ...
|[Pointeur de pile (SP) pointe ici]|
arguments empilés pour les fonctions (à moins que tous les paramètres soient passés par registres)
variables de la fonction courante
un tableau qui nous intéresse
variables de la fonction courante
Frame Pointer (FP)
Adresse de retour
arguments empilés pour les fonctions
variables de la fonction parente
etc.

Sur ma représentation, la pile grandit du bas vers le haut.

Si on écrit les tableaux dans le sens contraire à celui où la pile grandit (tableaux écrits du haut vers le bas) - ce que la quasi-totalité des processeurs fait - on peut écrire au-delà du tableau, par-dessus les variables, FP, et l'adresse de retour.
Comme ça, si on rentre exprès du code machine dans le buffer, et que par-dessus l'adresse de retour, on écrit une adresse qui pointe dans le buffer, et bien on a pris le contrôle du processeur, et on peut exécuter des conneries.

Les buffer overflows sur la pile seraient moins dangereux si les tableaux étaient écrits dans le même sens que la pile (du bas vers le haut), puisque ça rendrait plus difficile la réécriture de l'adresse de retour (il faudrait accéder à un offset négatif par rapport au début du buffer, ce qui veut dire que le code original est mal fait - par exemple, il présente un integer overflow !).


Sur les machines évoluées (x86 modernes, par exemple), une semi-protection contre les buffer overflows sur la pile est la protection hardware (activée par l'OS) contre l'exécution de la pile. Ca rend l'exploitation plus difficile, mais pas impossible.
Voir le Month of PHP Bugs à http://www.php-security.org/ : tout plein de trucs super mal faits dans le code de PHP, dont pas mal de buffer overflows. L'auteur du Month of PHP Bugs a essayé d'améliorer la sécurité de PHP de l'intérieur pendant des années, mais il a fini par en avoir marre d'être mal considéré par les principaux développeurs PHP, que beaucoup de modifs très importantes pour la sécurité ne soient pas effectuées, et que plein de conneries d'architecture soient ajoutées.

de façon peut-être plus compréhensible pour les non-initiés : (je sais pas si c'est le cas de jul2149, mais ça servira au moins pour une personne qui lira ce topic )

supposons que ton cerveau soit organisé de la manière suivante :

  char phrase_courante[500];   // on réserve 500 caractères pour enregistrer la phrase courante
  char souvenir_1[500];   // puis on laisse de la place pour stocker les souvenirs...
  char souvenir_2[500];   // ...
  char souvenir_3[500];   // ...

autrement dit, ta mémoire de 2000 caractères sera organisée comme ça :

0 1 2 3 ... 498 499 500 501  ... 999 1000 1001 ... 1499 1500 1501 ... 1999
\ phrase courante / \ souvenir n°1 / \  souvenir n°2  / \  souvenir n°3  /

bref, en temps normal ton cerveau stocke la phrase qu'il est en train d'entendre dans la zone de 500 caractères appelée 'phrase_courante', puis il essaye de la comprendre et si elle est intéressante il la stocke dans un des souvenirs (ah bon, c'est pas du tout comme ça que ça fonctionne en vrai ? )

le problème c'est qu'il y a une faille : si un méchant pirate s'amuse à te dire une phrase de plus de 500 caractères, qu'est-ce qui se passe ? si le concepteur de ton cerveau n'a pas fait attention à ça, après avoir enregistré le caractère n°499, ton cerveau va continuer à stocker le caractère suivant dans la cellule mémoire suivante, à savoir la cellule n°500, mais c'est une cellule qui appartient au souvenir n°1 ! donc le 1er caractère du souvenir n°1 va être remplacé par un caractère dit par le vilain pirate -- ainsi de suite pour le 2è caractère, etc : autrement dit, il peut remplacer *tous* les caractères du souvenir n°1, puis tous ceux du souvenir n°2, etc, bref changer tous les souvenirs qu'il veut

du coup si ton 1er souvenir c'est "je m'appelle jul" le pirate peut le remplacer par autre chose, genre "j'aime les marmottes", ou pire, quelque chose de très cruel comme "je m'appelle jul, et il ne faut pas oublier d'envoyer une cargaison de hamsters à phil02" du coup le lendemain, tu vas te souvenir qu'il fallait faire ça et tu vas faire qqch que tu n'avais pas envie de faire ^^ (c'est un peu le principe du lavage de cerveau en fait )

mais il y a un moyen très simple d'éviter ça, c'est tout simplement de se boucher les oreilles dès qu'on atteint le 500è caractère (encore fallait-il y penser, c'est pour ça que les failles de type buffer overflow sont si répandues)

OK, merci pour vos explications!

Et, est ce que le "buffer overflow" est valable pour tous les langages informatiques? tout type de matériel? Est ce que certain systèmes d'exploitations sont soumi à plus de risque?

Le buffer overflow est une bonne specialite du C/C++/Fortran/"Langage assez bas niveau" on va dire.
En Java tu retrouves des heap overflow dans la JVM a cause de boucles infinies par exemple (je sais plus quel version de la jvm)... mais tu en auras pas directement si tu as une VM pke c elle qui s'occupe de la memoire.

Le buffer overflow est une bonne specialite du C/C++/Fortran/"Langage assez bas niveau" on va dire.

D'accord, et est ce qu'on peut dire, d'un point de vue électronique, que tout système est potentiellement "victime" de buffer overflow? Avec un langage bas niveau comme l'assembleur, il me semble que l'on controle directement le matos, on code directement sur le fer quoi. Donc est ce un problème hardware également?

tu connais le ping? et bien rien qu'avec ca on peut faire planter ton pc

Le ping d'adresse ip?
tu veux dire un truc genre :
ping 192.168.x.x ?

jul2149 (./7) :

Le buffer overflow est une bonne specialite du C/C++/Fortran/"Langage assez bas niveau" on va dire.

D'accord, et est ce qu'on peut dire, d'un point de vue électronique, que tout système est potentiellement "victime" de buffer overflow? Avec un langage bas niveau comme l'assembleur, il me semble que l'on controle directement le matos, on code directement sur le fer quoi. Donc est ce un problème hardware également?

C'est un peu plus compliqué que ça, par exemple programmer en mode "noyau" (comme le cœur du système) permet de faire plein de choses pas cool sur le matériel mais il reste des protections.
Programmer en assembleur un programme normal n'a pas ces risques (hormis faille de sécurité critique) car le système lui accorde une plage de mémoire dont il ne peut pas sortir sinon il est forcé à s'arrêter violemment, mais sans toucher au système et aux autres programmes.

mais surtout on peut dire que le buffer overflow n'est une propriété ni du matériel, ni de l'OS, ni même du langage : c'est avant tout lié au style de programmation... un programme de haut niveau genre java qui utilise des tableaux peut être victime de buffer overflows (sauf que ça ne fera pas planter le programme, mais ça reste une vulnérabilité), alors qu'un programme assembleur en mode noyau peut très bien avoir un style de programmation qui empêche complètement les buffer overflows


JackosKing> ça a rien à voir, au mieux tu peux avoir une denial of service, mais certainement pas un buffer overflow sur un système pas trop buggé ^^ (et donc c'est bcp moins grave)

C'est sur que quelqu'un qui code bien (avec notion de securite) devrait pas faire bcp de buffers overflow, mais ca n'appporte rien de dire que ca vient du style de programmation
Enfin, le coup de la vulnerabilite pour un overflow en Java, je dirais "mouais", c'est surtout pas exploitable, donc ca sert a pas grand chose de s'en preoccupe plus que d'habitude (faut quand meme checker les exceptions etc.) et c'est ce qui est fait en pratique, c'est une vulnerabilite sans impact, donc de tres faible niveau reportee pour etre corrigee "si on a le temps" ou alors si on a une politique de securite vraiment stricte.

Pollux (./11) :
mais surtout on peut dire que le buffer overflow n'est une propriété ni du matériel, ni de l'OS, ni même du langage : c'est avant tout lié au style de programmation... un programme de haut niveau genre java qui utilise des tableaux peut être victime de buffer overflows (sauf que ça ne fera pas planter le programme, mais ça reste une vulnérabilité), alors qu'un programme assembleur en mode noyau peut très bien avoir un style de programmation qui empêche complètement les buffer overflows


JackosKing> ça a rien à voir, au mieux tu peux avoir une denial of service, mais certainement pas un buffer overflow sur un système pas trop buggé ^^ (et donc c'est bcp moins grave)

Le ping de la mort, c'est quand même en plein dans le sujet , enfin d'il y a qqs années

Excusez moi de remonter le topic, mais j'ai encore une petite question:
L'autre jour, des amis parlaient de "Stack Overload". D'après ce que j'ai compris, c'est comme un buffer overflow, mais cela concerne la pile?

On peut aussi parler de stack overflow, ça marche (enfin ça plante ) de la même façon (dans certains systèmes, la pile a une taille déterminée, et si tu demandes plus qu'elle n'en a, boum (ça peut aussi arriver avec une boucle récursive trop grande, etc), dans d'autres la pile peut se redimensionner, mais bon t'es toujours limité par la taille de la mémoire de ton système d'une façon ou d'une autre).

Pollux (./11) :
un programme de haut niveau genre java qui utilise des tableaux peut être victime de buffer overflows (sauf que ça ne fera pas planter le programme, mais ça reste une vulnérabilité)

Bah ca finit par une java.lang.ArrayIndexOutOfBoundsException

et puis en général,
{stack|buffer} {overrun|overflow|overload} c'est pareil, ça représente que ton programme écrit plus haut que les bords, et la cerise qui fait déborder le vase permet d'exécuter des gateaux malicieux parfois

par contre buffer underrun, c'est l'inverse, ça veut dire que le buffer est vide (par ex si tu lis une vidéo en stream et que le réseau rame)

ExtendeD (./16) :

Pollux (./11) :
un programme de haut niveau genre java qui utilise des tableaux peut être victime de buffer overflows (sauf que ça ne fera pas planter le programme, mais ça reste une vulnérabilité)

Bah ca finit par une java.lang.ArrayIndexOutOfBoundsException

Non, je parlais du cas où on ne sort pas du tableau Java (donc pas d'exception), mais où on écrit qd même un peu plus loin que là où on devrait... Exemple extrême : un émulateur qui émule un programme victime d'un buffer overflow. Exemple plus courant :

  char[] mp3_file = readFile("dansedescanards.mp3");
  long position_id3 = findID3Tag(mp3_file);
  string infos_mp3 = readHTTP("http://plop.com/id3/infos?nom=dansedescanards");
  if (infos_mp3.contains(caractères interdits))
    throw "pas bien";
  mp3_file.copy(position_id3, infos_mp3);
  replaceFile("dansedescanards.mp3", mp3_file);

Si plop.com s'amuse à t'envoyer des infos plus grandes que la taille normale d'un ID3, pouf tu commmences à écraser le reste du fichier...
Evidemment selon le niveau où tu te places tu peux ne pas appeler ça un buffer overflow, mais ça reste fondamentalement la même chose et dans tous les cas c'est une vulnérabilité ^^

Ah ok

Pile = (SP)?

Stack Pointer, l'adresse du bas de la pile (on en pile par le bas).

(SP) représente le contenu du sommet de la pile.
SP représente son adresse.

bref, le registre qui contient son adresse

Ok,merci pour vos réponses.

./18

Le mp3 va pas 'grandir' pour pouvoir stocker toutes les données voulant être entrées dans le tag ?

les tags ID3 v1 étaient de taille fixe, si j'ai bonne mémoire.
(si un tag faisait 100 octets, il fait toujours 100 octets dans le fichier, qu'il y ait 10 cdaractères => 90 octets de perdus, ou 120 => overflow de 20 octets)

ExtendeD (./21) :
Stack Pointer, l'adresse du bas de la pile (on en pile par le bas).

ça depend des piles...

le 6502 c'est plutot l'inverse (la piles est forcement en 0x01xx et on commence a 0x1FF et on empile en decrementant)