Address Space Layout Randomization (ASLR) on iOS
Since launch of iPhone, Apple does continuously improve it’s OS security. One of the big steps was introduction of missing support for Address Space Layout Randomization (ASLR). This came with iOS 4.3 back in 2010.
What is ASLR?
A technique employed by the OS to make the successful exploitation of a software bug much more difficult. By ensuring memory addresses and offsets are unpredictable, exploit code can’t hard code these values.
Back in 2010, it was then possible to build an app with ASLR support, but it was not a default setting on XCode. And I beleive, the only one apps that was using this was only natives Apple apps at the exception of some few 3rd party ones.
Use ASLR is just an XCode build option
It’s only later one with iOS 5 end of 2011 that XCode default settings on new projects was out of the box compiling apps as so called Position Independent Executables (PIE). So now, the position of all system apps and libraries are randomized, along with all third-party apps compiled as position-independent executables.
See Apple Technical Q&A QA1788 on how to build a Position Independent Executable binary.
The thing is that in theory all apps are now PIE-Binary apps. But in fact this is not quite true and it’s actually the all point of this article!
iOS apps firstly created before 2012 might need update
In fact all XCode projects that were initiated before iOS 5 (very end of 2011) have the default settings that does not generate PIE-Binary at compilation time. So even if you have recently updated your app (using XCode prior to 4.6.3) it should sit in the AppStore as a non PIE-Binary.
It seems that Apple have added an explicit change of this settings if you launch an old XCode project from XCode version starting at 4.6.3. Meaning that from XCode 4.6.3 your app will by default be PIE-Binary.
If you have started your project development from a fresh “new project” on XCode starting to 4.2 (after Oct 12 2011), it might be possible that the app is compiled as a PIE-Binary. Watch out: sometimes you might think that your first app version was submitted somewhere in 2012 where first XCode project creation could have been started end of 2011 on the wrong XCode version …
In any cases, the best way to check if your app have been build as a PIE-Binary or not is to check it with:
otool -hv /path/to/MyApp.app/MyApp
In short:
created new xcode project on XCode 4.2 or greater (after Oct.12 2011): you most likely have a PIE-Binary app.
created new xcode project before Oct. 12 2011: you most likely have a non PIE-Binary app (even if updated since then).
opened any xcode project since XCode 4.6.3: you most likely have a PIE-Binary app.
But why would we care now about ASLR or PIE-Binary?
Apple have recently announce iOS 7. And one of the major change in iOS 7 is Multitasking mode for all.
So, while your app will be opened, you will have potentially all other opened apps that would have an opportunity to exploit your weakness at the same time.
I’m not sure how easy it would be to do so for a malicious app, but what I’m sure of is that if you have an app with sensitive info, authentication or premium content, you might want to make sure it’s a PIE-Binary one.
It’s even a good move to force update of any of your existing apps that are not yet PIE-Binary!
Discuss this topic on Hacker News …