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

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:

 

Detecting PIE with otool

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:

 

Detecting stack protection with otool

 

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:

 

Xcode stack-smashing settings

 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!

 

 

 

Comments
Tony Hammond(anon) | ‎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.

dawnisabel | ‎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!
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.