CODEWITHSUNDEEP
clinuxsecurityx86-64buffer-overflow
marcofor10
marcofor10

Reputation: 76

buffer overflow on x86_64 - return to libc attack (linux)

After having studied and tested various types of attack on 32-bit linux machine (shellcode injection, return to libc, GOT overwriting) I focused on the 64-bit world. I hadn't any problems in the implementation of a basic shellcode injection attack.

But now I'm trying to make a return to libc attack on x86_64 in order to bypass the NX-stack protection. Now, in the 64-world, the text segment of the vulnerable program is protected with null bytes so you can't redirect the execution to an instruction inside the victim.

(gdb) disas main
Dump of assembler code for function main:
   0x00000000004005bc <+0>: push   %rbp
   0x00000000004005bd <+1>: mov    %rsp,%rbp
   .........................................................
   0x0000000000400600 <+68>:    callq  0x400480 <strcpy@plt>
   0x0000000000400605 <+73>:    lea    -0x40(%rbp),%rax
   .........................................................
End of assembler dump.

5 of 8 bytes of the addresses are null bytes (1 of 4 is a null bytes -> finding a 32-bit pop-ret gadget isn't a solution).

As in 32-architecture the instructions in libc are protected with NULL bytes :

(gdb ) p execve<br/>
$ 1 = { <text variable, no debug info> } 0x7ffff7ad2cc0 <execve>

2 of 8 bytes are null bytes.

I found an article about the technique I'm trying to realize:

http://pastebin.com/RA4qVWgX

but at the main point when the input (with null bytes?) is passed to the program (line 241 of the article) it just says "feed it into victim". As far as I know there is no way to inject an input with more than one null byte in a string exploiting a vulnerable function (gets, strcpy).

I would be grateful if someone can help me understand this or give me advice about ret2libc attack on a x86_64 machine.

Upvotes: 3

Views: 2561

Answers (1)

Armali
Armali

Reputation: 19395

So I guess you could say: if the vulnerability is due to the presence of gets it's possible to realize a return-to-libc exploit (containing many null bytes), but if the vulnerability is due to the presence of strcpy it isn't possible to realize that because the strcpy will stop at the first null byte.

We could say so, but should be aware that gets is just one example of code that doesn't stop at a null byte, and strcpy is just one example of code that does.

Upvotes: 1

Related Questions