The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information.

Difference between revisions of "ASLR"

From The iPhone Wiki
Jump to: navigation, search
(→‎Kernel space ASLR)
m (Updatin)
 
(9 intermediate revisions by 4 users not shown)
Line 1: Line 1:
−
'''ASLR''' (Address Space Layout Randomization) is a form of data security used to randomize data on the {{wp|Random Access Memory|RAM}} to help prevent exploits from taking control of the system. It first appeared in {{wp|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
   
−
== Kernel space ASLR ==
 +
== 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]] ==
−
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, it is safe to assume that iOS 6 (which is not yet released at the time of this writing, but will probably have a greater equal version of XNU) will likely have ASLR. In reply to i0nic, this is the lowdown of 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.0 beta 1 (XNU 2107.1.78) indeed includes [[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 beta 3: Apple probably realized how stupid this is, and so the syscall (at 0x8021C9E8 on 6.0 beta 3, [[N81AP]]) returns 0x2D (ENOTSUP).
−  
−
* 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.
  
−  
 
* 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.
  +
* 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.
  
An upcoming book on OS X/iOS internals discusses this in detail.
   
 
== dyld_shared_cache ==
  
== dyld_shared_cache ==
−
* The system libraries are now stored in a big cache file, see
+
* 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 ==
−
* {{wp|Address space layout randomization|ASLR}} on Wikipedia
 +
* [[wikipedia:Address space layout randomization|ASLR]] on Wikipedia
 
* [http://www.iphonedevwiki.net/index.php/Dyld_shared_cache ASLR in the dyld] on the iPhone Dev Wiki
  
* [http://www.iphonedevwiki.net/index.php/Dyld_shared_cache ASLR in the dyld] on the iPhone Dev Wiki

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.

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.

dyld_shared_cache

  • 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

Retrieved from "https://www.theiphonewiki.com/w/index.php?title=ASLR&oldid=48715"