0

I am working through Erickson's "The Art of Exploitation" and failing to reproduce an exploit.

Shellcode is stored in an environmental variable "SHELLCODE", which is then executed by a program with root access. The Book suggests, that the address stays roughly the same for each call of the program (depending on the length of the program name) and uses the following code to find it:

getenv.c

#include ...
int main(int argc, char *argv[]) { 
printf("SHELLCODE is at %p\n", getenv(SHELLCODE));
}

However, on my linux virtual machine (gcc (Debian 10.2.1-6) 10.2.1) the address changes wildly with each call of the program:

cream@debian$ ./getenv
SHELLCODE is at 0xbf955414
cream@debian$ ./getenv
SHELLCODE is at 0xbfa4b414
cream@debian$ ./getenv
SHELLCODE is at 0xbfe94414

Why is this the case and how can I avoid it?
Or alternatively, how would one modify the exploit to get it to work despite an unpredictable SHELLCODE address before program call.

Some detail on the exlpoit:

"SHELLCODE" contains a NOP sled of reasonable size ending with the shellcode. To get root access, one now runs a program (notesearch) with root access and, using a buffer overflow, overwrites the return address of the stack pointer with an address on the NOP sled.
This, in turn, executes the shellcode as root:

cream@debian$ ./notesearch $(perl -e 'print "\x47\xf9\xff\xbf"x40')

It is necessary to know the address of the SHELLCODE variable (\x47\xf9\xff\xbf in the above) to work the exploit.

This question is on the same exploit with a similar problem. There, the only answer assumes that the address changes between gdb and shell (it is never clarified if this solves the problem). I see a changing address in the shell alone.

Cream
  • 101
  • 2
  • This is because of [ASLR](https://en.wikipedia.org/wiki/Address_space_layout_randomization). It is ofcourse used to prevent vulnerabilities. – Example person Jan 29 '22 at 12:38
  • Seems like a duplicate of [Why address of a variable change after each execution in C?](https://stackoverflow.com/questions/2846637/why-address-of-a-variable-change-after-each-execution-in-c) – Example person Jan 29 '22 at 12:40
  • And also, I don't think there is any guarantee that `getenv()` returns the same address every time even when ASLR is disabled. – Example person Jan 29 '22 at 12:47
  • @Exampleperson Thanks for pointing that out! However, I'm not just asking why it happened but also how to either turn off the address randomization or find a way modify the (specific) exploit to work despite randomized addresses (this might be of interest for other people learning about this). Also, as you pointed out, I am considering environment variables. So things might work different for them. I would therefore not call it a duplicate. – Cream Jan 29 '22 at 12:52
  • @Exampleperson I correct myself: [This answer](https://stackoverflow.com/a/62276071/18048105) in the suggested post includes how to turn off ASLR. This indeed solves my problem and the address of the environment variable stays the same on repeated calls. The remaining question, how to modify exploits to circumvent ASLR is then maybe worth its one question. Thanks again! – Cream Jan 29 '22 at 13:03
  • "how to modify exploits to circumvent ASLR": It's hard. It's supposed to be hard. That's why ASLR is an effective hardening mechanism. In many cases you would have to find a *second* vulnerability that discloses the absolute address of some object in the program whose relative address is known, then use it to adjust the absolute addresses used in your exploit. Or, you have to find an exploit that works not by executing your own code, but by manipulating data to cause the program's existing code to do something else. – Nate Eldredge Jan 29 '22 at 18:03

0 Answers0