Switch branches/tags
Nothing to show
Find file History
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
..
Failed to load latest commit information.
README.md
crash-issue1.c
crash-issue2.c
crash-issue3.c
lpe-issue1.c

README.md

Multiple LPE vulnerabilities in Yosemite (10.10.1)

  • Authors: Aristide Fattori (@joystick) and Roberto Paleari (@rpaleari)
  • Release date: 12/01/2015
  • Status: Fixed in OS X 10.10.2

Full details in our blog post.

Issue 1

crash_issue1.c

Many callback routines handled by IOBluetoothHCIController blindly dereference pointer arguments without checking them. The caller of these callbacks, IOBluetoothHCIUserClient::SimpleDispatchWL(), may actually pass NULL pointers, that are eventually dereferenced. Such dereferences can be exploited to perform full LPE attacks by mapping page 0.

Issue 2

crash_issue2.c

IOBluetoothHCIController::BluetoothHCIChangeLocalName() is affected by an "old-school" stack-based buffer overflow, due to a bcopy(src, dest, strlen(src)) call where src is fully controlled by the attacker. To the best of our knowledge, this bug cannot be directly exploited due to the existing stack canary protection. However, it may still be useful to mount a LPE attack if used in conjunction with a memory leak vulnerability, leveraged to disclose the canary value.

Issue 3

crash_issue3.c

IOBluetoothHCIController::TransferACLPacketToHW() receives as an input parameter a pointer to an IOMemoryDescriptor object. The function carefully checks that the supplied pointer is non-NULL; however, regardless of the outcome of this test, it later dereferences the pointer. The IOMemoryDescriptor object is created by the caller (DispatchHCISendRawACLData()) using the IOMemoryDescriptor::withAddress() constructor. As this constructor is provided with a user-controlled value, it may fail and return a NULL pointer.

Issue 4

lpe_issue1.c

This issue is due to a missing sanity check on the arguments of the following function:

IOReturn BluetoothHCIWriteStoredLinkKey(
						   uint32_t req_index,
						   uint32_t num_of_keys,
						   BluetoothDeviceAddress *p_device_addresses,
						   BluetoothKey *p_bluetooth_keys,
						   BluetoothHCINumLinkKeysToWrite *outNumKeysWritten);

The first parameter, req_index, is used to find an HCI Request in the queue of allocated HCI Requests (thus this exploit requires first to fill this queue with possibly fake requests). The second integer parameter (num_of_keys) is used to calculate the total size of the other inputs, respectively pointed by p_device_addresses and p_bluetooth_keys. No sanity checks are performed over these two paramters, leading to an overflow over the vtable of a HCI Request object, easily exploitable to mount a LPE attack.