|
The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "ARM Exception Vector Info Leak"
(mention second info leak) |
m (→References: mention ATV link too) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | This is CVE-2013-0978. |
||
| − | This vulnerability is used by [[evasi0n]] in order to defeat [[Kernel ASLR|KASLR]]. Since iOS6 the kernel base address is randomized at 2^9 possible locations. Actually it is not fully randomized due to the ARM vector table residing at a fixed address. The vector table is held at address zero and at runtime relocated to <code>0xffff0000</code> by setting the V-bit in CP15 c1. The following ARM vector table entries exist: |
||
| + | This vulnerability is used by [[evasi0n]] in order to defeat [[Kernel ASLR|KASLR]]. Since iOS6 the kernel base address is randomized at 2<sup>9</sup> possible locations. Actually it is not fully randomized due to the ARM vector table residing at a fixed address. The vector table is held at address zero and at runtime relocated to <code>0xffff0000</code> by setting the V-bit in CP15 c1. The following ARM vector table entries exist: |
||
{| class="wikitable" style="text-align:center;" |
{| class="wikitable" style="text-align:center;" |
||
|- |
|- |
||
| Line 33: | Line 34: | ||
In the exception handler it is also possible to get 4 bytes at a chosen address, so this is additionally an info leak for arbitrary memory. |
In the exception handler it is also possible to get 4 bytes at a chosen address, so this is additionally an info leak for arbitrary memory. |
||
| + | |||
| + | Apple's description in the iOS 6.1.3 security fixes: |
||
| + | |||
| + | <cite> |
||
| + | '''Kernel'''<br/> |
||
| + | Impact: A local user may be able to determine the address of structures in the kernel<br/> |
||
| + | Description: An information disclosure issue existed in the ARM prefetch abort handler. This issue was addressed by panicking if the prefetch abort handler is not being called from an abort context. |
||
| + | </cite> |
||
== References == |
== References == |
||
* [http://blog.azimuthsecurity.com/2013/02/from-usr-to-svc-dissecting-evasi0n.html Analysis by kernelpool] |
* [http://blog.azimuthsecurity.com/2013/02/from-usr-to-svc-dissecting-evasi0n.html Analysis by kernelpool] |
||
| + | * [http://support.apple.com/kb/HT5704 Apple's iOS 6.1.3 security fixes] |
||
| + | * [http://support.apple.com/kb/HT5702 Apple's iOS 5.2.1 (Apple TV) security fixes] |
||
| + | * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0978 NIST Reference CVE-2013-0978] |
||
| + | * [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0978 Mitre Reference CVE-2013-0978] |
||
[[Category:Exploits]] |
[[Category:Exploits]] |
||
Latest revision as of 23:10, 6 April 2013
This is CVE-2013-0978.
This vulnerability is used by evasi0n in order to defeat KASLR. Since iOS6 the kernel base address is randomized at 29 possible locations. Actually it is not fully randomized due to the ARM vector table residing at a fixed address. The vector table is held at address zero and at runtime relocated to 0xffff0000 by setting the V-bit in CP15 c1. The following ARM vector table entries exist:
| Offset | Handler |
|---|---|
00
|
Reset |
04
|
Undefined Instruction |
08
|
Supervisor Call (SVC) |
0C
|
Prefetch Abort |
10
|
Data Abort |
14
|
Reserved |
18
|
Interrupt (IRQ) |
1C
|
Fast Interrupt (FIQ) |
evasi0n calls the Data Abort exception from a separate thread and catches the exception. In the exception handler, in_state->__pc is saved to global.exception_pc and leaks the base address because this exception was called from com.apple.iokit.IOUSBDeviceFamily.
In the exception handler it is also possible to get 4 bytes at a chosen address, so this is additionally an info leak for arbitrary memory.
Apple's description in the iOS 6.1.3 security fixes:
Kernel
Impact: A local user may be able to determine the address of structures in the kernel
Description: An information disclosure issue existed in the ARM prefetch abort handler. This issue was addressed by panicking if the prefetch abort handler is not being called from an abort context.
