Pwn2Own Winner Charlie Miller Discusses OS Security

Sunday, March 13, 2011

Anthony M. Freed


An Interview with Four-Time Pwn2Own Winner Dr. Charlie Miller

Dr. Charlie Miller is the Principal Security Analyst for the Baltimore-based security consulting firm Independent Security Evaluators (ISE), which focuses on application security and penetration testing.

His professional experience is in the field of computer attack methodology and includes identifying vulnerabilities in software and the crafting of exploits. Miller is  the author of two books, "Fuzzing for Software Security Testing and Quality Assurance" and the "Mac Hacker's Handbook".

Prior to his work with ISE, Miller spent five years as a Global Network Exploitation Analyst for the National Security Agency.

Miller has a Ph.D. from the University of Notre Dame and is a Red Hat Certified Engineer (RHCE), a GIAC Certified Forensics Analyst (GCFA), and holds a CISSP certification.

He has addressed leading industry conferences on multiple occasions, including the Workshop on the Economics of Information Security, Black Hat, and DEFCON.

Miller is also unrivaled as a four-time Pwn2Own content winner (2008-2011) where he has successfully hacked the Mac OS X using various Safari exploits, and this year he won the iPhone hacking competition.

Miller's Twitter profile probably sums up his professional bio best: "I'm that Apple 0day guy..."

I asked Dr. Miller to expound on the evolution of security features that have been incorporated into Mac OS X and iOS, to offer some insight into what we can expect from subsequent releases, and to comment on his experiences at Pwn2Own:

Q:  The myth that Apple operating systems are inherently more secure is slowly abating as Apple gains in market share and becomes a more attractive target for attackers; do you believe the relatively slow adoption of security standards like Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) was simply a matter of cost over benefit?

A: Product security is something that is very hard to measure.  Because of this, it is difficult for users to make purchasing decisions based on security and therefore companies have little incentive to spend money on it. 

Apple doesn't have a perceived security problem by customers and so they haven't had a need to invest heavily in it.  I've done what I can to try to educate people that Apple products aren't magical and can have security problems like every other product.

Q:  Can you explain how DEP differentiates between data and executable code to prevent a successful exploit?

A: Each page in memory is marked as either executable or non-executable and the processor will not allow pages marked as non-executable to execute.  In this way, the actual program and its associated libraries will run fine, but if the processor tries to execute data provided by the user (i.e. attacker), it will crash rather than "run" the data.

Q:  Return Oriented Programming (ROP) exploits can render DEP defenses ineffective; what kind of code is typically sought out and how does it work to re-purpose the code for use in an attack?

A: ROP works by reusing existing code.  By piecing together small code fragments already in memory, the attacker can do whatever they want, with enough time and patience.  However, for ROP to work, the attacker needs to know the location of the executable code in memory.

Q: If an attack is using ROP to seek out specific code, how does using Address Space Layout Randomization (ASLR) to place the code randomly in memory foil the exploit?

A: ASLR makes it impossible to do ROP in the absence of some additional vulnerability.  The attacker cannot predict where the code fragments they want to reuse are located.  ASLR and DEP together are very difficult to bypass.  The OS knows where the code is because it can read from memory and figure it out. 

Typically, an attacker cannot do this without an additional bug.  So ASLR and DEP together means an attacker typically needs to know two vulnerabilities in order to get their code to run.

Q: Windows has used ASLR since the release of Vista in 2007, but Apple has only partial ASLR in Leopard and Snow Leopard; what can be deduced from the company's decision to only partially implement the security measure?

A: I guess the only conclusion you can draw is that these security measures are not a priority for them.  However, when Lion comes out this summer, it will give them a chance to have full ASLR and DEP, we'll see if they take advantage of it or not.

Q:  Did you capitalize on the vulnerability presented by partial ASLR implementation in your successful exploits at Pwn2Own?

A: Yes, I used ROP and used the fact that I knew where all the code was located.  It would have been significantly harder had the phone had ASLR.

Q:  Windows Phone 7 has full ASLR and DEP, yet iPhone has no ASLR at all; if an argument could be made in the past about market share and the need for security features for the Mac OS, is there any excuse is for the iOS?

A: So, this has changed.  In the newest version of iOS, released just this week, (4.3), they have implemented ALSR.  So, now iPhone has full ASLR and DEP joining Windows Phone 7 as the only phones with this protection.  iPhone has slowly been evolving security. 

For the first year (2007) it was horribly insecure.  Since then it has been much better, but still lacked DEP.  Now it seems to be downright well designed.

Q:  Does this lead you to believe that the Mac OS X Lion may also have full ASLR when released?

A: I sure hope so.  If it has full ASLR, it will be a huge improvement over Snow Leopard.

Q:  Apple definitely seems to be putting more focus on security; is that the reason why Apple is letting researchers look at the beta of Mac OS X Lion?

A: Traditionally Apple has more or less ignored the security industry.  They don't sponsor conferences or bring in researchers to talk with them.  The fact they are beginning to reach out is a very positive sign that they think they want our input.

Q:  Pwn2own is offering more in cash prizes for successful hacks than ever before; you mentioned to me in an email that you had decided not to compete this year - can you tell us why?

A: Actually, I changed my mind, competed and won this year against the iPhone ;)

Q:  A recent article in Computerworld quoted you as being critical of the competition for encouraging the "weaponization" of exploits en masse - can you briefly reiterate your concerns?

A: This is still a concern for me.  There is a difference between vulnerabilities and exploits.  The former are problems that need to be patched.  But an exploit is something that can actually take advantage of the vulnerability to get code running on the system.  The biggest difference is that a bad guy can't do anything with knowledge of a vulnerability by itself, a bad guy needs an exploit. 

Normally, researchers report vulnerabilities and don't bother to actually write exploits.  Writing an exploit is hard, time consuming work and doesn't help the vendor's patch the bug, so isn't necessary to make. 

However, at pwn2own, you need an exploit that works reasonably well if you hope to win.  But, not everyone get's a chance to win, even if they have an exploit.  For each target the names of the people who want to compete are drawn at random.  For example, for Safari on OS X this year, 4 people signed up. 

After the random drawing, I was fourth in line.  So, four of us showed up with Safari exploits, but the first team won (from VUPEN).  Now, the contest is over for that target and there are three of us with exploits but nothing to do with them.

Q:  Companies increasingly utilize a bounty system to encourage the exposing of critical vulnerabilities - is this the best system?

A: Bug bounties are a great idea.  More companies are starting to do this and I hope this trend continues.  Traditionally, companies rewarded researchers for their efforts only by putting their name in an advisory. 

However, for established researchers like myself, this isn't much motivation.  Adding another advisory to my resume isn't very useful at this point in my career.  This reward is mostly only useful to researchers who are new to the field. But you really want the most experienced researchers hunting for bugs to help clean up all the problems. 

Bug bounties provide another incentive that works for everybody.  Plus, from the vendor's perspective it makes sense.  They want to have a secure product and the amount they pay in bug bounties actually saves them money from having to release emergency patches when problems become publicly exploited. 

I just hope the amount of the bounties continue to increase as bugs become harder to find.

Q:  Will you continue to compete in Pwn2Own in the future?

A: I really like the concept of Pwn2Own.  It gives researchers a chance to demonstrate their skills and make some money.  Since all the bugs are reported, it also gets patches produced which reduce the number of bugs in the products we all use.  I really think it's a win-win for everyone. 

As for whether I'll compete again next year, we'll have to wait and see.  It takes a lot of time to prepare and it can be quite stressful.  This year, my collaborator Dion Blazakis and I didn't finish the exploit until the night before the contest and were still testing it the morning the contest began.  Those were some sleepless nights!

Q:  Anything else you would like to add?

A: Vendors care about their customers and keeping them happy.  Make sure when you are making purchasing decisions, that you let them know that your choice depends on the security of the product and that you'll buy other products if they seem more secure.  Money talks.

Possibly Related Articles:
Operating Systems
Operating Systems Pwn2Own DEP ASLR ROP Mac OS X iOS Charlie Miller
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.