j'ai dernièrement entendu parler de Make et d'une potentielle brèche, certains disent que c'est pas encore vérifié.
Donc j'ai pas hésité une seconde ! Je devais vérifier çà ! J'ai fais mes test sur Make 3.81 sur les architectures X86,x64
sur les distributions Arch, Fedora, Debian, Ubuntu.Je vais reprendre certaines partie du Poc publié sur Exploit-Db
On peut commencer par se faire une idée des protections sur le bin MAKE avec Checksec (https://github.com/slimm609/checksec.sh).
©t.vivien
### 32 bits ###
RELRO STACK CANARY NX PIE RPATH RUNPATH FILE
No RELRO No canary found NX enabled No PIE No RPATH No RUNPATH make
### 64 bits ###
RELRO STACK CANARY NX PIE RPATH RUNPATH FILE
No RELRO No canary found NX enabled No PIE No RPATH No RUNPATH make
On pourras effectivement s'étonner d'une protection aussi faible pour un binaire pouvant compiler tout les programmes sur un système linux.
Je vous passe les détails de la recherche fastidieuse du Segfault et j'en viens à l'essentiel.
Le Seg Fault se trouve : à 4096 octets plus l'offset de retour 4 octets soit 4100. Voici un aperçu
Overflow Code :
40cc59: 74 10 je 40cc6b <__ctype_b_loc@plt+0xa52b>
40cc5b: 0f 1f 44 00 00 nop DWORD PTR [rax+rax*1+0x0]
40cc60: 48 89 c3 mov rbx,rax
40cc63: 48 8b 00 mov rax,QWORD PTR [rax] // heap overflow
Program received signal SIGSEGV, Segmentation fault.
[----------------------------------registers-----------------------------------]
RAX: 0xdeadbeefdeadbeef
RBX: 0xdeadbeefdeadbeef
RCX: 0x4242424242424242 ('BBBBBBBB')
RDX: 0x0
RSI: 0x7fffffff97d0 ('A' <repeats 200 times>...)
RDI: 0x7fffffffa7e2 --> 0x732e656c69666500 ('')
RBP: 0x7fffffffb930 --> 0x1
RSP: 0x7fffffff95f0 --> 0x0
RIP: 0x40cc63 (mov rax,QWORD PTR [rax])
R8 : 0x4242424242424242 ('BBBBBBBB')
R9 : 0x7ffff7972440 (mov dx,WORD PTR [rsi-0x2])
R10: 0x4242424242424242 ('BBBBBBBB')
R11: 0x7ffff799f990 --> 0xfffd28d0fffd2708
R12: 0x1
R13: 0x0
R14: 0x6397a0 --> 0x6f2e25 ('%.o')
R15: 0x0
EFLAGS: 0x10282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
Comme vous le constatez plus haut on contrôle RAX, pour pousser l'exploit on pourrais utiliser des gadgets style mov %rbx, %rax
Pour faire cette recherche on utilise Objdump -D -M intel make | grep "mov" | grep "rbx"
40cc60: 48 89 c3 mov rbx,rax <- je prendrais celle-ci pour l'exemple
rbx prend la valeur de rax ce qui nous permet de controler rbx, sachant que %ebp(addresse la plus basse de la stack)
vaut la sauvegarde de la stack à la sortie de la fonction Calloc.La fonction Calloc est dimensionnée a 4096 octets
donc une seule page virtuelle et c'est pile notre valeur de Seg fault + 4 octet pour l'offset de retour.
On tombe sur notre Derefenrecing pointer
0x40cc59: je 0x40cc6b
0x40cc5b: nop DWORD PTR [rax+rax*1+0x0]
0x40cc60: mov rbx,rax <= Gadget
=> 0x40cc63: mov rax,QWORD PTR [rax] <= Pointer Dereferencing
0x40cc66: test rax,rax
0x40cc69: jne 0x40cc60
0x40cc6b: cmp DWORD PTR [rbp-0x105c],0x1
0x40cc72: lea rdi,[rbp-0x40]
[------------------------------------stack-------------------------------------]
J'ai d'ailleurs commencé à trouver de bonnes pistes ;-) un possible article sur une exploit de make serait sympa.Mais je vais m'en assurer et faire un truc béton.
Vous pourrez retrouver prochainement le POC sur Exploit-Db
Special Thanks A Kmkz et Zadyree qui ont fait des recherches sur les architectures en 32 bits.
HyP ++
Aucun commentaire:
Enregistrer un commentaire