full-disclosure - Re: Executing Code on Linux/x86 with ASLR+GCC4Protections

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c83481820909231008p9f1ec63t5fc703f8714c9b65@mail.gmail.com>
Date: Wed, 23 Sep 2009 13:08:12 -0400
From: Jeremy Brown <0xjbrown41@...il.com>
To: Jeremi Gosney <Jeremi.Gosney@...ricity.com>,
	full-disclosure@...ts.grok.org.uk
Subject: Re: Executing Code on Linux/x86 with
	ASLR+GCC4Protections

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@...ricity.com> 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@...ts.grok.org.uk [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Lucus Rife
> Sent: Tuesday, September 22, 2009 5:28 PM
> To: full-disclosure@...ts.grok.org.uk
> 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/