How To Check For ASLR and NX Features of Embedded Linux System 1
How To Check For ASLR and NX Features of Embedded Linux System 1
/bin/busybox
/bin/busybox
[heap]
/lib/ld-2.8.so
/lib/ld-2.8.so
/lib/libm-2.8.so
/lib/libm-2.8.so
/lib/libm-2.8.so
/lib/libc-2.8.so
/lib/libc-2.8.so
/lib/libc-2.8.so
/lib/libc-2.8.so
[stack]
After Reboot,
tango3[bin]# cat /proc/modules
em8xxx 935488 0 - Live 0xc01b8000 (PF)
llad 144800 1 em8xxx, Live 0xc00b0000 (P)
sigmablock 70976 3 - Live 0xc002c000 (P)
tango3[bin]# cat /proc/self/maps
00400000-004b0000 r-xp 00000000 00:01 387
004bc000-004c0000 rw-p 000ac000 00:01 387
004c0000-004c4000 rwxp 004c0000 00:00 0
2aaa8000-2aac8000 r-xp 00000000 00:01 624
2aac8000-2aacc000 rw-p 2aac8000 00:00 0
2aad4000-2aad8000 rw-p 0001c000 00:01 624
2aad8000-2ab54000 r-xp 00000000 00:01 514
2ab54000-2ab60000 ---p 0007c000 00:01 514
2ab60000-2ab64000 rw-p 00078000 00:01 514
2ab64000-2acac000 r-xp 00000000 00:01 630
2acac000-2acb8000 ---p 00148000 00:01 630
2acb8000-2acc0000 r--p 00144000 00:01 630
2acc0000-2acc4000 rw-p 0014c000 00:01 630
2acc4000-2acc8000 rw-p 2acc4000 00:00 0
7f7c8000-7f81c000 rwxp 7f7c8000 00:00 0
/bin/busybox
/bin/busybox
[heap]
/lib/ld-2.8.so
/lib/ld-2.8.so
/lib/libm-2.8.so
/lib/libm-2.8.so
/lib/libm-2.8.so
/lib/libc-2.8.so
/lib/libc-2.8.so
/lib/libc-2.8.so
/lib/libc-2.8.so
[stack]
Most of them are consistent before and after the system reboot, except the stack, but
that is not a problem from the perspective of attacking embedded linux system. So, the
system being tested has ASLR disabled. How about NX ? Regarding to this issue, we first
assume the stack should always be NX protected. So, we will put some instructions in
the stack and then redirect the program counter into it. After that, we step over those
instructions and observe the outcomes. If the outcome is positive, it means the NX is
disabled. Otherwise, if exception incurred, then it means the NX is enabled and run
properly. We will run our test on a MIPS platform with GDB. Let's say we want to create
some instructions to change register $t0 to 0xffffffff now. Well, it is
lui $t0,0xffff
ori $t0,$t0,0xffff
Please refer my previous paper "How To Convert Assembly Instruction Into Machine Code
In Any Type Of Processors Platform" to obtain the respective machine code of that 2
instructions.
Host:# echo 'lui $t0,0xffff' > temp.s && ./mips-linux-gnu-gcc -EL -c temp.s &&
./mips-linux-gnu-objdump -d temp.o | grep 0: | sed s/.*0://
3c08ffff
lui
t0,0xffff
Host:# echo 'ori $t0,$t0,0xffff' > temp.s && ./mips-linux-gnu-gcc -EL -c temp.s &&
./mips-linux-gnu-objdump -d temp.o | grep 0: | sed s/.*0://
3508ffff
ori
t0,t0,0xffff
Well, let us put the machine codes into the stack. We need to run a dummy program, set
a breakpoint at _main, then continue the execution, and stop at the breakpoint.
tango3[gdb]# ./gdb ./hello
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mips-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/cawan/mips-4.3/bin/gdb-7.0/gdb/hello...
(no debugging symbols found)...done.
Setting up the environment for debugging gdb.
Function "internal_error" not defined.
Make breakpoint pending on future shared library load? (y or [n])
[answered N; input not from terminal]
Function "info_command" not defined.
Make breakpoint pending on future shared library load? (y or [n])
[answered N; input not from terminal]
/root/cawan/mips-4.3/bin/gdb-7.0/gdb/.gdbinit:8: Error in sourced command file:
No breakpoint number 0.
(gdb) break main
Breakpoint 1 at 0x400620
(gdb) run
Starting program: /root/cawan/mips-4.3/bin/gdb-7.0/gdb/hello
Breakpoint 1, 0x00400620 in main ()
(gdb)
Good, we are at the point. Let's check the register info.
at
fffffff8
t1
0ffffffe
s1
004004f0
t9
00400610
lo
00005e17
fir
01739300
v0
7ff5ba68
t2
00000002
s2
004cece8
k0
00000000
hi
000001a5
restart
00000000
v1
2aac8a70
t3
7ff5ba20
s3
004ced40
k1
00000000
badvaddr
2ab065d0
a0
00000001
t4
ffffffff
s4
00412580
gp
2ac3d950
cause
50808024
a1
7ff5bb24
t5
7ff5b978
s5
004cece8
sp
7ff5ba30
pc
00400620
a2
7ff5bb2c
t6
2aab1b84
s6
004ceda0
s8
7ff5ba30
a3
00000000
t7
f0000000
s7
004cedb0
ra
2aaee948
0x00400658
0x00412580
0x00000001
0x00000000
0x004004f0
0x00000000
0x7ff5bb24
0x2aaee908
0x004cece8
0x2aaee948
0x2aaee7fc
0x7ff5ba50
0x3c08ffff
0x00000000
0x7ff5bb24
0x2aaee908
0x3508ffff
0x2aaee948
0x2aaee7fc
0x7ff5ba50
nop
nop
lui $t0,0xffff
ori $t0,$t0,0xffff
nop
nop
(gdb)
Fine, the content of stack has been changed to our instructions. Now, let us
redirect our program counter to the stack.
(gdb) set $pc = $sp
warning: GDB can't find
(gdb) info reg
zero
at
R0
00000000 fffffff8
t0
t1
R8
2ac372f4 0ffffffe
s0
s1
R16 00400658 004004f0
t8
t9
R24 00000000 00400610
status
lo
00001c13 00005e17
fcsr
fir
00000000 01739300
(gdb)
v1
2aac8a70
t3
7ff5ba20
s3
004ced40
k1
00000000
badvaddr
2ab065d0
a0
00000001
t4
ffffffff
s4
00412580
gp
2ac3d950
cause
50808024
a1
7ff5bb24
t5
7ff5b978
s5
004cece8
sp
7ff5ba30
pc
7ff5ba30
a2
7ff5bb2c
t6
2aab1b84
s6
004ceda0
s8
7ff5ba30
a3
00000000
t7
f0000000
s7
004cedb0
ra
2aaee948
Well, the program counter is already at the stack, and the $t0 register is 2ac372f4 now.
Let us step over those instructions, and we suppose once the program counter arrived at
the 5th instruction, register $t0 should be changed into 0xffffffff. Let's see.
(gdb) ni
warning: GDB can't find
0x7ff5ba34 in ?? ()
(gdb) ni
warning: GDB can't find
0x7ff5ba38 in ?? ()
(gdb) ni
warning: GDB can't find
0x7ff5ba3c in ?? ()
(gdb) ni
warning: GDB can't find
0x7ff5ba40 in ?? ()
(gdb) ni
warning: GDB can't find
0x7ff5ba44 in ?? ()
(gdb) info reg
zero
at
R0
00000000 fffffff8
t0
t1
R8
ffffffff 0ffffffe
s0
s1
R16 00400658 004004f0
t8
t9
R24 00000000 00400610
status
lo
00001c13 00005e17
fcsr
fir
00000000 01739300
(gdb)
v0
7ff5ba68
t2
00000002
s2
004cece8
k0
00000000
hi
000001a5
restart
00000000
v1
2aac8a70
t3
7ff5ba20
s3
004ced40
k1
00000000
badvaddr
2ab065d0
a0
00000001
t4
ffffffff
s4
00412580
gp
2ac3d950
cause
50808024
a1
7ff5bb24
t5
7ff5b978
s5
004cece8
sp
7ff5ba30
pc
7ff5ba44
a2
7ff5bb2c
t6
2aab1b84
s6
004ceda0
s8
7ff5ba30
a3
00000000
t7
f0000000
s7
004cedb0
ra
2aaee948
Awesome, the register $t0 has eventually changed to 0xffffffff. So, the MIPS platform
under test has NX disabled. In other words, it is easy to design shellcode to work with
appropriate exploit in attacking this platform.