Go Mac OS X Local privilege escalation (iobluetoothfamily)

Source:?http://joystick.artificialstudios.org/2014/10/mac-os-x-local-privilege-escalation.html

Nowadays, exploitation of user-level vulnerabilities is becoming + more difficult, because of the widespread diffus Ion of several protection methods, including ASLR, NX, various heap protections, stack canaries, and sandboxed execution. As a natural consequence, instead of extricating themselves with such a plethora of defensive methods, attackers prefer to Take the ' easy ' and started to move at the Kernel-level, where sophisticated protection techniques is still not very Common (indeed, things like as KASLR and SMEP is implemented only in the latest versions of the most popular OSes). This trend was also confirmed by the rising number of kernel-level vulnerabilities reported in the last few months in Windo Ws? Linux, and? Os x.following This trend, we recently looked at few OS X drivers ("KEXT" s) and found a integer signedness bug affecting s Ervice?Iobluetoothhcicontroller? (Implemented by the?iobluetoothfamily? KEXT). This vulnerability can is exploited by a local attacker to gain root privileges. The issue is present in the latest versions of OS X Mavericks (tested on 10.9.4 and 10.9.5), but have been "silently" patch Ed by Apple in OS X yosemite.vulnerability overview

In a nutshell, the bug lies in The? IOBLUETOOTHHCIUSERCLIENT::SIMPLEDISPATCHWL () ? function. The function eventually takes a user-supplied 32-bit signed integer value and uses it to index a global array of structure s containing a function pointer. The chosen function pointer is finally called. As the reader can easily imagine,? SIMPLEDISPATCHWL () ? fails at properly Sanitizing the user-supplied index, thus bad things may happen if a malicious user was able to control the chosen function Pointer.

More in detail, the vulnerable part of the function was summarized in the pseudocode below. At line, the user-supplied 32-bit integer was casted to a 64-bit value. Then, the ' if ' statement at line returns a error if the casted (signed) value is greater than the number of methods AV Ailable in the Global_sroutines ? array; Obviously, due to the signed comparison, any negative value for The?method_index ? Variable would pass this test. At line 20method_index ? was used to access the?< Span style= "font-family: ' Courier New ', Courier, monospace;" >_sroutines ? Array, and the retrieved callback is finally called on line.

1 2 3 4 5 6 7 8 91011121314151617181920212223242526

typedef struct{void(*function_pointer) (); UInt64 num_arguments;} Bluetoothmethod; Bluetoothmethod _sroutines[] = {...}; UInt64 _sroutinecount =sizeof(_sroutines)/sizeof(Bluetoothmethod); Ioreturn iobluetoothhciuserclient::simpledispatchwl (Iobluetoothhcidispatchparams *params) {//Here ' User_param ' is a signed 32-bit integer parameterInt64 method_index = (Int64) User_param;if(Method_index >= _sroutinecount) {returnkioreturnunsupported; } Bluetoothmethod method = _sroutines[method_index]; ...if(Method.num_arguments <8) {Method.function_pointer (...); } ...}

Exploitation details

Exploitation of this vulnerability was just a matter of supplying the proper negative integer value in order to MAKE? iobluetoothfamily ? Index the Global _ Sroutines ? Structure out of their bounds, and to fetch an attacker-controlled structure. The supplied value must is negative to index outside The _ Sroutines ? Structure while still satisfying the check on line.

As a foreword, consider, proof-of-concept, we disabled both Smep/smap and KASLR, so some additional voodoo Tricks is required to get a fully weaponized exploit. Thus, our approach is actually very simple:we computed a value for the user-supplied parameter this allowed us to index Abluetoothmethod ? Structure such That?bluetoothmethod.function_ptr valid User-space address (where we placed our shellcode), WhileSIMPLEDISPATCHWL () at line).

As shown in the C code fragment above, the user-supplied 32-bit value (user_param) was first casted to a 64-bit si gned value, and then used as a index in_sroutines. Each entry of the global? _sroutines? Array is 16-byte wide (8-byte values). These operations is implemented by the following assembly code:

1 2 3 4 5 6 7 8 9101112131415

; r12+70h points to the user-supplied index valuemov ecx, [R12+70h]mov r13d,kioreturnunsupportedLea RDX,_sroutinecountCMP ecx, [RDX]Jge fail; Go on and Fetch _sroutine[method_index]...Movsxd Rax,ecx ; Sign extension to 64-bit valueSHL Rax,4 ; method_index *= sizeof (Bluetoothmethod)Lea RDX,_sroutinesmov ESI, [RDX+Rax+8]; esi = _sroutines[method_index].num_argumentsCMP ESI,7 ; Check Method.num_arguments < 8ja Loc_289ba...

At a higher-level, the address of the?Bluetoothmethod? structure fetched when processing an index value "User_param"is computed by the following formula:struct_addr = (ext (user_param & 0xFFFFFFFF) * +) + _sroutine

Where? ext ()? is the sign-extension operation (implemented by the? Movsxdinstruction in the assembly code snipped above).

By solving the formula for? User_paramand searching inside the kernel address space, we found several candidate addresses that matched our C Riteria (i.e., a valid user-space pointer followed by an integer value < 8). The rest of the exploit is just a matter of? mmap ()' ing the shellcode at the proper user-space address, connecting to the? IobluetoothhcicontrollerService and invoking the vulnerable method.

The source code for a (very rough) proof-of-concept implementation of the aforementioned exploit are available?here, while The following figure shows the exploit "in action".

Execution of our "proof-of-concept" exploit

?

Patching

We verified the security issue both on OS X Mavericks 10.9.4 and 10.9.5 (MD5 hash values for The?2a55b7dac51e3b546455113505b25e75 ? and?< Span style= "font-family: ' Courier New ', Courier, monospace;" >b7411f9d80bfeab47f3eaff3c36e128f , respectively). After the release of OS X Yosemite (10.10), we noticed the vulnerability have been silently patched by Apple, with no menti On about the IT in the?security change log.

A side-by-side Comparison between versions 10.9.x and 10.10 Of?iobluetoothfamily ? Confirms Apple have patched the device driver by rejecting negative values for the user-supplied Index. In the figure below, the user-supplied index value is compared Against?_sroutinecount ? (orange basic block). Yosemite adds an additional check to ensure the (signed) index value was non-negative (green Basic block, on the right).

Comparison of the vulnerable OS X driver (Mavericks, on the left) and patched version (Yosemite, on the right)

Conclusionswe contacted Apple on October 20th, asking for their intention to back-port the security fix to OS X Mave Ricks. Unfortunately, we got no reply, so we decided to publicly disclose the details of this vulnerability:yosemite have now bee N released since a while and was available for free for Apple customers; Thus, we don ' t think the public disclosure of this bug could endanger end-users.?

Go Mac OS X Local privilege escalation (iobluetoothfamily)