Discussion :

[arcanum28]

hello

alors voila ca fais un ptit bout d'temps que je code en langage C,
et j'essai de comprendre le principe du buffer overflow.

j'ai comprit que rsa (prochaine adresse de eip) se situais au dessus (en mémoire) de chaque fonction dans la pile

j'ai donc prit comme point de repère ma variable int i pour l'adresse de retour répéter (car les adresse sont décaler avec des bit de bourrage par mesure de sécurité) qui sera écraser par mon nop sled (qui dérivera sur mon shellcode)

pour ca j'ai fais déborder mon pointer buffer (nop/shell/adr_ret)

pour ca j'ai décider de faire simple et d'exécuter tout ca dans une fonction que mon main appellera, seulement voila... mon premier code ne compile pas mon 2 eme non plus et mon 3 eme me tape un segmentation fault (en plus d'être très moche...)

aurais-je mal comprit quelque chose ?
appliquerais-je mal la théorie a la pratique ?
y-aurais t'il des amélioration possible ? (ou imaginable^^)

bref ^^ trop de question me passe par la tête et j'ai beau lire et relire des
tuto sur les overflow je ne trouve pas...
merci quand même google...
et quand mon code compile je me tape un seg fault...
je précise que je suis sur un mac osx 64 bit


mon premier code de test (dsl d'avance ^^)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
unsigned long stack_pointer()
{
	__asm__("movl %esp, %eax");
}
 
int fonction()
{
	int i, y, compt, adr_ret, offset;
        char ptr;
 
	adr_ret = stack_pointer;
	adr_ret -= offset;
	y = 0;
	compt = 0;
	i = 0;
	char *buffer;
 
	buffer = malloc(109);
 
	ptr = buffer;
	char *shellcode =
		"\x41\xb0\x02\x49\xc1\xe0\x18\x49\x83\xc8\x17\x31\xff\x4c\x89\xc0"
		"\x0f\x05\xeb\x12\x5f\x49\x83\xc0\x24\x4c\x89\xc0\x48\x31\xd2\x52"
		"\x57\x48\x89\xe6\x0f\x05\xe8\xe9\xff\xff\xff\x2f\x62\x69\x6e\x2f"
		"\x2f\x73\x68";
 
	while(y < 30)
	{
		*(ptr++) =
		y++;
	}
 
/*	while (i < 30)
	{
		buffer[i] = '\x90';
		i++;
	}
*/
 
		  y = 0;
	while (y < strlen(shellcode))
	{
		*(ptr++) = shellcode[i];
		y++;
	}
 
 
	while (compt < 130)
	{
		ptr = (buffer[i] + strlen(shellcode) + compt);
		*(ptr) = &buffer;
		compt++;
	}
	return 0;
}

mon 2 eme code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
30
31
32
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
char shellcode[] =
"\x31\xc0\x31\xdb\x31\xc9\x99\xb0\xa4\xcd\x80\x6a\x0b\x58\x51\x68"
"\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe2\x51\x89\xe2\x53\x89"
"\xe1\xcd\x80";
 
int fonction()
{
    int i, *ptr, ret, offset, size_sh;
    char *command, *buffer;
 
    buffer = (char*) &i;
 
    //size_sh = strlen(shellcode);
    offset = (char**)&i - &buffer;
 
    printf("%d\n", offset);
 
    system("PAUSE");
 
    ret = &i - offset;
 
    for (i=0;i<160;i+=4)//addr retour dans tampon
        *((int*)(buffer+i)) = ret;
    memset(buffer, 0x90, 60); //nope sled
    memcpy(buffer+60, shellcode, sizeof(shellcode)-1);
 
    return 0;
}

et voici mon 3 eme code (en cours de rerererereremodifications donc/et vraiment moche en plus d'être incomplet...)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
30
31
32
33
34
35
36
37
38
39
40
41
#include <stdio.h>
#include <stdlib.h>
#include <string.h>0
 
int fonction()
{
    char *i, *buffer, *buffer2;
    int j;
    char    *shellcode =     
    "\x41\xb0\x02\x49\xc1\xe0\x18\x49\x83\xc8\x17\x31\xff\x4c\x89\xc0\x0f\x05\xeb\x12\x5f\x49"
    "\x83\xc0\x24\x4c\x89\xc0\x48\x31\xd2\x52\x57\x48\x89\xe6\x0f\x05\xe8\xe9\xff\xff\xff\x2f"
    "\x62\x69\x6e\x2f\x2f\x73\x68";
 
 
    i = (char *) &i;
 
    printf("%p ",&i);
    printf("%d,", *i);
 
    buffer = i;
 
    printf("%p ",i);
 
    j = strlen(shellcode);
    buffer2 = i;
 
    //addr retour dans tampon
        buffer2++;
 
    printf("%d ",k++);
 
    memset((void *)buffer, 0x90, 40); //nope sled
 
    printf("%d ",k++);
 
    memcpy((void *)(buffer+40), shellcode, sizeof(shellcode)-1);
 
    printf("%d ",k++);
 
    return 0;
}

[Obsidian]

Bonjour et bienvenue,

J'ai beaucoup de mal à comprendre où tu veux en venir.

« overflow » signifie débordement en anglais. Un « buffer overflow », c'est un dépassement de tampon. En C et en assembleur, les objets ne sont pas managés : lorsque tu déclares un buffer de n octets, tu indiques au compilateur que tu réserves cette place en mémoire. Si, derrière, tu écris un code qui dépasse les limites de cet espace, rien ne l'empêchera a priori de continuer et, donc, d'écraser tout ce qui se trouve à côté.

Jusqu'à une époque relativement récente (jusqu'au milieu des années 1990) code et données cohabitaient dans la même mémoire et rien n'empêchait cela d'arriver si ce n'est la vigilance du programmeur. Ça a commencé à devenir un vrai problème lorsque le multitâche s'est démocratisé sur les machines grand public. Les micro-processeurs de la scène ont alors commencé à proposer le mode protégé qui permet au système d'allouer à la base un segment de mémoire défini et faire en sorte que ce soit le micro-processeur lui-même qui refuse de continuer si on lui demande de travailler dans une zone qui sort de ce segment, déclenchant alors la fameuse « segfault ».

De cette manière, on est sûr qu'un programme défectueux n'ira pas compromettre le système, ni les applications qui tournent à côté. Par contre, rien ne peux l'empêcher de s'auto-détruire s'il en a envie. Par contre, tant qu'il ne fait qu'écrire dans ses propres données, il ne se passera rien, et tu ne t'apercevra pas que ton programme est défectueux. C'est pour cela que les buffer overflows sont insidieux et parfois difficiles à débuguer.

Maintenant, je ne sais pas ce que tu veux faire avec ton shell code mais il semble que tu cherches à faire de l'injection de code en profitant de la faille. Ça se faisait à l'époque mais c'est devenu impossible, principalement parce que le micro-processeur utilise aujourd'hui deux segments distincts : un pour le code et un pour les données. Les offsets des différentes ressources sont relatifs à leur point de départ et même si tu obtiens deux adresses identiques pour le code et les données, elles correspondront quand même à des zones distinctes en mémoire. En outre, ces segments disposent généralement de flags « x » qui permettent d'autoriser ou interdire l'exécution de code dans ledit segment.

Il est donc impossible d'exécuter ce code en l'état sans exploiter une autre faille dans le programme te permettant de gagner les privilèges permettant d'invoquer les appels système nécessaires.

[arcanum28]

ok j'ai bien compris ton message
merci pour cette hélant de lumière dans les sombres entrailles des systèmes ^^
et désolé du temps de réponse étais bien occuper ce début de week-end

[Médinoc]

@Obsidian: Le coup des segments différents, c'était vrai à l'époque 16 bits; en 32 bits, on utilise un modèle mémoire plat (comparable à modèle "tiny" géant).

De nos jours, les choses qui servent à empêcher une injection de code par buffer overflow, sont:

• l'Address Space Layout Randomization (ASLR) qui met les différentes bibliothèques à des adresses aléatoires, pour contrecarrer les injections de code contenant des adresses hard-codées
• la Prévention de l'Exécution des Données (DEP) qui permet d'empêcher le processeur d'exécuter des instructions dans les pages mémoire qui ne sont pas censées contenir du code (comme la pile).
• la détection de buffer overflow par cookie: une valeur placée dans la pile entre les variables locales et l'adresse de retour; l'épilogue de la fonction vérifie que cette valeur n'a pas été modifiée avant de faire le ret.

[grim7reaper]

la détection de buffer overflow par cookie

Ça se dit ça ?
J’ai toujours entendu parler de valeur canari (en référence aux mines de charbon), mais jamais de cookie.

[Metalman]

Cookie et Canari sont employés tous les deux indifféremment !

"Cookie de Sécurité" parfois aussi...

[grim7reaper]

Cookie et Canari sont employés tous les deux indifféremment !

En effet.
Je n’avais jamais rencontré ce terme mais il semble être aussi utilisé (bien que moins fréquemment on dirait).

[Médinoc]

On dit peut-être canari en Français (je ne sais pas, je n'ai pas lu d'article en Français là-dessus), mais sur les sources Anglophones comme MSDN, on parle toujours de "cookie".

↓Ah, OK.

[grim7reaper]

On dit peut-être canari en Français (je ne sais pas, je n'ai pas lu d'article en Français là-dessus), mais sur les sources Anglophones comme MSDN, on parle toujours de "cookie".

Ça dépends des sources alors.
Exemple ici, là, là-bas et encore là.

Dans toutes les ressources anglophones que j’ai lu (mais je n’ai jamais consulté MSDN et ils semblent effectivement utiliser ce terme) c’était toujours canari (canary donc) qui revenait.

Donc non, c’est clairement pas un truc francophone… Comme toi je n’ai jamais lu de document en français à ce sujet.

[orfix]

Si j'ai bien compris tu cherches à écraser l'adresse de retour au sein d'une fonction pour exécuter ton shell code, si c'est bien ça, jette un coup d'œil sur ce code que j'avais écrit dans le temps (sous GNU/Linux), ce n'est pas vraiment compliqué:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#include <stdlib.h>
 
char sysCall_exit[]= "\xB8\x01\x00\x00\x00" /* mov eax,1  ; sys_exit de kernel/exit.c              */	
                     "\xBB\x05\x00\x00\x00" /* mov ebx,5  ; code d'erreur 5 choisis arbitrairement */
                     "\xCD\x80";            /* int 80h    ; appel système                          */
void foo( void )
{
    size_t *ret = (size_t *)(&ret + 2);
    *ret = (size_t)sysCall_exit;
}
 
int main (void)
{
    foo();
 
    return 0;
}