Who Gets Held Accountable For Security?
Alan: What about a Consumer Reports-type third-party to grade companies on their security? Even if I could do a better job than Sony, the guys at Microsoft and Google definitely are better than the average user. The average user isn't going to be able to do what Google did with counter-hacking the Chinese hackers or what Microsoft did with Waledac which combined technical measures with legal/political measures.
Charlie: Yes, this is one of the solutions I recommended during my recent talk at the NATO Cooperative Cyber Defense Centre of Excellence in Estonia. On a high level, something like Underwriters Laboratories. If you buy a toaster, and it has the UL seal on it, you can be sure it won't burn your house down. We need something like that for software where if you see the UL seal, you know it might not be perfect, but it has undergone and passed a certain level of scrutiny. On a technical level, I could imagine something like a private fuzzing test suite that a product would either pass or fail, and the software maker would not be given the failing test cases. In this way they couldn't "train for the test." They'd probably find way more bugs than the private test suite would find, just in the effort to pass the test.
Alan: Say you have secure hardware and secure software. How do we protect against social engineering?
Charlie: People are usually the weakest link in security. Almost all of the exploits I write at least require the user to go to a malicious Web site. That means clicking on a link sent via email, surfing on a public wireless access point, etc. Computers are designed, for the most part, to do things we ask them to. No matter how much security you build into a system, if the user really wants to run a piece of malware they think will show them some naked pictures, they're going to figure out a way to run that program.
Alan: Let’s talk a little bit about the iPad jailbreak. From what I understand, this is another PDF-based exploit. Have you had a chance to look at this?
Charlie: Yes, I've reverse engineered it a bit. The exploit is delivered via a PDF file, but the underlying vulnerability is in how it parses a font that is embedded in the PDF. This "malicious" font could have been delivered in ways besides PDF files. Anyway, it is a very clever exploit. The bug is in this little state machine that is processing the font. The bug allows the attacker to change where the program thinks the end of the buffer where the state machine is operating is located to beyond where it is supposed to be. Then the state machine can operate on parts of memory it is not supposed to while processing the font. This allows it to corrupt memory (to get control of the process) as well as read and operate on values from memory (which allows it to bypass ASLR, allowing it to find some executable code to use). At that point, it reuses the existing code fragments it wants (this technique is called return oriented programming) to launch a second exploit against a different vulnerability to escape the iOS sandbox, get root, disable code signing, and finally jailbreak the phone.