12

If I run a C/C++ program in gdb (after compiling with the -g flag) and I examine the addresses of certain variables, arguments...etc, and then I run it outside of gdb (using ./) will these addresses be the same as the ones I saw in gdb? If they're different are they usually similar or will they be drastically different?

I ask this because I have a buffer overflow program that works perfectly in gdb (with and without breakpoints), however when I try to run it outside of gdb it doesn't work.

Kevin Reid
  • 37,492
  • 13
  • 80
  • 108
Nosrettap
  • 10,940
  • 23
  • 85
  • 140

3 Answers3

11

I examine the addresses of certain variables, arguments...etc, and then I run it outside of gdb (using ./) will these addresses be the same as the ones I saw in gdb

It depends.

  1. Global variables defined in the main executable will stay at the same address (unless the executable is built with -fpie and linked with -pie flags.
  2. Global variables defined in other shared libraries may have drastically different addresses due to ASLR.
  3. Local variables and parameters may move around by several K-bytes due to ASLR.
  4. Heap-allocated variables may also drastically move due to ASLR, or if your program is multi-threaded.

Note that GDB on Linux by default disables ASLR, to make debugging easier. You can re-enable ASLR under GDB with set disable-randomization off. That may allow you to reproduce the problem under GDB.

I have a buffer overflow

Also note, that tools like Valgrind and Address Sanitizer are often significantly more effective for finding buffer overflows than running under GDB. Address Sanitizer in particular is great in that it finds buffer overflows in globals and on stack (Valgrind doesn't).

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
2

You should never ever assume that a certain code or vars will be located at a fixed place.

This was true in the past in the most OS but it is a security hole. malicious software uses this to inflect programs. OS will tend to scramble addresses to increase security.

stefan bachert
  • 9,413
  • 4
  • 33
  • 40
  • 2
    I was just about to mention [address space layout randomization (ASLR)](http://en.wikipedia.org/wiki/Address_space_layout_randomization). – Blastfurnace Apr 08 '12 at 08:40
  • 1
    One can *safely* assume that in a position-dependent executable, all global variables will stay at the same fixed address from one execution to another. – Employed Russian Apr 08 '12 at 15:22
  • 1
    @ Employed Russian: I would not expect that. Why do you think so? – stefan bachert Apr 08 '12 at 15:41
  • 1
    I don't *think*, I *know* (because I understand how executables get loaded into memory and how they are linked). Try it. – Employed Russian Apr 08 '12 at 17:29
  • @stefanbachert: That's because the code refers to these addresses directly, and their memory is located in a special section of the PE (e.g. .data, .bss - depending on a few factors). – Asaf Apr 08 '12 at 17:33
0

Compiling with the -g flag increases the code size as it bungs into the executable extra information.

As to your buffer problem it would help to publish a snippet of code where things are going awry.

Ed Heal
  • 59,252
  • 17
  • 87
  • 127