Charlie Miller Reveals His Process for Security Research

As the first in an ongoing series of interviews, we got recent Pwn2Own winner Charlie Miller to answer a few questions and pull back the curtain a bit on the methods, tools and motivation for the research he does discovering security exploits.

Charlie Miller is currently Principal Analyst at Independent Security Evaluators. He was the first with a public remote exploit for both the iPhone and the G1 Android phone. He has won at the CanSecWest Pwn2Own competition in each of the last four years. Popular Mechanics listed him as a Top 10 Hacker of 2008 and he is on the list of 2010 Security Superstars by Channel Web. He has authored two information security books and holds a PhD from the University of Notre Dame.

What motivates you to find security vulnerabilities?

I have many motivations. I like to highlight security issues in products I use so they get fixed and become more secure. Another motivation is I like collecting bugs because I get a thrill knowing I know something that nobody else probably knows, so its like how some people have stamp collections, I have a bug collectin. Finally, I enjoy doing it. It satisfies my intellectual curiosity and its fun to do!

What are the primary tools you use, and how do you use them?

I mostly use fuzzers. I outlined how I use my fuzzer at my CanSecWest talk last year. I fuzz and collect crashes. Then I have to sort through all the crashes and figure out if any look exploitable. For the best, I have to figure out the root cause to understand what the underlying vulnerability happens to be. My fuzzing is fully automated, but the crash analysis is mostly by hand and so is the most time consuming part of the process. Last year at BlackHat I spoke about some tools that I helped work on to try to automate this process, but mostly I am still forced to do it by hand.

How do you choose your target of investigation? Do you pick your target application and look for bugs, or look for a genre of bug in many different applications?

Ah, this is the real trick. As a researcher, this is probably the hardest part, and luckily, I’ve been pretty good at this. On the one hand you want to pick something that you think will be easy. On the other hand, you want to pick something important and in wide use. The hard part is finding the happy medium of something that is pretty important, but still relatively easy to find bugs inside. For example, choosing a random web app from the Internet will be easy to find bugs but no one will care. Finding a bug in Apache would be awesome, but its probably too hard.

How do you handle disclosure? Which vendors have been good to work with and which have not?

Earlier in my career, I used to disclose bugs to vendors regularly. Now, I rarely do so. Disclosing bugs is often an exhausting bureaucratic hassle that can leave you open to legal problems and doesn’t have much personal upside. Plus, I am a professional consultant who finds vulnerabilities in software for a living, so it doesn’t seem fair to make my paying customers pay and let some vendors not have to pay for bugs.

What are you working on currently?

I just finished Pwn2Own, which I’m happy to say I won for the fourth straight year. That took a lot of time, so I’ll probably take a little break and then hopefully start working again. One thing I might look at would be the beta release of the next OS X version called Lion.

Do you think there will be more remotely exploitable bugs discovered for the iPhone this year?

If people care to look for them, there certainly will be. There are a lot of bugs in almost every product and application we rely on. Information security is not in a good place right now.

Please compare the quality of code you have reversed in OSX vs. other platforms in terms of security. Does Apple pay more/equal/less attention to secure software development when compared to other vendors?

I think Apple code used to be quite a bit worse than, say, MS code, although this is a very difficult thing to measure. MS started trying to write secure code back in 2003, while Apple only recently found religion. However, I’ve noticed some improvements lately in Apple, so this divide may not be as large as it used to be. For example, I’ve known a few very serious flaws in OS X for over a year. I’ve noticed that a large number of them are going to be patched in the next version 10.6.7 that comes out, so Apple is starting to secure up their code I think, which is awesome.