6

Recently I'm doing some Return-to-libc attack experiment base on the paper Bypassing non-executable-stack during exploitation using return-to-libc with my Ubuntu11.10.

Before my experiment I closed the ALSR.

According to the paper, I can find address of the environment variable SHELL="/bin/bash" in gdb(use gdb to debug the program I want to attack):

enter image description here
enter image description here

But I found that this address is wrong when I try to use it to Return-to-libc experiment.

And then I write a simple program to get the environment variable address:

enter image description here

When I run this program in the Terminal, I get the right address:

enter image description here

With this address I can do the attack.

I also find the related question about this. But the answers doesn't really make sense(the second one may be better).

Just tell me some details about this, please.

Community
  • 1
  • 1
KUN
  • 527
  • 4
  • 18

1 Answers1

4

From your screenshots, I'll assume you're running on an 32-bit intel platform. I haven't spent the time to fully research an answer to this, but these are points worth noting:

  1. I'll bet that your entire environment is in about the same place, and is packed together tightly as c-style strings. (try x/100s **(char***)&environ).
  2. When I tried ths on my x86-64 installation, the only thing I saw after the environment was my command line, and some empty strings.
  3. At 0xBffff47A, you're very close to the top of user address space (which ends at 0xC0000000).

So, my guess is that what's going on here is that:

  1. The environment block and command line parameters are, at some point during startup, shoved in a packed form right at the end of user address space.
  2. The contents of your environment are different when you run your program in GDB or in the terminal. For example, I notice "_=/usr/bin/gdb" when running under GDB, and I'll just bet that's only there when running under GDB.

The result is that, while your fixed pointer tends to land somewhere in the middle of the environment block, it doesn't land in the same place every time, since the environment itself is changing between runs.

Managu
  • 8,849
  • 2
  • 30
  • 36
  • I also agree that the environment is different. Does that mean the paper I read is wrong? – KUN Jul 19 '12 at 04:36
  • @KUN: wrong? Ehh, the general idea makes sense. But, as you've demonstrated, their exploit example needs work. These things are notoriously fiddly (after all, you're really not "supposed" to be interacting with programs in this manner), and often require significant expertise to pull off. I suspect the author(s) understood the difficulty you've experienced could exist, and figured that solving them was an "exercise left to the reader." – Managu Jul 19 '12 at 13:42
  • @KUN: Oh, seems I didn't read far enough in. They did experience exactly this problem (on the next page). And they also discuss how they solved it. – Managu Jul 19 '12 at 13:46
  • Actually they solved it by the gdb again which I've tried but failed. That's why I used 'getenv' to get the address. – KUN Jul 20 '12 at 02:15
  • @KUN: they solved it by using GDB to open a core dump file. That's a different scenario, and the difference is important. – Managu Jul 20 '12 at 02:55
  • Oh,that's my fault. Now I understand it. Thanks. – KUN Jul 20 '12 at 03:39