Eviter les dépassements de pile

Bonjour,

Dans le but d'améliorer le programme que je suis entrain d'écrire, je voudrais d'abord comprendre ce que c'est un dépassement.
Pour cela, j'ai écrit un petit code sous Code::Blocks (compilateur GCC)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#include <string.h> #include <stdio.h>   void test(const char* buf) { char buffer[10]; strcpy(buffer, buf); }   int main() { char str[100]; gets(str); test(str); printf("C'est fini !!"); return 0; }

---

J'entre un texte sur str de
- longueur 11 (puisque buffer[10] donc dépassement), aucun problème, le printf s'affiche
- longueur 27, le printf s'affiche
- longueur 28, c'est là que le programme crashe, POURQUOI SI LOIN?

Il semble que GCC possède aussi une protection contre cela (stack error) à la compilation, comment ? Merci d'avance

Ne pas confondre buffer overflow et stack overflow.

Une solution pour ne pas avoir de buffer overflow, c'est de ne pas coder en C mais en C++, en favorisant l'utilisation d'objets qui maintiennent des invariants et font des assertions en mode de débogage.

Citation:

---

POURQUOI SI LOIN?

---

Invoquer un comportement indéfini ne veut pas dire que ça va forcément crasher de suite, c'est même pire puisque tu peux silencieusement corrompre ton code.

Et bien, vous vous trompez: les dépassements sont souvent détectés en C aussi bien qu'en C++ (on peut encore utiliser strcpy et sprintf)
Ce bout de code que j'ai montré est en C++

Ce que je ne comprend pas c'est que la fonction n'a qu'un "char buffer[10]" comme variable locale donc un espace de 10 octets dans la pile après l'adresse de retour, normalement si j'entre un tableau de [11], ça doit crasher non?

Citation:

---

Envoyé par bruce-willis

Ce que je ne comprend pas c'est que la fonction n'a qu'un "char buffer[10]" comme variable locale donc un espace de 10 octets dans la pile après l'adresse de retour, normalement si j'entre un tableau de [11], ça doit crasher non?

---

Pas forcément.

Par exemple, si tu as :

Code:

---

1 2	char buffer[10]; unsigned long value;

---

Ces 2 variables seront sur la pile mais le compilateur va probablement faire un alignement de frontière de manière à ce que la variable 'value' soit sur une adresse multiple de 4. Donc tu te retrouveras probablement avec un trou de 2 octets inutilisé entre buffer[10] et 'value'. Si tu fais buffer[10] = 0, tu vas taper dans ce trou, cela ne gênera personne par contre, si tu fais buffer[12]=0, tu va aller taper dans la variable 'value' et laà cela peut partir en live avec un comportement indterminé (rien de notable, crash, formattage du disque, démarrage de ta cafetière, ...)

Le plus flagrant pour les dépassements de pile est d'utiliser les pointeurs en C ou en C++. Rares doivent être les compilateurs qui peuvent détectés le problème.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#include <stdio.h>   int main() { char buf[10]; for(int i=0; i<100; i++) { *(buf+i) = i; // Au delà de 9 on écrit n'importe où } return 0; }

---

Il y a d'ailleurs du très bon cours sur ce site pour leur exploitation http://david-gross.developpez.com/tu...ffer-overflow/

Citation:

---

Envoyé par ram-0000

Par exemple, si tu as :

Code:

---

1 2	char buffer[10]; unsigned long value;

---

Ces 2 variables seront sur la pile mais le compilateur va probablement faire un alignement de frontière de manière à ce que la variable 'value' soit sur une adresse multiple de 4. Donc tu te retrouveras probablement avec un trou de 2 octets inutilisé entre buffer[10] et 'value'. Si tu fais buffer[10] = 0, tu vas taper dans ce trou, cela ne gênera personne par contre, si tu fais buffer[12]=0, tu va aller taper dans la variable 'value' et laà cela peut partir en live avec un comportement indterminé (rien de notable, crash, formattage du disque, démarrage de ta cafetière, ...)

---

Je ne comprend toujours pas la façon dont les variables sont rangées en STACK (pile)!! Pour cet exemple, buffer[10] au top suivi de value suivi de l'adresse de retour non??? Donc, un tableau de taille 10+sizeof(value)+4 doit écraser la valeur de retour?

Citation:

---

Envoyé par bruce-willis

Je ne comprend toujours pas la façon dont les variables sont rangées en STACK (pile)!! Pour cet exemple, buffer[10] au top suivi de value suivi de l'adresse de retour non??? Donc, un tableau de taille 10+sizeof(value)+4 doit écraser la valeur de retour?

---

En reprenant mon exemple et en admettant que ce que j'ai dit sur l'alignement soit vrai (c'est probablement vrai)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

0X0000     ..... buffer[0] buffer[1] buffer[2] buffer[3] buffer[4] buffer[5] buffer[6] buffer[7] buffer[8] buffer[9] not used not used value (byte1) value (byte2) value (byte3) value (byte4) adresse de retour de la fonction (byte1) adresse de retour de la fonction (byte2) adresse de retour de la fonction (byte3) adresse de retour de la fonction (byte4) .....     0Xffff

---

Les valeurs sur la pile sont ajoutées dans le sens descendant (donc de 0Xffff vers 0x0000). Le sens d'écriture dans la pile va donc de bas en haut (sur mon schéma)
Sur cette pile, on va trouver l'adresse de retour de la fonction (empilée par le call à la fonction) et les variables locales donc buffer[10] sur 10 octets et 'value' sur 4 octets. Comme 'value' doit être aligné sur 1 frontière multiple de 4 (pour des raisons de performance d'accès à la variable), il y aura un trou de 2 octets entre 'buffer' et 'value' pour faire cet alignement.

Donc si on écrit en buffer[10], on va taper dans le trou, c'est pas encore très grave pour la santé du programme, si on écrit en buffer[12], on va taper dans 'value' (là, cela peut provoquer un comportement bizarre) et si on écrit en buffer[16], on va taper dans l'adresse de retour de la fonction (et là en général, le programme ne s'en remet pas).

L'exemple présenté ici est ultra simplifié (en fait plus de choses que cela sont empilées sur la pile lors d'un appel de fonction) mais le principe reste le même.

Citation:

---

Envoyé par bruce-willis

Ce bout de code que j'ai montré est en C++

---

C'est peut-être du C++ valide, mais ce n'est pas du C++ typique. Et une grande partie de l'apport du C++ par rapport au C est justement de permettre la mise en place de techniques permettant d'éviter sans efforts une grande partie des causes de ce genre de dépassement.

Citation:

---

Envoyé par ram-0000

Donc si on écrit en buffer[10], on va taper dans le trou, c'est pas encore très grave pour la santé du programme, si on écrit en buffer[12], on va taper dans 'value' (là, cela peut provoquer un comportement bizarre) et si on écrit en buffer[16], on va taper dans l'adresse de retour de la fonction (et là en général, le programme ne s'en remet pas).

---

D'accord, mais avec ma fonction test(), pourquoi c'est à buffer[28] que cela crashe?

La réponse de principe t'a été donnée par ram-000 et JolyLoic.
Pourquoi dans ton cas faut-il aller jusqu'à 28?: regarde le code ASM généré et tu verra où tu commence à charcuter quand tu débordes, et pourquoi au début, les conséquences ne sont pas immédiatement visibles.

Déjà, en C, si les gens apprenaient à ne pas utiliser gets(), on lutterait plus contre les buffer overflow...
Et si les profs apprenaient à ne pas dire aux élèves d'utiliser gets() :roll:

Note: Je connais un moyen d'utiliser gets() sans risque, mais:

1. C'est inutilement compliqué, j'ai fait ça pour m'amuser
2. Ça utilise des fonctions de gestion de mémoire spécifiques à Windows, et aucun équivalent standard n'existe.

Citation:

---

Envoyé par bruce-willis

D'accord, mais avec ma fonction test(), pourquoi c'est à buffer[28] que cela crashe?

---

De toute façon, en cas de débordement de buffer, le comportement est indéfini. Dans ce cas, tout peut arriver et même son contraire. Dans ton exemple, cela cracher à l'indice 28 et peut être que demain cela sera 32, c'est indéfini et c'est les joies de ce genre de bug :P.

Citation:

---

Envoyé par ram-0000

De toute façon, en cas de débordement de buffer, le comportement est indéfini.

---

Le comportement indéfini oui mais le débordement non! C'est à dire je sais à quand l'écrasement de l'adresse de retour de fonction. Ce qui diffère beaucoup d'un compilateur à l'autre, ce cas de 28, c'est avec C::B mais sous VISUAL C++ 6, ça commence dès le buffer[12] mais bon, je vais étudier le désassemblage de ce petit code

le compilateur utilise la pile comme il veut. Il peut se dire qu'il a besoin de plus d'espace temporaire si tes registres de travail ne tiennent pas en mémoire, il peut créer des temporaires pour les réutiliser, bref, il fait ce qu'il veut.

sur la pile il n'y a pas que l'adresse de retour, le compilateur a sans doute générer une instruction pusha pour sauver les registres, etc etc. il n'y a aucun document qui dit que lorsque tu smashes la pile tu ecris sur l'adresse de retour. d'ailleurs sur certaines architectures la pile va dans l'autre sens.

Citation:

---

Envoyé par bruce-willis

Le comportement indéfini oui mais le débordement non!

---

Comportement indéfini ou indéterminé : dont on ne peut prévoir le résultat. Donc, ça peut marcher ou pas. Un peu comme le chat de Schrödinger :aie:
Il faut bien comprendre qu'à partir du moment où c'est indéfini, le comportement va varier en fonction du compilateur, de la machine sur laquelle le programme est exécuté, de la météo, de l'age du capitaine etc... C'est indéfini

Je me rend compte que le terme INDEFINI est très utilisé dans ce fil
Mais ce n'est pas indéfini, pas du tout avec le compilateur de Visual C++ (Delphi/C++ Builder, etc.): quand c'est 28, c'est toujours 28 pour ce code (en fait c'est de buffer[16] à buffer[19] que les 32 bits de l'adresse de retour sont écrasés; on parle là de ce code du poste #1 sur un compilateur mais pas sur tous les compilateurs
Le désassemblage au débogage du programme peut prouver cela, le code asm correspondant reste le même et on y voit bien les "PUSH", "POP", "RET", "MOV EBP,ESP" ! => Il semble que l'overflow simple par écrasement de EIP à la fin d'une fonction n'est pas possible à partir de VS2003, il y a une fonction de test de STACK appelée avant RET

Conventions sous Microsoft Visual C++ (fr)
http://support.microsoft.com/kb/100832/fr

Tu oublies que l'optimiseur est libre d'inliner les appels de fonction et d'utiliser ses propres conventions d'appel quand c'est approprié.

Cela se produit typiquement lors de l'appel de fonctions static au sein d'un même fichier source, mais cela peut aussi être fait à un niveau plus global si des options d'optimisation poussées (Whole Program Optimization, Link-Time Code Generation) sont activées.

De plus, même avec des conventions fixes pour les paramètres, l'organisation des variables locales est bel et bien indéfinie. Notamment, on peut voir que les bricolages rigolos de MinGW n'ont rien à voir avec l'organisation de Visual, par exemple...

Citation:

---

Envoyé par Médinoc

Tu oublies que l'optimiseur est libre d'inliner les appels de fonction et d'utiliser ses propres conventions d'appel quand c'est approprié.

Cela se produit typiquement lors de l'appel de fonctions static au sein d'un même fichier source, mais cela peut aussi être fait à un niveau plus global si des options d'optimisation poussées (Whole Program Optimization, Link-Time Code Generation) sont activées.

De plus, même avec des conventions fixes pour les paramètres, l'organisation des variables locales est bel et bien indéfinie. Notamment, on peut voir que les bricolages rigolos de MinGW n'ont rien à voir avec l'organisation de Visual, par exemple...

---

+++
La norme dit que le comportement est indéfini. Cela veut dire que tu ne sais dire en lisant le code quel sera le résultat. Une fois le code généré par le compilateur et que tu as un code binaire, là oui, tu peux prévoir. Mais, ce n'est plus du ressort du C++. Il s'agit bien de comprendre que le comportement est indéfini du point de vue du langage C++.

Mais bon, pour Visual Studio 2003 et plus, le paramètre /GS (par défaut) permet de vérifier l'état du stack avant le retour d'une fonction. Donc, le risque de STACK OVERFLOW est presque nul aujourd'hui (les HEAP OVERFLOW plutôt difficile à exploiter)!!! Ces failles sur les tampons d'aujourd'hui ne sont plus que des erreurs de certaines bibliothèques: en effet, même si on fait très attention à nos codes et on importe un fichier LIB par ex, on ne sait pas s'il y a une faille dedans