2

I'm trying to exploit my own code, just to learn how the "return-to-libc" technique works.

I'm following a tutorial which basically says that to use this, I must find the address of the function I want to use.

To remain on classic, I choose to use the "system" function in order to obtain a shell.

My steps in order to find this address are:

  1. run gdb with as argument the name of the executable I want to exploit. eg. "$ gdb test"
  2. place a breakpoint in order to stop the loaded code. Let say "b main" at the gdb prompt
  3. run the code which stops at the breakpoint "r"
  4. get the address with "p system"

This an example of what I did:

GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".<br>

(gdb) b main
Breakpoint 1 at 0x8048468
(gdb) r
Starting program: /home/ale/test

Breakpoint 1, 0x08048468 in main ()
(gdb) p system
$1 = {<text variable, no debug info>} **0x2779b0** <system>
(gdb) q


GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) b main
Breakpoint 1 at 0x8048468
(gdb) r
Starting program: /home/ale/test

Breakpoint 1, 0x08048468 in main ()
(gdb) p system
$1 = {<text variable, no debug info>} **0x1459b0** <system>

It seems that each time I start gdb I get a different address? Can someone explain me why?

Is this a mitigation feature built in my kernel/linux made to prevent this exploit technique usage?

Later, googling around I finally found something that fits a little my scenario. It seem to exist a feature called "Kernel address space layout randomization" which is similar in some ways to what I'm experiencing. However, if I understand completely what this Kernel address space layout randomization is, I should experiencing this beaviour once each time I reload the kernel, instead I have this behaviour each time I start the code through gdb. Infact, building the following simple code the experienced weird behaviour seem not be there:

#include <stdio.h>
#include <stdlib.h>

int main()
{
 printf("%p\n", (void*)system);
}

This code should output the address of the system() function. Testing it, it produces each time the same address. It seems this strange behaviour is some how related to the gdb, but I'm not sure.... I'm confused.

  • KASLR is not related to the problem you are experiencing. It does not affect userland, but is a (rather limited) defense against exploits against the kernel. If you are exploiting a userland program, KASLR will not have any effect on what you are doing. – forest May 1 '16 at 2:40
1

It seems I found an answer myself, at least a sort of.
Well, as I suspected, kernel developers are very far away from me.
Indeed the "Address space layout randomization" seems to produce the behaviour I observed on my system.
When I read the wikipedia article, I understood address space is structured once each time kernel starts, but testing it I verified that actually things are slightly different.
GDB has a neat feature called "disable-randomization" which is on by default.
In spite that, libc system(), and I guess any libc function, changes its address each time I start GDB.
Digging deeper I finally found that kernel feature may be disabled at kernel level through "/proc/sys/kernel/randomize_va_space".
My kernel by default was set it to the value 2.
Setting it at 0, I realized the randomization stops.
Everything seems clear now, but there's still a piece which does not fit.

  • Why the code I wrote to print the libc system address, when I run it from the prompt produces any time the same address?
  • Is the code I wrote, that do not request the feature producing this result?

UPDATE
if there's someone is good enough, I'd like this guy to explain me this:

$ cat /proc/sys/kernel/randomize_va_space
0
$ ldd /tmp/t
        libc.so.6 => /lib/tls/libc.so.6 (0x00110000)
        /lib/ld-linux.so.2 (0x00843000)
$ ldd /tmp/t
        libc.so.6 => /lib/tls/libc.so.6 (0x00dcd000)
        /lib/ld-linux.so.2 (0x0037b000)
$ ldd /tmp/t
        libc.so.6 => /lib/tls/libc.so.6 (0x00ab7000)
        /lib/ld-linux.so.2 (0x00f14000)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.