PaX PoC-exploit.

[Joel Eriksson <je-dailydave () bitnux com>]

Hi Daily Davers,

Just wanted to let you know of a little PoC-exploit I did
to show how stack overflows can be exploited on PaX-protected
systems with non-executable pages and a randomized stack and
mmap() base.

There are 16 bits of entropy in the randomized mmap() base, e.g.
only 65536 possibilities. That's no big deal to bruteforce in
local SUID/SGID prorams or daemons that fork() off a new process
for each connection (or that are automatically restarted).

In a remote exploit one would preferably like to have access to
the libc-binary on the system to find out offsets, but since most
systems use pre-compiled binaries it is usually just a matter of
determining or guessing which distribution the system uses.

The sample vuln and exploit is available at:

   http://0xbadc0ded.org/exploits/pax-poc.tar.gz

This is from a sample run:

sh-2.05b$ uname -a
Linux segv 2.4.26-grsec #1 Wed Apr 21 09:13:59 CEST 2004 i686   GNU/Linux
[je@segv ~/pax-poc]$ make all  
gcc -Wall -ansi -pedantic -o pax-exp pax-exp.c 
gcc -Wall -ansi -pedantic -o pax-vul pax-vul.c 
------------------------------------------------
Read the source or use pax-exp.sh to try it out.
- je () 0xbadc0ded org
[je@segv ~/pax-poc]$ ./pax-exp.sh
[*] Copying vuln file to temp file
[*] Using chpax/paxctl to disable all PaX flags on temp file
[*] Using ldd to find the libc base addr of temp file
[*] Creating program to be executed when exploit succeeds
[*] Using gdb to find out the offset to execvp() from the libc base addr
[*] Determining number of 4-byte pads between buf and the saved eip
[*] Using ldd to find a possible libc base addr of vuln file
[*] Executing ./pax-exp -v ./pax-vul -b 0x20a1c000 -f 0xa80b0 -p 1
[*] This could take a few minutes, so be patient..
[*] Time is now: Sun May  2 09:25:11 CEST 2004
................................................................
................................................................
.....................
[*] Exploit succeded at Sun May  2 09:26:31 CEST 2004
sh-2.05b$ 

Unless combined with something like SegvGuard, that stops programs
that segfaults to be executed again for a certain period of time, it
seems like Grsecurity/PaX does not do much good for protecting against
simple stack overflows.

Surprisingly, when examining the grsecurity-code a while ago I noticed 
that there is actually code there that enforces a minimum delay before
a segfaulted program can be executed again, but that it is only enabled
if the ACL-system is used. Perhaps someone on this list that uses
Grsecurity and its ACL-system could verify if this is indeed the case
by trying out the pax-poc?

Oh and btw, the box I ran the exploit on in the sample run listed above
was a Celeron 300MHz. It usually takes a 2-5 minutes to succeed on my
system, on faster machines it should be even faster. A dot is printed
on every 128:nd attempt and 64 dots are printed on each row = a full row
of dots is equal to 8192 attempts.

I wonder how W^X deals with these kind of attacks. It was quite a while
since I used OpenBSD on any of my machines, and after hearing about the
discoveries of a friend of mine while auditing the OpenBSD-kernel for a
couple of hours I feel even less inclined to use it again. ;) Seems Theo
and company should read up a bit on how to use integers. :P

-- 
Best Regards,
   Joel Eriksson
-------------------------------------------------
Cellphone: +46-70 228 64 16 Home: +46-26-10 23 37
Security Research & Systems Development at Bitnux
PGP Key Server pgp.mit.edu, PGP Key ID 0x529FDBD1
A615 A1E1 3CA2 D7C2 CFEA 47B4 7EF7 E6B2 529F DBD1
-------------------------------------------------
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave