Is the memory map of a process different when executed in GDB?

[Florencio Cano]

Hi,
I'm beggining studying deeply exploits. Now I have a problem. I'm
trying a return-to-libc exploit but I get a segmentation fault when
executed in the terminal and I get the code correctly executed when I
run it inside GDB. Does GDB alter the memory map of a process when
executed inside it? In which way? Where I can read info about this?
This is the problem:

fcano@gohan ~/ShellcodersHandbook/code/ch02 $ ./ret2libc 609 1776
Using address: 0xbfffeb08
fcano@gohan ~/ShellcodersHandbook/code/ch02 $ ./victim $BUF
Segmentation fault
fcano@gohan ~/ShellcodersHandbook/code/ch02 $ gdb ./victim
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) r $BUF
Starting program: /home/fcano/ShellcodersHandbook/code/ch02/victim $BUF
sh-3.2$

Any ideas?

[Chris McCulloh]

> I'm beggining studying deeply exploits. Now I have a problem. I'm
> trying a return-to-libc exploit but I get a segmentation fault when
> executed in the terminal and I get the code correctly executed when I
> run it inside GDB. Does GDB alter the memory map of a process when
> executed inside it? In which way? Where I can read info about this?

It's hard to say exactly what's going on without seeing the example  
code you're trying to exploit.  But let me give you some basic  
thoughts..

I assume you are putting the address of the string "/bin/sh" somewhere  
in the environment and then attempting a basic ret-to-libc with a call  
to system().  So your buffer probably looks something like this:

[ x bytes of junk to overflow buffer ][ address of system() ][ address  
of exit() ][ address of "/bin/sh" ]

The environment a program receives when being invoked by gdb is a bit  
different than that which it receives when being invoked from the  
shell.  As an example, try compiling and running this simple program  
which shows the address of an environment variable:

#include <stdlib.h>
main(int argc, char **argv){   printf("%s :: 0x%08x\n", argv[1],  
getenv(argv[1])) ; }

Run that both from a shell and from gdb and you will see the addresses  
are different.  Don't hold me to this, but I believe on Linux you will  
find that your target environment variable address will be 0x20 bytes  
lower when called from gdb than from a shell.  But you should do your  
own experimenting to see how it works.

Remember also that the length of your program name (argv[0]) also  
affects the memory layout.  So if you compile the above code as './
getenv' and your program name is './vulnerableproggy' then the address  
will be different.  For every character longer the vulnerable program  
is, the memory address you are examining will be two bytes *lower* (on  
Linux IA-32, at least).  This is because the name of the program, as  
part of argv, is passed to the program.  This difference also differs  
across platforms.

Also try manually looking through the process memory space in gdb so  
you can see what kind of items are in there.  If the address returned  
by the above call to getenv() is 0xbffffd10, for example, try looking  
at memory as strings starting at 0xbffff900 in gdb using

x/20s 0xbffff900

Hope this helps.
-c

[Kristian Erik Hermansen]

On Tue, Sep 23, 2008 at 3:43 AM, Florencio Cano
<florencio.cano@...> wrote:
> run it inside GDB. Does GDB alter the memory map of a process when
> executed inside it? In which way? Where I can read info about this?

Yes, your offsets will differ.  Put a break at start of main(),
recompile, and use something like memfetch | hexdump -C to see...
http://lcamtuf.coredump.cx/soft/memfetch.tgz

You must also remember that newer Linux distros include many security
features that randomize offsets and protect against other hackery.
Not that you can't get around them given enough information (like a
memory peek), but you should know about them.  All of this stuff is
well documented on places like milw0rm.  Regards...
--
Kristian Erik Hermansen
http://friendfeed.com/khermans