VANCOUVER, BC -- At the CanSecWest security conference here, I got a chance to sit down with Charlie Miller, the researcher who broke into a fully patched MacBook machine using a Safari code execution vulnerability.
We discuss the state of Web browser security, the vulnerability marketplace and the need for anti-exploit mitigations on modern operating systems.
Ryan Naraine: So, what can you tell us about the vulnerability?
Charlie Miller: Not much. As part of the contest rules, I'm under NDA about the technical details. I can tell you the computer (MacBook Air) was fully patched. It was an exploit against Safari 4 and it also works on Safari 3. I actually found this bug before last year's Pwn2Own but, at the time, it was harder to exploit. I came to CanSecWest last year with two bugs but only one exploit. Last year, you could only win once so I saved the second bug. Turns out, it was still there this year so I wrote another exploit and used it this year.
Does it work on Safari for Windows?
I don't know. I didn't look.
Did you consider reporting the vulnerability to Apple?
I never give up free bugs. I have a new campaign. It's called NO MORE FREE BUGS. Vulnerabilities have a market value so it makes no sense to work hard to find a bug, write an exploit and then give it away. Apple pays people to do the same job so we know there's value to this work. No more free bugs.
What's the ballpark value of that Safari bug?
It was probably more than that $5,000 prize I won. It's much less than the IE 8 vulnerability (exploited separately by Nils) by about a factor of ten. I could get more than $5,000 for it but I like the idea of coming here and showcasing what I can do and get some headlines for the company I work for (Independent Security Evaluators).
Why Safari? Why didn't you go after IE or Safari?
It's really simple. Safari on the Mac is easier to exploit. The things that Windows do to make it harder (for an exploit to work), Macs don't do. Hacking into Macs is so much easier. You don't have to jump through hoops and deal with all the anti-exploit mitigations you'd find in Windows.
It's more about the operating system than the (target) program. Firefox on Mac is pretty easy too. The underlying OS doesn't have anti-exploit stuff built into it.
With my Safari exploit, I put the code into a process and I know exactly where it's going to be. There's no randomization. I know when I jump there, the code is there and I can execute it there. On Windows, the code might show up but I don't know where it is. Even if I get to the code, it's not executable. Those are two hurdles that Macs don't have.
It's clear that all three browsers (Safari, IE and Firefox) have bugs. Code execution holes everywhere. But that's only half the equation. The other half is exploiting it. There's almost no hurdle to jump through on Mac OS X.
What's harder? Finding the bug or writing the exploit?
It's changing. In the past, it was always hard to find bugs but once you found something, it was easier to write a reliable exploit. Now the (software companies) have gotten smart and they make it much harder to exploit. It's hard to find a good bug these days and even harder to exploit and deal with all the mitigations. That's why Dino (Dai Zovi) and I are a good team. He specializes in exploits and I can concentrate on finding good bugs.
On a scale of 1-10, how impressive was the Nils' sweep of exploiting all three main browsers?
I was surprised. For IE 8, I'd give him a 9 out of 10. For Safari, maybe a 2. It's just too easy to pop Safari. For Firefox on Windows, I give him a 10. That was the most impressive of the three. It's really hard to exploit Firefox on Windows.
Really? What's the difference between what you can do on IE but can't do on Firefox?
The technique he used works against IE but not Firefox. It allows you to place code in a specific spot in memory. Mark Dowd and Alex Sotirov talked about this at last year's Black Hat. You can use a technique to make .net not opt into the mitigations and jump over hurdled easily. With Firefox, you can't do that.
For all the browsers on operating systems, the hardest target is Firefox on Windows. With Firefox on Mac OS X, you can do whatever you want. There's nothing in the Mac operating system that will stop you.
You talked earlier about the value of vulnerabilities. Was it a surprise that he (Nils) basically gave up three "high-value" bugs for $5,000 each?
It's clear he's incredibly talented. I was shocked when I saw someone sign up to go after IE 8. You can get paid a lot more than $5,000 for one of those bugs. I've talked to a lot of smart, knowledgeable people and no one knows exactly how he did it. He could easily get $50,000 for that vulnerability. I'd say $50,000 is a low-end price point.
For the amount of time he spent to do what he did on IE and Firefox, he could have found and exploited five or 10 Safari bugs. With the way they're paying $5,000 for every verifiable bug, he could have spent that same time and resources and make $25,000 or $30,000 easily just by going after Safari on Mac.
Google Chrome was the one target left standing. Surprised?
There are bugs in Chrome but they're very hard to exploit. I have a Chrome vulnerability right now but I don't know how to exploit it. It's really hard. The've got that sandbox model that's hard to get out of. With Chrome, it's a combination of things -- you can't execute on the heap, the OS protections in Windows and the Sandbox.
I might have this bug and I might be able to get code execution. But now you'r ein a sandbox and you have no permissions to do anything. You need another bug to get out of the sandbox. Now you need two bugs and two exploits. That raises the bar.
Coming in, when I posted my predictions, I didn't think anyone would get go after Chrome, IE or Firefox. It's all economics. It's only hard or easy compared to what someone would pay. If Pwn2Own offered $1 million per bug for Chrome, there would be a line of people here looking to bankrupt them.
Are browsers generally getting better at securing Web surfers?
Browsers are so complex, it's almost impossible to get everything right. With all that code and dependencies, it's hard to be perfect. People said five years ago that buffer overflows would be solved by now. Well, they're not. Bugs will always be there so it's a smart move to work on mitigations and (anti-exploit) roadblocks.
Browsers do a better job of providing visual warnings of phishing and malware sites or poor SSL. It's not enough but it's better than nothing. I think what you see with Chrome and sandboxing, that's where everyone needs to go. It'll take a few years but that will have to be the standard.
* Image credit: TippingPoint Zero Day Initiative.