[转载]Solution To Red Hat PIE protection
文章作者：Fr0z3nSolution To Red Hat PIE protection
(Fr0z3n : [email]zarul_shahrin@yahoo.com[/email])
I read a great article written by Vangelis about exploiting local vulnerability 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"?
Izzit really "near impossible"? Let us check it out now,
first of all, this is the vuln program..just the same as the one in Vengelis paper:
---------------------------------vul.c----------------------------------------
int main(int argc, char *argv[])
{
char buffer[256];
strcpy(buffer,argv[1]);
return 0;
}
------------------------------------------------------------------------------
Btw, all the work below was done under Fedora 3.So any improvement from the Fedora 2 would be in this version.
I started this work exactly after Installing it which of course took a longer time than finding out how to exploit this program.
So no patch applied.
[zarul@localhost exercise]$ cat /proc/version
Linux version 2.6.9-1.667 ([email]bhcompile@tweety.build.redhat.com[/email]) (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 let us compile our "Vulnerable" program , I will compile the vulnerable program as Arjan van de Ven said:
[zarul@localhost exercise]$ gcc -fpie -pie vul.c -o vul
[zarul@localhost exercise]$
[root@localhost exercise]# chown root vul
[root@localhost exercise]# chgrp root vul
[root@localhost exercise]# chmod 4755 vul
[root@localhost exercise]# ls -la
total 40
drwsr-xr-x 2 zarul zarul 4096 Feb 9 14:20 .
drwx------ 3 zarul zarul 4096 Feb 8 20:48 ..
-rw-r--r-- 1 root root 564 Feb 9 113:15 data
-rw-r--r-- 1 root root 556 Feb 9 110:31 data~
-rwxrwxr-x 1 zarul zarul 5191 Feb 8 220:48 exploit1
-rw-rw-r-- 1 zarul zarul 100 Feb 8 220:48 exploit1.c
-rwsr-xr-x 1 root root 5441 Feb 9 114:20 vul
-rw-rw-r-- 1 zarul zarul 113 Feb 8 118:39 vul.c
Ok..Did I do the correct way bro?
ok now, let us 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".
(gdb) b main
Breakpoint 1 at 0x5d4
(gdb) r
Starting program: /home/zarul/exercise/vul
(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
(gdb) disas execl
Dump of assembler code for function execl:
0xf6f3f720 <execl+0>: push %ebp
0xf6f3f721 <execl+1>: mov %esp,%ebp
0xf6f3f723 <execl+3>: lea 0x10(%ebp),%ecx
0xf6f3f726 <execl+6>: push %edi
0xf6f3f727 <execl+7>: push %esi
0xf6f3f728 <execl+8>: push %ebx
0xf6f3f729 <execl+9>: sub $0x1038,%esp
0xf6f3f72f <execl+15>: mov 0xc(%ebp),%eax
0xf6f3f732 <execl+18>: movl $0x400,0xfffffff0(%ebp)
0xf6f3f739 <execl+25>: lea 0x1b(%esp),%edx
0xf6f3f73d <execl+29>: and $0xfffffff0,%edx
0xf6f3f740 <execl+32>: call 0xf6ecac71 <__i686.get_pc_thunk.bx>
0xf6f3f745 <execl+37>: add $0x998af,%ebx
0xf6f3f74b <execl+43>: mov %eax,(%edx)
0xf6f3f74d <execl+45>: test %eax,%eax
0xf6f3f74f <execl+47>: mov %ecx,0xffffffe8(%ebp)
0xf6f3f752 <execl+50>: movl $0x1,0xffffffec(%ebp)
0xf6f3f759 <execl+57>: je 0xf6f3f7e0 <execl+192>
0xf6f3f75f <execl+63>: movl $0x1a,0xffffffe0(%ebp)
0xf6f3f766 <execl+70>: jmp 0xf6f3f783 <execl+99>
0xf6f3f768 <execl+72>: addl $0x8,0xffffffe0(%ebp)
0xf6f3f76c <execl+76>: mov 0xffffffe8(%ebp),%edi
0xf6f3f76f <execl+79>: mov 0xffffffec(%ebp),%ecx
0xf6f3f772 <execl+82>: addl $0x4,0xffffffe8(%ebp)
0xf6f3f776 <execl+86>: mov (%edi),%eax
0xf6f3f778 <execl+88>: mov %eax,(%edx,%ecx,4)
0xf6f3f77b <execl+91>: inc %ecx
---Type <return> to continue, or q <retturn> to quit---
....
wtf? Where is the NULL pointer dereference protection?
Is the protection ON?Let me check it 1st..
[zarul@localhost exercise]$ cat /proc/sys/kernel/exec-shield
2
[zarul@localhost exercise]$
the echoed value is 2..what it means? Let us check the latest "Exec-Shield" Document.It 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 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
页:
[1]