Behind Pwn2Own: Exclusive Interview With Charlie Miller

The Truth Behind Pwn2Own

Alan: I see. So someone with a Web application might come to your company to make sure that their user authentication is robust or that their code won’t allow arbitrary queries to be made to the SQL database? 

Charlie: Sure, that is one type of customer ISE has. Another might have a desktop application that they want to make sure isn’t going to get hacked or they might want to make it tamper-resistant to hackers.

Alan: Without going into the details, what would be the silliest, most obvious, and most catastrophic error you’ve ever caught during your code review?

Charlie: Well, none of them are silly because some companies/developers don’t have security training, which is why they hire us. As for the most obvious/catastrophic, I’ve found command injection vulnerabilities that allowed me to execute code on a client’s server within a few minutes.

Alan: Well, let’s get to the part our readers will want to hear the most about. When people hear about Pwn2Own and systems failing within seconds, many imagine a Hollywood-esque free-for-all, with rows upon rows of teams trying to hack a single system (like the scene from Transformers). In truth, Pwn2Own is a lot more civilized and structured, isn't it?  How does this compare to other security challenges?

Charlie: Yes, I took down the Mac in under a minute each time. However, this doesn't show the fact that I spent many days doing research and writing the exploit before the day of the competition. It only looks Hollywood because you don't see the hard work in the preparation. If you set me down in front of an application I've never seen before and told me I have 2 minutes to hack it, as is often the case in movies, I'd have no more luck than your grandma at accomplishing it. Well, maybe a little more of a chance, but not much!

As for comparing this to other competitions, most other competitions face teams of hackers against programs written for the contest with bugs purposely added. I like Pwn2Own because its against real software and the bugs found are real bugs and are given to the vendors to fix, so some good comes out of it too.

Alan: I hadn’t realized that Pwn2Own was one of the few contests to employ real software. I completely agree--if you’re intentionally placing bugs, it’s nothing more than a Where’s Waldo puzzle. With enough teams trying, someone will guess the bug that’s been added. Historically, most of the criticism behind “hacking contests” was that it did not reflect realistic conditions. Company XYZ would claim “our firewall is 100% secure. We’ll give $100 to anyone who can crack our system as Trade Show ABC.” Of course, by the time the trade show was over, the system wasn’t cracked. Obviously, the company will fail to mention that no one tried because the $100 reward wasn’t worth the effort.

Charlie: Right. That is true at Pwn2Own partially too. Mac bugs aren’t really valuable, but while $5,000 is a lot of money, it’s really not that much when you consider what a bad guy could make with an exploit for an unknown vulnerability in, say, IE 8 running on Vista. The one thing other contests do test that Pwn2Own doesn’t is speed. I could have written my exploit in a day or a week or even a month. At other contests, you have to be ready to go non-stop for three days or whatever. I really never work more than eight hours a day.

  • crisisavatar
    he was born to kill
    Reply
  • Niva
    Blah, sad he didn't give an estimate to linux security. He said it has some method of protection but didn't expand on that much...

    As osx market share grows we'll see more exploits.
    Reply
  • Silluete
    Interesting thing about sandboxing, it's mean chrome more safe than other browser? or i missing something here?
    Reply
  • lire210
    whats up mac
    Reply
  • pcfxer
    Chrome uses processes instead of threads. The difference is that the memory space for each process is different--better sandboxing.

    Processes have increased headroom: they are making a copy of local variables and structures at the time of "forking".

    Threads "fork off" as functional code and work with their own memory space... in a nutshell.

    Sandboxing doesn't mean that Chrome is safer, it does mean that if sandboxing is implemented correctly Chrome CAN be safer. Security is so relative ;).
    Reply
  • AlanDang
    Exactly, Chrome is currently safer than any other web browser on Windows Vista or Windows 7. We have an upcoming interview that talks a little bit more about this, but we haven't made plans on a dedicated article. Is that something people are interested in?
    Reply
  • echdskech
    AlanDangExactly, Chrome is currently safer than any other web browser on Windows Vista or Windows 7. We have an upcoming interview that talks a little bit more about this, but we haven't made plans on a dedicated article. Is that something people are interested in?count me in A
    Count me in. Come to think of it, I spend more time on my browser than any other piece of software (except the OS ofcourse) at any given day. primarily because I use it both at work for research and for play (ie reading articles here). Also, trend these days seem indicate it becoming more and more a target rather than the OS.

    Would be extra nice if the level of detail would be like the articles you guys write when a new cpu architecture is discussed. =)
    Reply
  • anthony lackey
    There is less ppl attacking Mac's because they aren't the mainstream. Hackers would rather try to infect as many ppl as possible thats why they target PC users.
    Reply
  • If Apple does not allow cloning mac os may be safe for a long while, nobody likes to be tied to a single hardware vender. I really don't see how Apple could pull more that 15% to 18% market share without clones. JMO.
    Reply
  • dedhorse
    Good interview. Makes up for that Mac review.
    Reply