Protect Your Assets
Showing results for 
Search instead for 
Do you mean 

What Your Binary Says About You, Part 2: I'm Not Worried About Exploits!

dawnisabel ‎12-13-2013 11:31 AM - edited ‎08-03-2015 10:48 AM

In the first installment of this series, we saw how source paths can be leaked by iOS binaries and which Xcode settings can be used to suppress them.  Source paths can reveal concrete details about the development environment for a binary, like the developer’s username.  Your binary might also make more subtle statements about you to an attacker if you fail to enable some straightforward settings during development.  Given that these are common-sense protections, a binary that doesn’t have them will stand out in the crowd (and not in a good way). 


I'm predictable, and that's why attackers like me


In iOS 4.3, Address Space Layout Randomization (ASLR) was introduced to protect against exploits that expect application elements to reside at predictable addresses in memory.  ASLR on iOS randomizes the locations of an application’s heap and libraries by default.  However, this still leaves other key elements mapped to fixed locations, including the application binary, data, stack, and dynamic linker.  In order to maximize the benefit of ASLR, an application has to be compiled with the Position-Independent Executable (PIE) flag.  A binary with the PIE flag set can be loaded from a random memory location, which enables randomization of the elements that were previously fixed.  If you are wondering just how much of a difference this makes, check out Dino Dai Zovi’s “Apple iOS 4 Security Evaluation” white paper from 2011.  It shows the extent of ASLR randomization in action both with and without PIE enabled on iOS 4.3, and it is eye-opening!


How can you tell if a binary has been compiled with the PIE flag?  With Apple’s otool, you can easily dump the Mach-O headers for an iOS binary in human-readable format.  A binary compiled with the PIE flag will be pretty obvious:


Hint: Look for the part that says “PIE”


If you didn’t find any PIE in your binary’s headers, fear not!  Apple provides a Technical Q&A with a walkthrough of how to enable PIE, assuming that you are targeting iOS 4.3 or later.


If I don't see it, it didn't happen


ASLR approaches buffer overflow protection by making it harder for attackers to predictably locate application elements in memory.  For stack-based buffer overflows, applying stack-smashing protection to the binary enables a second approach: detecting the overflow so that exploitation can be prevented.  Stack-smashing protection works by placing a random "canary" value on the stack when a function is called, between any local variables and the return pointer.  Right before the function returns, the canary is validated.  If the stack is corrupted by a buffer overflow, the canary will likely be overwritten and the check will fail, alerting the application to the attack.  Obviously this is a very high-level explanation; for more information, Oliver Mueller's "Anatomy of a Stack Smashing Attack" is a great resource for understanding the technical details around protecting the stack.


We can use otool to check if an application is compiled with stack-smashing protection by dumping the symbols from the binary and searching for the telltale symbols stack_chk_guard and stack_chk_fail:



Inclusion of these symbols indicate that stack-smashing protection is enabled.  If you came up empty when you tried this on your own binary, check the "Other C Flags" setting in Xcode; it should include the flag -fstack-protector-all:


 I've heard that later versions of Xcode enable stack-smashing protection by default, but unfortunately could not find details on which versions do this.  If you have more information, or would like to share your own tips for configuring Xcode to protect binaries against attack, leave a comment below!




0 Kudos
About the Author


Tony Hammond
on ‎12-14-2013 07:49 AM

This is a wonderful article and I really appreciate you for sharing it.  I am working on iOS and this is a huge help.

on ‎12-17-2013 04:52 AM
Thanks, Tony! I'm glad that it was helpful. I would be really interested in hearing what other appsec topics would be most useful to developers, if you have any thoughts!
27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all