Every browser falls at this year's record-setting Pwn2Own


Chaouki Bekrar, VUPEN, demonstrating exploit on day two of ​Pwn2Own 2013

Pwn2Own 2014 saw record payouts for 0-day vulnerabilities, with a total of $850,000 paid out to the eight entrants, and $385,000 potential prize money unclaimed.

Firefox seemed to be the common target for this year's event, making up a third of all vulnerabilities. George Hotz, also known as Geohot: the famed hacker and cryptanalyst that developed iOS and PS3 jailbreaks, also participated and was awarded $50,000 for a Firefox exploit. However, other browsers weren't spared, and every browser had been pwned by the end of the second day of the contest. 

The French security company VUPEN made up the lion's share of vulnerabilities and prize money, taking home $300,000 on the first day of the contest and a further $100,000 on day two.

The exploits presented at this year's Pwn2Own are as below.

By Team VUPEN:

  • Against Adobe Flash, a use-after-free with an IE sandbox bypass resulting in code execution.
  • Against Adobe Reader, a heap overflow and PDF sandbox escape, resulting in code execution.
  • Against Microsoft Internet Explorer, a use-after-free causing object confusion in the broker, resulting in sandbox bypass.
  • Against Mozilla Firefox, a use-after-free resulting in code execution.
  • Against Google Chrome, a use-after-free affecting both Blink and WebKit along with a sandbox bypass, resulting in code execution.

By Sebastian Apelt and Andreas Schmidt:

  • Against Microsoft Internet Explorer, two use-after-free bugs and a kernel bug, resulting in system calculator.

By Liang Chen of Keen Team:

  • Against Apple Safari, a heap overflow along with a sandbox bypass, resulting in code execution.

By George Hotz:

  • Against Mozilla Firefox, an out-of-bound read/write resulting in code execution.

By Zeguang Zhao of team509 and Liang Chen of Keen Team:

  • Against Adobe Flash, a heap overflow with a sandbox bypass, resulting in code execution.

By Jüri Aedla:

  • Against Mozilla Firefox, an out-of-bound read/write resulting in code execution.

By Mariusz Mlynski:

  • Against Mozilla Firefox, two vulnerabilities, one allowing privilege escalation within the browser and one bypassing browser security measures.

By an anonymous participant:

  • Against Google Chrome, an arbitrary read/write bug with a sandbox bypass resulting in code execution. Upon review, contest judges declared this a partial win due to one portion of the presentation’s collision with a vulnerability presented earlier at Pwnium.

A third Internet Explorer exploit was attempted on day two, but was unsuccessful in the 30 minute time-frame given for the Pwn2Own contest. ZDI analysts did however look into the submission afterwards and confirmed that it was functional, and purchased the vulnerability as part of their standard brokerage program.

Source: Pwn2Own Day 1, Day 2 | Image via Pwn2Own

Report a problem with article
Previous Story

FCC approves AT&T's acquisition of Leap Wireless

Next Story

United States to give up its oversight on domain name assignment

31 Comments

Commenting is disabled on this article.

DaveGreen93 said,
Seeing how Flash is built into IE on Windows 8, doesn't this put it on par with Firefox? 2 IE exploits + 2 Flash exploits.

considering that most Firefox users use Flash Player too, the answer is nope. But nice try!

(btw, you can disable flash player on IE9/10/11 and allow it only on specific websites by enabling ActiveX Filtering in the tool, safety menu).

btw, EMET also protects against Flash Player exploits, which means you would still be safer with IE11 with Flash player and EMET, rather than with just Firefox without Flash player and EMET.

DaveGreen93 said,
Seeing how Flash is built into IE on Windows 8, doesn't this put it on par with Firefox? 2 IE exploits + 2 Flash exploits.

Just like using it with Firefox, Chrome, Opera it can be enabled or disabled. This is truly a false analogy. Also the internal Flash in some of these browsers tend to be far more buggy than the official Adobe version that Microsoft uses.

link8506 said,

considering that most Firefox users use Flash Player too, the answer is nope. But nice try!

(btw, you can disable flash player on IE9/10/11 and allow it only on specific websites by enabling ActiveX Filtering in the tool, safety menu).

btw, EMET also protects against Flash Player exploits, which means you would still be safer with IE11 with Flash player and EMET, rather than with just Firefox without Flash player and EMET.

Well, I stand corrected. Thank you.

All these bugs would be impossible if these software were written in managed languages such as C#. The world may be "built on C++" as Herb Sutter likes to gloat, but year after year of buffer overruns, use-after-free, heap overflows and such memory-unsafe exploits costing billions of dollars to the software industry, shows that this obviously is not a good thing.

Edited by Andre S., Mar 16 2014, 6:20pm :

Andre S. said,
All these bugs would be impossible if these software were written in managed languages such as C#. The world may be "built on C++" as Herb Sutter likes to gloat, but year after year of buffer overruns, use-after-free, heap overflows and such memory-unsafe exploits costing billions of dollars to the software industry, shows that this obviously not a good thing.

yeah a 100% managed code browser would be much more secure (although there could still be design flaws not related to memory corruption).

but that would require image decoding libraries and SSL library to be written in managed code too.

and I'm not entirely sure that the underlying .net framework (or whatever managed runtime) would be 100% free of any memory corruption that could be triggered from the managed web browser (as it would have a JS implementation that could help attackers manipulate memory).

but yeah, in the end, such attacks would become extremely unlikely, and speed would be slower, but it would still remain usable.

I created a basic web browser using c#/xna on wp7 a few years ago, but never released it (no, it was not based on IE/trident web browser control). it was just supporting HTML and CSS, not JavaScript, and it was slower than IE7 Mobile, but faster than I expected considering the total lack of optimizations.


another solution against memory corruption exploits would be to ban scripting languages like Javascript from web browsers (and from adobe reader and flash). With no way to manipulate memory through scripts, it would be near impossible to bypass memory protections such as DEP and ASLR, even on a browser based on native code.

if web browsers were just document viewers, such exploits would be a thing of the past. But we're actually heading to the opposite direction with more demand for features (such as webgl).

Pluto is a Planet said,
There are still regular security patches for the .NET framework... That doesn't necessarily mean it's worse though
Yes, because the core CLR is written in C++ itself. But that's a much smaller area of attack, and one that sees a lot more testing than any individual piece of software.

Pluto is a Planet said,
There are still regular security patches for the .NET framework... That doesn't necessarily mean it's worse though

yes, runtimes such as .net and java are at risk being compromised when they load or start JITing compromised assemblies or applets from untrusted sources.

but the interesting question would be: can a .net/java application be compromised during its execution, at the runtime level, via a memory corruption vulnerability?

in other words, would it be possible to compromise a .net/java-based browser using underlying runtime flaws?

it think the answer is probably yes. But the attack surface is pretty low.

Mr. Dee said,
Adobe products are a major problem.

not much more than IE, Chrome, Firefox, or safari actually!

security of adobe product is not as bad as people say (although code quality is not as good as MS or google products)

but considering that adobe flash player and adobe reader are installed on 90% of the computers, black hats will prefer targeting flash or adobe reader rather than having to develop an exploit for each browser.

actually, exploits targeting Firefox are easier to create than exploits targeting a sandboxed adobe reader X or flash player on IE or Chrome.

that means if Firefox had 90% of market share, you would hear more about 0day attacks against Firefox, and almost never hear about attacks against Flash or adobe reader.

Leopard Seal said,
It's strange that there is no mention of what CPU platform the browsers were running on. I can only assume it was Intel.

how is that relevant?

exploit code is the same on intel or AMD x86/x64.

and on ARM too the same flaws could be exploited (although the actual exploit code would be different)

link8506 said,

how is that relevant?

exploit code is the same on intel or AMD x86/x64.

and on ARM too the same flaws could be exploited (although the actual exploit code would be different)

How do you know that it's not relevant? ARM and x86 and their supported operating systems have entirely different architectures, memory management and sandboxing.

Leopard Seal said,

How do you know that it's not relevant? ARM and x86 and their supported operating systems have entirely different architectures, memory management and sandboxing.

no they don't

there are a few implementation differences which may make some,flaws specific to 1 environment, but fundamentally the underlying kernels are similar, and the web browser code is the same.

Flaws in ChromeOS should be exploitable no matter if the machine is x86 or ARM. And they are likely to also be similarly exploitable to android/chrome or a desktop Linux with chrome.

link8506 said,

no they don't

there are a few implementation differences which may make some,flaws specific to 1 environment, but fundamentally the underlying kernels are similar, and the web browser code is the same.

Flaws in ChromeOS should be exploitable no matter if the machine is x86 or ARM. And they are likely to also be similarly exploitable to android/chrome or a desktop Linux with chrome.

Not to get into details, on one hand you are correct that a lot of things will be similar; however, there is a far bigger difference in the architectures, especially in code execution that simply would not work across architectures.

Depending on the OS model the kernel or the abstraction layers will be significantly different on each architecture. This is where even x86 and x64 aren't similar, let alone a RISC architecture like ARM compared to a CISC architecture like x86/x64.

Also there is a difference between AMD and Intel even with their similarities, they have far different multimedia (FP) cores that can be exploited in different ways.

Mobius Enigma said,

Not to get into details, on one hand you are correct that a lot of things will be similar; however, there is a far bigger difference in the architectures, especially in code execution that simply would not work across architectures.

of course an x86 shellcode won't work on ARM.
the exploit has to be rewritten to target other platforms.

but the question asked by the op was irrelevant because the answer may mislead him into thinking that only the specific platform targeted in the contest is vulnerable.


Depending on the OS model the kernel or the abstraction layers will be significantly different on each architecture. This is where even x86 and x64 aren't similar, let alone a RISC architecture like ARM compared to a CISC architecture like x86/x64.

Also there is a difference between AMD and Intel even with their similarities, they have far different multimedia (FP) cores that can be exploited in different ways.

if we talk just about Firefox exploits, most of them don't rely on exploiting kernel flaws. So a flaw in Firefox for windows will likely be easy to modify to work on linux/osx/openbsd or whatever else.

kernels flaws might not always exist on different architectures, but by default you should still consider they might, unless proven otherwise (for example if the affected component does not exist on the other architecture, such as the 16bit VM on Win64).

as for the difference between x86/64, an exploit targeting a 32bit browser will typically work the same regardless of whether the cpu is x86 or x64, or Intel or AMD.

link8506 said,

of course an x86 shellcode won't work on ARM.
the exploit has to be rewritten to target other platforms.

but the question asked by the op was irrelevant because the answer may mislead him into thinking that only the specific platform targeted in the contest is vulnerable.

if we talk just about Firefox exploits, most of them don't rely on exploiting kernel flaws. So a flaw in Firefox for windows will likely be easy to modify to work on linux/osx/openbsd or whatever else.

kernels flaws might not always exist on different architectures, but by default you should still consider they might, unless proven otherwise (for example if the affected component does not exist on the other architecture, such as the 16bit VM on Win64).

as for the difference between x86/64, an exploit targeting a 32bit browser will typically work the same regardless of whether the cpu is x86 or x64, or Intel or AMD.

We are making this too involved for a simple question.

This architecture question was essentially a question about code execution escalation which can have various different effects based on the hardware architecture. So the hardware can matter, and as I pointed out there is a major difference in how code runs on various hardware architectures.

So an exploit targeting a 32bit browser will not ALWAYS work the same on x64 as it does on x86. There differences between x86 and x64 in execution and memory protection, and there are differences in how AMD and Intel each handle these types of technologies. (There are also additional OS kernel level features based on the architecture like ALSR, but that is not what I talking about.)

The article forgets to mention that another contest was rewarding $150k anyone who could exploit a flaw in Chrome OS or IE11 with EMET.

and the results may shock a lot of people:

Chrome OS was pwned. Twice. (1 full exploit, and another partial)

Leaving IE11 on Win8.1 + EMET the only target not to be pwned!

http://www.zdnet.com/crash-ban...sers-at-pwn2own-7000027343/
https://plus.google.com/app/ba...go30uv3gh04cjt5wyojojfsal34


if you still don't know what EMET is, take a few minutes to read this:
http://www.julien-manici.com/b...et-Explorer-Firefox-Chrome/

even if EMET is not perfect, it's worth installing, no matter what browser you use, as it appears that exploit developers face strong difficulties in bypassing EMET's protections

Edited by link8506, Mar 16 2014, 12:25pm :

link8506 said,
The article forgets to mention that another contest was rewarding $150k anyone who could exploit a flaw in Chrome OS or IE11 with EMET.

and the results may shock a lot of people:

Chrome OS was pwned. Twice. (1 full exploit, and another partial)

Leaving IE11 on Win8.1 + EMET the only target not to be pwned!

http://www.zdnet.com/crash-ban...sers-at-pwn2own-7000027343/
https://plus.google.com/app/ba...go30uv3gh04cjt5wyojojfsal34


if you still don't know what EMET is, take a few minutes to read this:
http://www.julien-manici.com/b...et-Explorer-Firefox-Chrome/

even if EMET is not perfect, it's worth installing, no matter what browser you use, as it appears that exploit developers face strong difficulties in bypassing EMET's protections

This!
this should have been mentioned.

link8506 said,
Even if EMET is not perfect, it's worth installing, no matter what browser you use, as it appears that exploit developers face strong difficulties in bypassing EMET's protections
Makes me wonder whether they should make it part of the OS in future. Even if it causes some incompatibility they can provide an easy to understand UI so the non-working app can be excluded.

link8506 said,
The article forgets to mention that another contest was rewarding $150k anyone who could exploit a flaw in Chrome OS or IE11 with EMET.

and the results may shock a lot of people:

Chrome OS was pwned. Twice. (1 full exploit, and another partial)

Leaving IE11 on Win8.1 + EMET the only target not to be pwned!

I wasn't following that close this year, was it even attempted? If not then that is hardly the same result. These guys are targeting known exploits that they can get into under the time allotted, and that aren't as highly lucrative to them as some of the others. $150k is a good pay day, but given the seriousness of the exploit needed to attain that pay day and the amount of time it might take they may be keeping that one in their bag.

Romero said,
Makes me wonder whether they should make it part of the OS in future. Even if it causes some incompatibility they can provide an easy to understand UI so the non-working app can be excluded.

EMET won't be included in future versions of Windows, but it is likely that some of its protections will be built into future versions of Windows and IE.

it already happened in the past.
For example, EMET allows (since a long time) to force ASLR on every component of a process, even on DLLs not marked as compatible with ASLR.
Recently, this option has been included in Win8 and back ported in Win7 under the name "ForceASLR", which is used starting with IE10 to ensure that ASLR doesn't get easily defeated by old plugins not supporting ASLR.

likewise, it may be possible that future versions of IE offer simple settings to enable/block plugins depending on the internet zone, based on what the newly introduced EMET5 ASR feature does (ex: allowing java to run only in IE's intranet zone)

Richeemxx said,

I wasn't following that close this year, was it even attempted? If not then that is hardly the same result. These guys are targeting known exploits that they can get into under the time allotted, and that aren't as highly lucrative to them as some of the others. $150k is a good pay day, but given the seriousness of the exploit needed to attain that pay day and the amount of time it might take they may be keeping that one in their bag.

indeed you're totally right.

none of the security researchers have signed up to demonstrate an exploit against EMET/IE11.

that doesn't means that an IE11/EMET exploit doesn't already exists somewhere (actually there was even a PoC against EMET4 last month). But if it exists, its creators were visibly not interested in selling it for $150k. Considering EMET is being used by more and more government agencies and big enterprises to protect their PCs, I can imagine that an EMET exploit is worth a lot more on the black market.

but in the end, it's still interesting to see that ChromeOS was pwned for the same $150k amount.
I didn't expect that to happen, because of such low market share, ChromeOS is not an attractive target yet. But I guess hackers were attracted by Google bragging year after year that "ChromeOS is the more secure thing ever" (or something like that). That has definitely put ChromeOS on their radar!

Every one knows that every browser has vulnerabilities, but cool to see people doing this stuff for the good.

Wonder if the one's found in Chrome also effect Opera since they've switched to that engine? Otherwise, don't see Opera mentioned in this article? Didn't read the source link.

VUPEN's chrome exploit affects all WebKit based browsers, and as a result earned $100,000 for that vulnerability alone.

cork1958 said,
Every one knows that every browser has vulnerabilities, but cool to see people doing this stuff for the good.

Wonder if the one's found in Chrome also effect Opera since they've switched to that engine? Otherwise, don't see Opera mentioned in this article? Didn't read the source link.

yes obviously it affects Opera too.

older versions of opera were not based on Chromium, but they were actually much less secure.

the older Presto-based Opera had no sandbox, and didn't interest a lot of hacker considering its low market share.

that's why even on previous Pwn2Own contests Opera was not among the targets, to avoid misleading people into thinking that Opera was more secure than the other browsers because nobody cared about hacking it.

Steven P. said,
Hah, good point.. I suppose the focus is just on the "major" browsers

Why were there no mention of IE11 with EMET? It had a 150k reward and no one pawned it.