|
Full Disclosure
mailing list archives
Re: Executing Code on Linux/x86 with ASLR+GCC4Protections
From: "Jeremi Gosney" <Jeremi.Gosney () motricity com>
Date: Wed, 23 Sep 2009 11:19:02 -0700
maybe you were possessed by the spirit of lucas rife while you were sleeping and he used your body to write his reply.
did you forget to wear your tin foil hat?
to be perfectly clear, there is a weak aslr implementation in the vanilla kernel that has been accepted and applied
upstream since 2.6.12, but it's hardly a full implementation and is generally completely ineffective. the example
program below is trivial to exploit without the compile-time stack protections. you will need to manually patch your
kernel with something like PaX to get the full functionality and effectiveness you would expect from aslr.
but as I stated, this example program lucas as provided is likely too trivial to implement any of the methods used to
defeat compile-time stack protection. the links I provided in my response will, however, show you different methods for
defeating both runtime and compile-time stack protections, and will likely be useful against real-world code. but as it
is currently written, we don't have any pointers on the stack that we can manipulate so these methods cannot be applied.
- epixoip
-----Original Message-----
From: Jeremy Brown [mailto:0xjbrown41 () gmail com]
Sent: Wednesday, September 23, 2009 11:04 AM
To: Jeremi Gosney; full-disclosure () lists grok org uk
Subject: Re: [Full-disclosure] Executing Code on Linux/x86 with ASLR+GCC4Protections
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 () gmail com> 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 () motricity 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 () lists grok org uk [mailto:full-disclosure-bounces () lists grok org uk] On Behalf
Of Lucus Rife
Sent: Tuesday, September 22, 2009 5:28 PM
To: full-disclosure () lists 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/
 By Date 
By Thread
Current thread:
|
