[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Full-disclosure] Executing Code on Linux/x86 with ASLR+GCC4Protections
- To: Jeremi Gosney <Jeremi.Gosney@xxxxxxxxxxxxx>, full-disclosure@xxxxxxxxxxxxxxxxx
- Subject: Re: [Full-disclosure] Executing Code on Linux/x86 with ASLR+GCC4Protections
- From: Jeremy Brown <0xjbrown41@xxxxxxxxx>
- Date: Wed, 23 Sep 2009 14:04:27 -0400
Ooops I made an lol.. or maybe I like talking as a third person? Haha.
In any regard, none of that is true, all made up.. except the problem.
Won't happen again :)
The lesson here is don't lie at all and especially not to trolls on
their property :P
On Wed, Sep 23, 2009 at 1:08 PM, Jeremy Brown <0xjbrown41@xxxxxxxxx> wrote:
> 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/