Discussion :

[shlagable]

Bonjour,

Je me suis récemment amusé à essayer le buffer overflow à l'aide d'un cours assez complet que j'ai trouvé sur internet, mais je rencontre, dès le premier programme présenté en exemple, un problème.
Voici le programme:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
#include <stdio.h>
//#include <string.h>
 
main (int argc, char *argv[])
{
	char buffer [256];
	if (argc>1)
		strcpy(buffer, argv[1]);
 
return (0);
 
}

Après quelques recherches, il semble que c'est vraiment l'exemple de base pour débuter, mais seulement, il ne fonctionne pas vraiment...
Déja, j'ai ajouté l'include string.h qui n'était pas et j'ai essayé avec et sans, ce qui ne change rien au résultat.
La compilation se déroule sans problème (heuresement...) et lors de l'execution, il ne se passe rien. seulement, lorsque je tape:

Code :

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

1
2
 
./vuln1 `perl -e 'print "A"x300'`

J'obtient comme réponse:

Code :

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

1
2
3
4
5
6
7
 
****stack smashing detected*****
====bactrace: ======
des trucs
====memory map ====
d'autres trucs (les adresses et les droits)
Abandon (core dumped)

Alors que j'attends segmentation fault.
et quand je regarde le core dump, il confirme bien programm terminated with signal 6, Aborted
au lieu de signal 11, Segmentation fault.
Comme mon cours date de 2002 j'imagine que gcc a depuis été mis à jour pour protéger ce genre de bug, mais j'aimerais bien avoir confirmation et si possible savoir si il y a moyen de contourner ça (par exemple, compiler sans cette protection)

Une autre question me vient: pour faire quelque chose du buffer overflow, il faut compiler un exploit, dans lequel on insère un shellcode, est ce que quelqu'un pourrait m'éclairer sur ce qu'est précisément un shellcode
Je précise que je suis sous Ubuntu processeur x86

Merci d'avance

[Obsidian]

Hello,

Dans le programme que tu nous montres, le buffer est large de 256 caractères. Ça veut dire qu'il faut que l'argument que tu passes en ligne de commande soit plus long que cette taille pour que cela provoque un crash. C'est pourquoi tu passes la commande Perl que tu nous montres. Ça, ok.

Lorsque tu utilises la commande Perl en question, tu dépasses donc la taille du tableau. Et ce tableau est déclaré… dans la pile ! Ce qu'il y a, c'est que cette pile est déclarée dans l'espace mémoire du processus, et qu'elle n'est pas vide. Elle contient toutes les autres variables locales lorsqu'il y a en a, mais aussi les cadres de pile, la sauvegarde des différents registres (notamment EBP).

« stack smashing » signifie littéralement « écrasement de pile ». Le pointeur de pile pointe par défaut la fin du segment de mémoire allouée à cette pile (donc l'adresse la plus grande) et est décrémenté à chaque fois que tu empiles un élément. Donc, en dépassant la fin d'un tableau, tu vas écraser ce qui a été précédement empilé.

Donc, concrètement, tu ne sors pas de l'espace mémoire alloué entièrement au processus, ce qui fait que le micro-processeur lui-même ne va pas aller déclencher d'exception, et donc la segfault ne se produit pas. Par contre, au retour, c'est la libC qui constate les dégats et qui te dit « Oh la la, mais qu'est-ce qui s'est passé ici ? ».

Tu peux utiliser le code suivant qui doit bien fonctionner sur une architecture 32 bits :

Code C :

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

1
2
3
4
5
6
7
8
9
10
11
12
#include <stdio.h>
 
int main (int argc,char ** argv)
{
    int x = 0;
    char buffer [4] = { 0 };
 
    if (argc>1) strcpy (buffer,argv[1]);
 
    printf("%x\n",x);
    return 0;
}

Appelle ensuite ce programme avec ./programme a, puis ./programme ab, puis ./programme abc, puis ./programme abcd, etc.

La valeur retournée va être systématiquement 0 jusqu'à l'argument atteigne la « variable précédemment déclarée dans la pile », donc x, et le little endianness sur PC fera que l'octet déposé le sera dans le moins significatif de ta variable.

Donc, la première valeur affichée différente de zéro sera le code ASCII de la lettre concernée, en hexadécimal.

Une autre question me vient: pour faire quelque chose du buffer overflow, il faut compiler un exploit, dans lequel on insère un shellcode, est ce que quelqu'un pourrait m'éclairer sur ce qu'est précisément un shellcode
Je précise que je suis sous Ubuntu processeur x86

Wikipédia en donne la définition : http://fr.wikipedia.org/wiki/Shellcode

Donc, il s'agit d'un bout de code minimaliste donc la seule fonction est d'ouvrir à l'attaquant un shell root à partir duquel il peut ensuite faire ce qu'il veut. Il est très difficile aujourd'hui de parvenir à ses fins de cette façon. L'idée générale était d'écrire un texte suffisamment long pour dépasser la zone de données et atteindre carrément la zone de code, dans laquelle on déposait des valeurs choisies, qui ensuite étaient tout bonnement exécutées par le processeur qui ne se doutait de rien.

Il n'est plus possible de faire cela en l'état actuel des choses sur PC car les segments de code et de données sont distincts, et qu'une segfault surviendra avant. Par contre, il est tout-à-fait possible de faire des choses très similaires, surtout avec les scripts web, en PHP notamment, donc il faut impérativement et systématiquement « assainir » les entrées.

Ça a donné lieu à « Exploits of a mom » (Little Boby Tables) de XKCD qui a bien fait rire tout le monde, mais aussi à certains effets de bords, comme des programmes-dæmons lancés en root (classique) mais qui donnait à l'utilisateur la possibilité d'ajouter une ligne quelconque dans le log de leur choix. Je ne développerai volontairement pas.

[D[r]eadLock]

Comme mon cours date de 2002 j'imagine que gcc a depuis été mis à jour pour protéger ce genre de bug, mais j'aimerais bien avoir confirmation et si possible savoir si il y a moyen de contourner ça (par exemple, compiler sans cette protection)

À priori il faut passer -fno-stack-protector à gcc (un peu d'info pour Ubuntu: https://wiki.ubuntu.com/CompilerFlags)

[Trankille]

tu as un blog qui explique tout très bien..
il évoque aussi les commandes à passer pour enlever la protection de gcc.

http://www.time0ut.org/blog/

pour les vulnérabilités, c'est vrai qu'elles sont de plus en plus complexes à exploiter... mais il en existe toujours et encore beaucoup dans le noyau Linux. Comme tu peux le voir ici:

securité de linux