UN BUFFEROVERRUN : LE DÉBORDEMENT DE PILE , Source N°20666

Information sur la source

Catégorie :Sécurité & Cryptage Niveau : Initié Date de création : 21/02/2004 Vu / téléchargé: 3 666 / 301

Auteur : vieuxLion

Ecrire un message privé

Note :

10,00 / 10

1
2
3
4
5
6
7
8
9
10

Commentaire sur cette source (7)

Ajouter un commentaire et/ou une note

Description

Cliquez pour voir la capture en taille normale

Soit un programme mal écrit, qui ne se protège pas contre les débordements de pile.
On va successivement voir comment ce programme :

I) Peut planter

II) Peut exécuter du code spécifié par l'utilisateur

III) Pourrait être corrigé

IV) Peut encore être « patché »

V) Devrait enfin utiliser l'option /GS du compilateur de VS7 ou équivalent pour d'autres compilateurs

Source

le point de départ est ce petit code :
void MalEcrite(const char* entree)
{
char buf[10];// ce buffer est limité à 10 caractères, soient 9 utiles !
//copions tout ce qui se présente sans contrôle ... copieusement quoi !
strcpy(buf, input);
printf("voici mon buffer :\n%s\n\n", buf);
}

le point de départ est ce petit code :
void MalEcrite(const char* entree)
{
  char buf[10];// ce buffer est limité à 10 caractères, soient 9 utiles !
  //copions tout ce qui se présente sans contrôle ... copieusement quoi !
  strcpy(buf, input);
  printf("voici mon buffer :\n%s\n\n", buf);
}

Conclusion

Cet article est dans la catégorie Sécurité.
Pour nous simplifier la compréhension, bien respecter les principes suivants :
1) le code sera compilé sans les nouvelles options de sécurité du compilateur Visual Studio .NET
2) nous allons utiliser une version "Release" sans optimisation de code
3) nous allons afficher les adresses utiles pour mieux pouvoir les introduire en entrée.

Fichier Zip

Pour les "Membres Club", vous pouvez télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Release
- 01_normal.pl77 octets
- 01_normal.vbs 145 octets
- 02-bufferTropLong.pl88 octets
- 02-bufferTropLong.vbs 156 octets
- 03_execSortie.vbs 188 octets
- 03-execSortie.pl99 octets
BufferOverRun.PDF401 222 octets
BufferOverRun.sln 915 octets
BufferOverRun.suo8 704 octets
BufferOverRun.vcproj3 470 octets
DepassementPile1.cpp 1 565 octets
DepassementPile2.cpp 2 067 octets

Télécharger le zip

Sources du même auteur

Toutes les sources de vieuxLion

Sources de la même categorie

Toutes les sources de la catégorie Sécurité & Cryptage

Commentaires

Commentaire de Xs le 22/02/2004 12:27:07

Salut !!

Excellente source pour comprendre le fonctionnement de la pile sans faire appel a un desasm !

Mais j'ai personnellement du modifié la ligne de 03_execsortie.vbs "arg" par une a moi :

arg = "123456789123" & chr(&h50) & chr(&h10) & chr(&h40)

La ca "marche bien". J'ai juste remarqué que comparéé à la "phrase" originale, il y avait 3 caracteres en moins (4,5,6).
J'avoue ne pas trop comprendre pourquoi ce sont les carateres 4,5,6 qui prennent la place de EIP et non 7,8,9

Pouquoi ?

merci
Commentaire de vieuxLion le 22/02/2004 14:30:02

j'obtiens des résultats corrects pour VC++6 et VC++7
Options d'optimisations "disabled"
quel compilateur utilise tu?
Commentaire de Xs le 22/02/2004 15:15:42

J'utilise VC++ SP5 avec le processor pack installé sous win2k sp5(ntfs)
Lors de mon premier message, mes options d'optimisations étaient sur "maximize speed".

A présent, j'ai coché "disable (debug)" ("défaut" ne me donne rien).
Et la j'ai du faire d'autres modifications dans le fichier 03....vbs :

arg = "123456789123456" & chr(&h50) & chr(&h10) & chr(&h40)
passe a
arg = "1234567891234567" & chr(&h45) & chr(&h10) & chr(&h40)

=> adresse de Sortie a changée.

J'avoue ne pas comprendre le pourquoi du comment de ces changements.

Sinon, une question me tracasse :
- Pourquoi l'adresse de Sortie() est-elle censé etre la meme partout (avec les memes options de compil' elle est identique sur tous les pcs fonctionnant sous win32) ?

merci
Commentaire de h4x0r le 13/03/2004 18:19:35

bon maintenant il rest juste a faire un exploit ;)
moi g un ti problem avec le mien je fait pointer EIP vers ESP mais je recois toujours une erreure de BO et il execute pas mon shell-code

#include <stdio.h>
#define BUFFSIZE 32

char shellcode[]="\x90\x90";
char ret[]="\x46\x12\x40";

int main(int argc, char *argv[])
{
char buffer[70];
int len,i,size,retlen,SIZE;
size = strlen(shellcode);
len = BUFFSIZE - size;
retlen = strlen(ret);

for(i=0;i<=len;i++){
buffer[i] = '\x90';
}

for(i=0;i<=size;i++){
buffer[i + len] = shellcode[i];
}
for(i=0;i<=4;i++){
buffer[i + len + size] = '\x90' ;
}

for(i=0;i<=4;i++){
buffer[i + len + size + 4] = ret[i];
}

printf("%s",buffer);

getchar();
return 0;
}
bon ok g changer mon shell-code pour des NOPs mais bon ca ne marche pas quand meme ....helpp
Commentaire de h4x0r le 13/03/2004 18:31:47

ton buf peut contenir 16 caractere car le processeur travail avec des MOTS, enfin... petit detail....a +
Commentaire de h4x0r le 12/04/2004 00:22:02

g trouver mon erreur.. EIP doit pointer vers EBP au crash time... enfin
Commentaire de algori le 23/06/2006 14:19:00

excellente source. J'ai appris plein de choses