Re: [Full-disclosure] Executing Code on Linux/x86 with ASLR+GCC4Protections

[Jeremy Brown <0xjbrown41@xxxxxxxxx>]

http://wiki.debian.org/Hardening
https://wiki.ubuntu.com/Security/Features#Feature%20Matrix

In fact, both have ASLR enabled in the kernel by default.

With all due respect, I've been exploiting buffer overflows on Windows
NT-like x86 operating systems for nearly 4 years. My job recently
required me to know how to attack *nix-based systems, so I figured
Linux would be the easiest to begin with. In fact, it seems many
protections such the compiler and kernel have been in place for a
while now.

My question is, how do I exploit this program? Looking over my
previous post I see that I did mention defeating GCC protections and
ASLR, both. So of those protections... I am aware.

I know sometimes you can overwrite other registers and gain code
execution, such as ESI usually points to pointers, etc and so forth.

I do appreciate your response, but maybe a well armed one next reply?

On Wed, Sep 23, 2009 at 4:18 AM, Jeremi Gosney
<Jeremi.Gosney@xxxxxxxxxxxxx> wrote:
> are you positive you have a kernel patched for aslr on this host? debian and 
> ubuntu do not ship with aslr. you will have to manually patch your kernel 
> with something like PaX to gain that functionality.
>
> it doesn't really matter. from your question I can tell you do not yet fully 
> understand the mechanics of a buffer overflow. the goal is to gain control a 
> function's return address by overwriting eip. you've already overwritten the 
> registers you are asking if you can overwrite; if you bother to look at your 
> gdb output, you'll see that you've of course already written 'BABA' to esi 
> and eax. so I guess to directly answer your question... no.
>
> what you're seeing below is the effect of compile-time stack protection, not 
> aslr. how do I know? because eip never changed. with aslr, you will likely be 
> able to overwrite eip, but you will not know the address to return to in 
> order to execute the stack since the stack is randomized at runtime. the 
> compile-time stack protection method used (StackGuard, ProPolice, 
> StackShield, etc) will determine which method you will use to defeat it, as 
> each take separate approaches to protecting eip. there are ways to defeat 
> each of the various stack protection methods, but the below program is likely 
> too simple to exploit since we don't have a pointer we can manipulate. they 
> are more useful against real-world examples.
>
> you should probably read this first:
> http://www.phrack.org/issues.html?issue=49&id=14#article
>
> further reading:
> http://www.phrack.org/issues.html?issue=56&id=5#article
> http://www.phrack.org/issues.html?issue=59&id=9#article
>
> - epixoip
>
>
> From: full-disclosure-bounces@xxxxxxxxxxxxxxxxx 
> [mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Lucus Rife
> Sent: Tuesday, September 22, 2009 5:28 PM
> To: full-disclosure@xxxxxxxxxxxxxxxxx
> Subject: [Full-disclosure] Executing Code on Linux/x86 with 
> ASLR+GCC4Protections
>
> Debian/Ubuntu latest with updates...
>
> (gdb) shell cat bof.c
> #include <stdio.h>
> #include <string.h>
>
> int main(int argc, char *argv[])
> {
>
> if(argc < 2) return 0;
>
> char buf[128];
> strcpy(buf, argv[1]);
>
> return 0;
> }
>
> (gdb) r `perl -e 'print "BABA" x 74'`
> Starting program: /home/rife/bof `perl -e 'print "BABA" x 74'`
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7e355eb in strlen () from /lib/tls/i686/cmov/libc.so.6
> (gdb) info r
> eax            0x41424142    1094861122
> ecx            0x2    2
> edx            0xbfc557b8    -1077585992
> ebx            0xb7f1cff4    -1208889356
> esp            0xbfc5520c    0xbfc5520c
> ebp            0xbfc557a4    0xbfc557a4
> esi            0x41424142    1094861122
> edi            0xb7f008b2    -1209005902
> eip            0xb7e355eb    0xb7e355eb <strlen+11>
> eflags         0x210202    [ IF RF ID ]
> cs             0x73    115
> ss             0x7b    123
> ds             0x7b    123
> es             0x7b    123
> fs             0x0    0
> gs             0x33    51
> (gdb)
>
> This is as far as I've gone. Is there some way to point EAX or better than 
> that, ESI, to our payload and execute code?
>
> Is there a way in any situation if we overwrite ESI to make it execute code?
>
> Surely to God someone on this list knows something..
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/