Pwn2own 2014 Set To Hunt Unicorns

darthcamaro writes "The annual Pwn2own hacking competition has always made short work of all browser vendors' security, shredding perception of safety by hacking IE, Firefox, Safari and Chrome in minutes. This year the competition is adding a twist — for IE on Windows 8.1, hackers will also have to bypass Microsoft EMET, which is a seemingly bulletproof type of sandbox. The competition is calling this the 'Unicorn Exploit' and the first researcher to successful exploit it will pocket $150,000."

What EMET is - and isn't

[daboochmeister]

At the risk of introducing information into the discussion ... some of the other respondents have taken oblique cue shots off this info, but to get it out on the table ... EMET is a software package that enforces otherwise existing security protections on programs that may not have them in place. For example, DEP, ASLR, SEHOP (very Windows-specific mitigation), heapspray prevention, and in 4.1 they added certificate pinning, to detect mitm attacks. (looking up acronyms left as an exercise for the reader)

The good news - these mitigations can be applied from outside the apps involved (as of 4.1, no more app recompiling or special-versions needed). The somewhat bad news - there are compatibility issues, and many apps are not compatible with the whole list of protections (see the MS KB article [microsoft.com] for more info). I also wonder if there are performance impacts from doing so, as opposed to compiling in the mitigations that can be compiled in - but don't quote me on that, I'm not sure

More bad news - it won't work with certain app features, e.g. any code that accesses certain system services at too low a level, so for example DRM-using apps (so many videogames are off the table); and it only intended for desktop apps (so they "do not advise" you use it with system services or server apps).

We tested the 3.0 version, focusing solely on the mitigations that could be imposed from outside the code even in that version - and found that many apps had issues with most, and some with all, of the mitigations (and, a killer for us, it wouldn't work with virtualized apps). Maybe that's improved, not claiming to know.

All in all - it has value if you're deploying legacy apps over which you have no control to a broad array of desktops, and it doesn't break your apps. Frankly, I don't know why the emphasis on IE11 ... I think the only protection that wouldn't already be compiled in is the certificate pinning, but maybe that alone is enough - or it makes it doubly difficult to break out of IE11 if you have the compiled in e.g. ASLR as well as the imposed-sandbox ASLR ... not sure.

To be clear ... it's NOT comparable to mandatory access control - it's more mitigation-specific than that. And also, by way of information, the open source operating systems often enforce the same kinds of mitigations on the apps that they support from their repositories (e.g., the Canonical Ubuntu team compiles every app in their repo with all possible mitigations -- see the Ubuntu security features page [ubuntu.com] for more info). That's one of the big advantages of open source - you don't have to try to impose really-meant-to-be-compiled-in security features from outside.