Introduction to iOS Platform Security

This if the first in a series of blog posts about iOS and iOS platform security, encompassing and expanding on the MDSec iOS Application (In)Security whitepaper.
In this post, MDSec provides some background information on the iOS platform and a brief introduction to the core security features of iDevices.

The core security features of the iOS platform can be summarised as:

  • Code Signing
  • Generic native language exploit mitigations
    • Address Space Layout Randomisation
    • Non executable memory
    • Stack Smashing Protection
  • Process level sandboxing
    • Also known as Seat Belt
  • Data at rest encryption

A comprehensive review of these features can be found within the whitepaper “Apple iOS 4 Security Evaluation” by Dino Dai Zovi [1] which provided much of the foundation for the details discussed.

Code Signing

Code signing is a runtime security feature of the platform that attempts to prevent unauthorised applications running on the device by validating the application signature each time it is executed. Additionally, applications may also only execute code signed by a valid, trusted signature.

For an application to be run on the device, it must first be signed by a trusted certificate. Developers can install trusted certificates on a device through a provisioning profile signed by Apple. The provisioning profile contains the embedded developer certificate and set of entitlements that the developer may grant to applications. In production applications, all code must be signed by Apple, this is performed during the AppStore submission process. This process allows Apple some degree of control over apps and to govern the APIs and functionality used by developers. For example, Apple looks to prevent apps using private APIs or downloading to installing executable code [2].

Exploit Mitigation Features

Address Space Layout Randomisation (ASLR) [3] is a security feature that attempts to increase the complexity of vulnerability exploitation by randomising where data and code is mapped in a processes address space. ASLR was first introduced to iOS in version beta 4.3 and since inception has gradually improved with each release. The primary weakness in the ASLR implementation was the lack of relocation of the dyld, this was addressed with the release of iOS 5.0. Applications can have ASLR applied in two different flavours, either partial ASLR or full ASLR depending on whether they have been compiled with support for Position Independent Execution (PIE). In a full ASLR scenario, all the application memory regions are randomised and iOS will load a PIE enabled binary at a random address each time it is executed. An application with partial ASLR will load the base binary at a fixed address and use a static location for the dynamic linker (dyld). An in-depth assessment of ASLR in iOS has been conducted by Stefan Esser and is recommended reading for those looking to gain a greater understanding [4].

ASLR is designed to frustrate exploitation due to the lack of knowledge an attacker will have of the process layout in memory and thus the addresses they need to target. However, there are a number of techniques that can weaken its effectiveness. The most common of these techniques is memory revelation. This is where a separate vulnerability is used to leak or confirm memory layout to an attacker prior exploitation of a vulnerability that will yield arbitrary code execution.

In an attempt to further mitigate exploitation of native language vulnerabilities, iOS combines ASLR with the implementation of a “W^X” non-executable memory policy, meaning that memory pages cannot be marked as writeable and executable at the same time. As part of this policy, executable memory pages that are marked as writeable cannot also be later marked back to executable. In many ways this is similar to the Data Execution Protection (DEP) features implemented by Microsoft Windows, Linux and Mac OS X desktop OS’. While non-executable memory alone can be trivially bypassed using Return Orientated Programming (ROP) based payloads, the complexity of exploitation is significantly increased when compounded with ASLR and Mandatory Code Signing.

iOS applications can look to add additional exploit mitigation at compile time through stack smashing protection. Stack canaries in particular introduce some protection against buffer overflows by placing a random, known value before the local variables. The stack canary is checked upon return of the function. If an overflow occurs and the canary is corrupted, the application is able to detect and protect against the overflow.


All third party applications on iOS run within a sandbox; this is a self-contained environment that isolates applications not only from other applications but also the operating system. While applications all run as the “mobile” operating system user, they are contained within a unique directory on the filesystem and separation is maintained by the XNU Sandbox kernel extension.  The operations that can be performed in the sandbox are governed by the seatbelt profile. Third party applications are assigned the “container” profile which will generally limit file access to the application home directory, allow read access to media, read and write to the address book as well as unrestricted access to outbound network connections, with the exception of launchd’s network sockets. See “The Apple Sandbox” [5] for recommended further reading.


By default, all data on the iOS filesystem is encrypted using block-based encryption (AES) with the File System Key, which is stored on the flash. The filesystem is encrypted only at rest; when the device is turned on the hardware based crypto accelerator unlocks the filesystem.

In addition to the hardware encryption, individual files and keychain items can be encrypted using the Data Protection (DP) API that uses a key derived from the device passcode. Consequently, when the device is locked, content encrypted using the DP API will be inaccessible unless cached in memory. Third party applications wishing to encrypt sensitive data should employ the Data Protection API to do so. However consideration should be given for background processes how they will behave if the at-rest becomes unavailable due to the device becoming locked.


[1] Apple iOS 4 Security Evaluation – Dino Dai Zovi

[2] iOS Standard Agreement

[3] Address Space Layout Randomization

[4] Steffan Esser’s ASLR Research

[5] Apple Sandbox – Dionysus Blazakis

written by

MDSec Research

Ready to engage
with MDSec?

Copyright 2021 MDSec