|
The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "ASLR"
m (→Kernel space ASLR: add link to Kernel ASLR) |
m (Updatin) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | '''ASLR''' (Address Space Layout Randomization) is a form of data security used to randomize data on the RAM to help prevent exploits from taking control of the system. It first appeared in [[wikipedia:iOS version history#4.3|iOS 4.3]]. |
+ | '''ASLR''' ('''Address Space Layout Randomization''') is a form of data security used to randomize data on the RAM to help prevent exploits from taking control of the system. It first appeared in [[wikipedia:iOS version history#4.3|iOS 4.3]]. |
== Program and dyld == |
== Program and dyld == |
||
* On program load, the address space offset of the program is randomized between 0x0 and 0x100000 |
* On program load, the address space offset of the program is randomized between 0x0 and 0x100000 |
||
| + | ** Deployment target must be [[iOS]] 4.3 or higher |
||
* It always falls on a 0x1000 page boundary |
* It always falls on a 0x1000 page boundary |
||
| + | ** 0x100 possible pages |
||
* dyld is included in this sliding section |
* dyld is included in this sliding section |
||
| + | |||
| + | == Changes in iOS 5 == |
||
| + | In [[iOS]] 5, Apple fixed a major weakness in [[dyld]]: All dynamic libraries are "slid" around in memory on load regardless of the main binary's deployment target. However, the dylib is slid the same amount as the main binary. To exploit this, the use of only 256 possible pages to be loaded on was used. A simple loop looking for an info leak was used. |
||
== [[Kernel ASLR|Kernel space ASLR]] == |
== [[Kernel ASLR|Kernel space ASLR]] == |
||
| − | Mountain Lion boasts a xnu 2150 kernel, which includes, for the first time, [[Kernel ASLR|ASLR in kernel space]]. Because OS X and iOS are so closely tied together, as previously surmised here, iOS 6. |
+ | Mountain Lion boasts a xnu 2150 kernel, which includes, for the first time, [[Kernel ASLR|ASLR in kernel space]]. Because OS X and iOS are so closely tied together, as previously surmised here, iOS 6.0 beta 1 (XNU 2107.1.78) indeed includes [[Kernel ASLR|ASLR]]. |
This is the lowdown of [[Kernel ASLR|ASLR]]: |
This is the lowdown of [[Kernel ASLR|ASLR]]: |
||
* When the kernel boots, i386_vm_init (iOS: arm_vm_init) initializes the value of vm_kernel_slide |
* When the kernel boots, i386_vm_init (iOS: arm_vm_init) initializes the value of vm_kernel_slide |
||
| − | * The kernel supports a new system call (#439 on Mountain Lion, likely #440 on iOS 6), called kas_info. This will return the value of vm_kernel_slide, but only for a privileged process. Update for |
+ | * The kernel supports a new system call (#439 on Mountain Lion, likely #440 on iOS 6), called kas_info. This will return the value of vm_kernel_slide, but only for a privileged process. Update for beta 3: Apple probably realized how stupid this is, and so the syscall (at 0x8021C9E8 on 6.0 beta 3, [[N81AP]]) returns 0x2D (ENOTSUP). |
* kld is updated to reflect the slide in symbols. Likewise OSKext::LoadExecutable and friends |
* kld is updated to reflect the slide in symbols. Likewise OSKext::LoadExecutable and friends |
||
* stackshot and other kernel functions take the vm_kernel_slide into consideration and subtract it from the actual positions of functions/symbols. |
* stackshot and other kernel functions take the vm_kernel_slide into consideration and subtract it from the actual positions of functions/symbols. |
||
| Line 20: | Line 25: | ||
== dyld_shared_cache == |
== dyld_shared_cache == |
||
| − | * The system libraries are now stored in a big cache file |
+ | * The system libraries are now stored in a big cache file |
* This address randomized at boot time, in many possible places, higher in the address space than the program |
* This address randomized at boot time, in many possible places, higher in the address space than the program |
||
| − | * The functions retain a fixed offset to each other |
+ | * The functions retain a fixed offset to each other |
== External Links == |
== External Links == |
||
Latest revision as of 09:38, 11 October 2015
ASLR (Address Space Layout Randomization) is a form of data security used to randomize data on the RAM to help prevent exploits from taking control of the system. It first appeared in iOS 4.3.
Contents
Program and dyld
- On program load, the address space offset of the program is randomized between 0x0 and 0x100000
- Deployment target must be iOS 4.3 or higher
- It always falls on a 0x1000 page boundary
- 0x100 possible pages
- dyld is included in this sliding section
Changes in iOS 5
In iOS 5, Apple fixed a major weakness in dyld: All dynamic libraries are "slid" around in memory on load regardless of the main binary's deployment target. However, the dylib is slid the same amount as the main binary. To exploit this, the use of only 256 possible pages to be loaded on was used. A simple loop looking for an info leak was used.
Kernel space ASLR
Mountain Lion boasts a xnu 2150 kernel, which includes, for the first time, ASLR in kernel space. Because OS X and iOS are so closely tied together, as previously surmised here, iOS 6.0 beta 1 (XNU 2107.1.78) indeed includes ASLR.
This is the lowdown of ASLR:
- When the kernel boots, i386_vm_init (iOS: arm_vm_init) initializes the value of vm_kernel_slide
- The kernel supports a new system call (#439 on Mountain Lion, likely #440 on iOS 6), called kas_info. This will return the value of vm_kernel_slide, but only for a privileged process. Update for beta 3: Apple probably realized how stupid this is, and so the syscall (at 0x8021C9E8 on 6.0 beta 3, N81AP) returns 0x2D (ENOTSUP).
- kld is updated to reflect the slide in symbols. Likewise OSKext::LoadExecutable and friends
- stackshot and other kernel functions take the vm_kernel_slide into consideration and subtract it from the actual positions of functions/symbols.
- Disassembly is somewhat harder. Rather than store addresses of symbols and strings at the end of each function (DCD), the symbols/string offsets with respect to PC are now hardcoded in the instructions themselves, and need to be calculated.
An upcoming book on OS X/iOS internals discusses this in detail.
- The system libraries are now stored in a big cache file
- This address randomized at boot time, in many possible places, higher in the address space than the program
- The functions retain a fixed offset to each other
External Links
- ASLR on Wikipedia
- ASLR in the dyld on the iPhone Dev Wiki
