Kernel ASLR - Revision history

Winocm at 18:07, 13 August 2013

2013-08-13T18:07:11Z

Http: /* Attacks */ mention vulnerability used in evasi0n

2013-02-25T23:12:51Z

‎Attacks: mention vulnerability used in evasi0n

Http: /* Attacks */ mention 6.0.1 fix

2012-11-11T12:48:31Z

‎Attacks: mention 6.0.1 fix

Http: /* Kernel Image */ fix disambiguation link

2012-10-16T23:32:08Z

‎Kernel Image: fix disambiguation link

Http: initial page with some infos from mdowd's presentation

2012-10-16T23:28:26Z

initial page with some infos from mdowd's presentation

New page

The goal of Kernel ASLR is to prevent an attacker from modifying or utilizing (kernel) data at known (fixed) addresses. The strategy to implement this is two-fold:
*Randomize the kernel image base
*Randomize the base of the <code>kernel_map</code> in some sense

===Kernel Image===
The kernel image base is randomized by the boot loader ([[iBoot]]). This is done by creating random data, doing a SHA-1 hash of it and then using a byte from the SHA-1 hash for the kernel slide. The slide is calculated with this formula:

base=0x01000000+(slide_byte*0x00200000)

If the slide is 0, the static offset of 0x21000000 is used instead.

The adjusted base is passed to the kernel in the boot arguments structure at offset <code>0x04</code>.

===Kernel Map===
The kernel map is used for kernel allocations of all types (<code>kalloc()</code>, <code>kernel_memory_allocate()</code>, etc.) and spans all of kernel space (<code>0x80000000</code>-<code>0xFFFEFFFF</code>). The kernel based maps are submaps of the <code>kernel_map</code>, for example <code>zone_map</code>, <code>ipc_kernel_map</code>, etc.

The strategy is to randomize the base of the <code>kernel_map</code>. A random 9-bit value is generated right after <code>kmem_init()</code> which establishes <code>kernel_map</code>, is multiplied by the page size. The resulting value is used as the size for the initial <code>kernel_map</code> allocation. Future <code>kernel_map</code> (and submap) allocations are pushed forward by a random amount. The allocation is silently removed after the first garbage collection and reused. This behaviour can be overridden with the "<code>kmapoff</code>" boot parameter.

===Attacks===
Leaking the kernel base is really useful. <code>Kext_request()</code> allows applications to request information about kernel modules, divided into active and passive operations. Active operations (load, unload, start, stop, etc.) require root access. iOS removes the ability to load kernel extensions. Passive operations were originally (before iOS6) unrestricted and allowed unprivileged users to query kernel module base addresses. iOS6 inadvertently removed some limitations; only the load address requests are disallowed. So we can use <code>kKextRequestPredicateGetLoaded</code> to get load addresses and mach-o header dumps. The load address and mach-o segment headers are obscured to hide the ASLR slide, but mach-o section headers are not. This reveals the virtual addresses of loaded kernel sections.

==References==
*[[ASLR]]
*[http://conference.hackinthebox.org/hitbsecconf2012kul/materials/D1T2%20-%20Mark%20Dowd%20&%20Tarjei%20Mandt%20-%20iOS6%20Security.pdf Mark Dowd & Tarjei Mandt's iOS6 presentation at HITB 2012 KUL D1T2]

← Older revision		Revision as of 23:12, 25 February 2013
Line 21:		Line 21:

	This information leak has been closed with iOS 6.0.1.		This information leak has been closed with iOS 6.0.1.
		+
		+	See also [[ARM Exception Vector Info Leak]] from the [[evasi0n]] jailbreak.

	==References==		==References==

@@ Line 10: / Line 10: @@
 If the slide is 0, the static offset of 0x21000000 is used instead.
-The adjusted base is passed to the kernel in the boot arguments structure at offset <code>0x04</code>.
+The adjusted base is passed to the kernel in the boot arguments structure at offset <code>0x04</code>, which is equivalent to gBootArgs->virtBase.
 ===Kernel Map===

@@ Line 19: / Line 19: @@
 ===Attacks===
 Leaking the kernel base is really useful. <code>Kext_request()</code> allows applications to request information about kernel modules, divided into active and passive operations. Active operations (load, unload, start, stop, etc.) require root access. iOS removes the ability to load kernel extensions. Passive operations were originally (before iOS6) unrestricted and allowed unprivileged users to query kernel module base addresses. iOS6 inadvertently removed some limitations; only the load address requests are disallowed. So we can use <code>kKextRequestPredicateGetLoaded</code> to get load addresses and mach-o header dumps. The load address and mach-o segment headers are obscured to hide the ASLR slide, but mach-o section headers are not. This reveals the virtual addresses of loaded kernel sections.
 ==References==

@@ Line 4: / Line 4: @@
 ===Kernel Image===
-The kernel image base is randomized by the boot loader ([[iBoot]]). This is done by creating random data, doing a SHA-1 hash of it and then using a byte from the SHA-1 hash for the kernel slide. The slide is calculated with this formula:
+The kernel image base is randomized by the boot loader ([[iBoot (Bootloader)|iBoot]]). This is done by creating random data, doing a SHA-1 hash of it and then using a byte from the SHA-1 hash for the kernel slide. The slide is calculated with this formula:
  base=0x01000000+(slide_byte*0x00200000)