I’ve been intrigued for a long by the so called fuzzers, I’ve wanted to give it a try on AIX some time ago. Let’s take one of the most recent AIX release that i had at that time, e.g. 6.1 Technology Level #6 Service Pack #4 (btw it works on 7.1.0.0 too):
$ oslevel -s
6100-06-04-1112
$ id
uid=100(guest) gid=100(usr)
$
$ ./ble
[After a while system reboots]
root@XYZ:# errpt -j 67145A39 -A
---------------------------------------------------------------------------
LABEL: DUMP_STATS
Date/Time: Fri Sep 16 05:06:17 EDT 2011
Type: UNKN
Resource Name: SYSDUMP
Description
SYSTEM DUMP
Detail Data
DUMP DEVICE
/dev/lv_dumplv
DUMP SIZE
242688512
TIME
Fri Sep 16 05:04:31 2011
DUMP TYPE (1 = PRIMARY, 2 = SECONDARY)
1
DUMP STATUS
0
ERROR CODE
0000 0000 0000 0000
DUMP INTEGRITY
Compressed dump - Run dmpfmt with -c flag on dump after uncompressing.
FILE NAME
PROCESSOR ID
0
root@XYZ:#
[..]
(0)> where
pvthread+011200 STACK:
[004CEB5C]rmsock+00001C (F3FCC00000000000 [??])
[00003850]ovlya_addr_sc_flih_main+000130 ()
[kdb_get_virtual_memory] no real storage @ 2FF22AC8
[1000070C]1000070C ()
[kdb_read_mem] no real storage @ FFFFFFFFFFF9610
(0)>
On different system 6100-03-01-0921:
(0)> where pvthread+00AF00 STACK: [0043DCFC]rmsock+00001C (F3FC000000000000 [??]) [00003844].svc_instr+000144 () [kdb_get_virtual_memory] no real storage @ 2FF229D0 [10000590]10000590 () [kdb_read_mem] no real storage @ FFFFFFFFFFF9680 (0)>
As you can see above it attempted any random syscall but on rmsock() – executed by non privileged user – it rebooted system (because of attributes on sys0 device that cause to reboot kernel in case of kernel panic). Typical Denial of Service attack, isn’t it?
Now let’s try something more intelligent (found during the research) – using only syscall number 793 on version 6100-06-04-1112:
$ ./ble 793 using only sc=793
.. and the system is dead. In AIX kernel debugger session on dump file after reboot you can see that even the system vector call instruction handler seems to be not visible, perhaps indicating some kind of memory overwrite in kernel space. (Probably) this could be exploited with finding offset of privilege access structure handling all UID/GIDs
(0)> where
pvthread+018C00 STACK:
[0001BF00]abend_trap+000000 ()
[000C585C]xm_bad_free+00025C (??, ??, ??, ??)
[000C4F30]xmfree+0004F0 (??, ??)
[046A7868]ptx_get_ndd_tree+000088 (??, ??, ??, ??, ??)
[00003850]ovlya_addr_sc_flih_main+000130 ()
[kdb_get_virtual_memory] no real storage @ 2FF22AC8
[1000070C]1000070C ()
[kdb_read_mem] no real storage @ FFFFFFFFFFF9640
(0)>
[..]
(0)> ppid 06400D8
SLOT NAME STATE PID PPID ADSPACE CL #THS
pvproc+019000 100*ble ACTIVE 06400D8 07700C8 0000000848B32480 0 0001
[..]
IDENTIFIER. uid :00000064 ........... suid :00000064
........... pid :006400D8 ........... ppid :007700C8
........... sid :006E0092 ........... pgrp :006400D8
[..]
(0)> nm pvproc
Symbol Address : F1000F0A00000000
TOC Address : 02B65540
(0)>
so as you can see UID of our “ble” system call fuzzing process was 0×64 (or in 100 if you are uncomfortable with hex notations). By changing value at address 0xF1000F0A00000000+0×19000 one could get root shell probably, but researching my way to do that could be very time intensive.
And sample from most recent AIX 7.1 that I was having access to:
guest@hostA:# oslevel -s 7100-00-03-1115 guest@hostA:# ./ble 766 using only sc=766
… and the system is dead:
(2)> where pvthread+011100 STACK: [F1000000C01E06CC]dupb+00000C (0000000030CBEE17 [??]) [F1000000C01E05DC]dupmsg+00001C (??) [00014D70].hkey_legacy_gate+00004C () [0000386C]ovlya_addr_sc_flih_main+00014C () [kdb_get_virtual_memory] no real storage @ FFFFFFFF3FFFE60 [kdb_read_mem] no real storage @ FFFFFFFFFFF95F0 (2)>
IBM has been notified months ago, patch has been released some time ago:http://aix.software.ibm.com/aix/efixes/security/syscall_advisory.asc (affects AIX 5.3, 6.1 and 7.1 plus all VIOS too). Happy patching 
-J.