As I mentioned at the RSA Europe panel on "the History and Future of Binary Exploitation", we have been seeing and will continue to see a shift in importance from the discovery of vulnerabilities in individual pieces of software to the discovery of vulnerabilities in mitigation techniques. The effectiveness (and cost-effectiveness) of the protections pioneered in PaX should be clear to everyone by this point, even if the clarity of this situation is a bit muddled by poor implementations/design decisions on certain OSes.

It was for this reason that I was a bit surprised by the presentation by Andreas Bogk at 27C3 recently entitled "Defense is not dead." I of course don't argue with this title, though I'd go further to say that it hasn't been dead for the past 10 years, if you've been paying attention. I disagree with the conclusions of the presentation though, and some of the statements made in it bothered me. A video of the presentation is available at: http://achtbaan.nikhef.nl/27c3-stream/r ... ot%20dead/ . Andreas is definitely very bright, but discussing the solution to our security problems in terms of removing all the exploitable bugs through formally-verified compilers and new languages/processors/OSes seems rather misguided.

Defense will die of old age before normal users will see security problems evaporate from these technologies. Our real-world experience should have sufficiently demonstrated to us that ridding the world of vulnerabilities will never happen (not to mention all the legacy code still laying around). Formal verification also has the real potential to introduce a sense of false security. How will users have knowledge of what was proven where? The verification is only as good as the proof. Does any long-term adoption plan exist? How would we (or is it even possible to) transition to such an extreme solution? Is it possible to solve the problem of legacy code? Can you run an old firefox binary on this new system without having your data stolen out of it via an exploit? There are all kinds of other societal factors to consider, like the fact that users are generally against alteration of their computing experience in a significant way (see the backlash against the Vista UAC). Barring some reality-based answers to these questions, I'm inclined to think of this approach more in terms of concept cars or fashion shows: the point isn't to take the "solution" wholesale, but to find what bits and pieces you can integrate into current solutions in a more progressive way.

We continue to see vulnerabilities in MS's implementation of PaX's PAGEEXEC/ASLR features (or vulnerabilities in other vendors' use of said mitigations due to certain design decisions and compromises). It's surprising actually that this many years into having this functionality, large vendors continue to apparently fail at implementing any kind of QA along the lines of "don't ship out any code without /DYNAMICBASE," which has lead to nearly all of the "ASLR bypass" stories that have cropped up in the past year or so.

It's important that the vendors take the initiative here, because with the trends in security going the way they are, the self-interest of the industry prevents it from being benevolent in reporting these kinds of mitigation vulnerabilities. There's a difference between killing a single vulnerability, which is probably found via fuzzing and which another researcher has likely also found, and killing a mitigation vulnerability that may make the next 20 vulnerabilities discovered unexploitable (or only unreliably exploitable). I've already heard of this kind of behavior taking place, and it's unfortunate and unacceptable that money/job security/industry security is given greater priority over actually fixing security problems. But this is all further evidence in what I've mentioned to others as an industry knowingly in its death throes. The tendency to ignore the latest OS/architecture trends and the latest mitigations in exploitation research is yet further evidence.

On the topic of mitigations, it's important to make the distinction between things like PAGEEXEC/SEGMEXEC/MPROTECT/ASLR and EAT address filtering. EAT address filtering has more in common with things like Comodo's Memory Firewall product that claimed protection against ret2libc (see: http://forums.comodo.com/frequently-ask ... 237.0.html) but simply contained a weak protection against canned ret2libc exploits against specific APIs. With any knowledge of the method Comodo was using, through some minutes of reversing, it wasn't difficult to modify a ret2libc-style exploit to still work. In November, Skylined published a bypass for EAT address filtering, which he wisely called a "pseudo-mitigation" (see: http://skypher.com/index.php/2010/11/17/bypassing-eaf/). A side-note about the comments to the article: DRx are privileged registers, so access to them by unprivileged code triggers an exception (i.e. you cannot just clear DR7 to evade detection). GD thus has nothing to do with this -- it would only cause privileged access to DRx to fault as well. There are other caveats associated with GD that generally makes it useless for anything security related, but people always like throwing it out there as evidence that they read the Intel manuals or something.

We need to be likewise careful when discussing "sandboxes." It's a failure that we have discussions about software like Adobe Reader that boil down to: "Person 1: Adobe Reader X has a sandbox. Person 2: A sandbox? that's great!" The implementation of the sandbox matters. This is why information like that contained in Mark Dowd's posts: http://blog.azimuthsecurity.com/2010/05 ... rview.html are important, though it would be nice to have this kind of information more readily available to users of the software and without the bias of the vendors themselves. Preventing the execution of arbitrary code or other control flow modifications has benefits for sandboxing as well. If you can guarantee that an attacker can't just issue arbitrary system calls (in order to exploit a kernel-level vulnerability as part of his/her exploit chain) then it doesn't matter so much that the sandbox in place has no syscall-level filtering.

Defense isn't dead, but it's not easy to do (properly), especially under the constraints Microsoft and others have to operate under. It's too bad there aren't more people in the industry interested in defense -- if there were, perhaps we could all work together to put ourselves out of jobs!

Accepting applications,

-Brad