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):
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:
When I run this program in the Terminal, I get the right address:
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.
GDB inherits the environment variables from your shell. Some environment variables, like LD_LIBRARY_PATH, might not be inherited for safety reasons. This can cause errors like this when you try to debug:
Environment variables that are unset by the user are also unset on gdbserver when starting the remote inferior. see QEnvironmentUnset . Warning: On Unix systems, GDB runs your program using the shell indicated by your SHELL environment variable if it exists (or /bin/sh if not).
3 In gdbyou can use the command show environment. Also as an alternative to examine the environment of a process is: $ sed 's/\x0/ /g' /proc/<PID>/environ The sedcommand is necessary to convert the NUL separators into newlines for readability.
You can use the string ‘ $cwd ’ to refer to whatever is the current working directory at the time GDB searches the path. If you use ‘. ’ instead, it refers to the directory where you executed the path command. GDB replaces ‘. ’ in the directory argument (with the current path) before adding directory to the search path.
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:
x/100s **(char***)&environ
).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:
_=/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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With