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 18.104.22.168 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 [??]) 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 [??]) .svc_instr+000144 () [kdb_get_virtual_memory] no real storage @ 2FF229D0 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 (??, ??, ??, ??, ??) 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