Researchers hack into newest Firefox with zero-day flaw

Researchers hack into newest Firefox with zero-day flaw

Summary: The exploit was triggered against a use-after-free vulnerability in the open-source browser and successfully evaded DEP and ALSR, two anti-exploit mitigations built into the Windows operating system.


Willem Pinckaers and Vincenzo Iozzo

VANCOUVER -- Mozilla's Firefox is the latest browser to fall victim to hackers at this year's Pwn2Own hacker contest.

Two researchers working together -- Willem Pinckaers and Vincenzo Iozzo -- exploited a single zero-day vulnerability in the latest Firefox 10.0.2 (Windows 7 SP1) to cart off a $30,000 cash prize.

follow Ryan Naraine on twitter

The exploit was triggered against a use-after-free vulnerability in the open-source browser and successfully evaded DEP and ALSR, two significant anti-exploit mitigations built into the Windows operating system.

Firefox does not have a sandbox, which made it an easy target at Pwn2Own, which unearthed multiple zero-day flaws in Microsoft's Internet Explorer and the Google Chrome browser.

[ SEE: Teenager hacks Google Chrome with three 0day vulnerabilities [

In an interview after demonstrating the drive-by download attack for Pwn2Own organizers, Pinckers said he was able to convert the use-after-free bug into two separate information-leak conditions to complete the exploit.

"We triggered the same vulnerability three times.  We used it once to leak some information, the used it again to leak addresses of our data.  Then, we used the same vulnerability a third time get code execution."

Pinckaers said it took him a single day to write a reliable exploit after Iozzo gave him the vulnerability.


  • Pwn2Own 2012: Google Chrome browser sandbox first to fall
  • CanSecWest Pwnium: Google Chrome hacked with sandbox bypass
  • Charlie Miller skipping Pwn2Own as new rules change hacking game
  • CanSecWest Pwn2Own hacker challenge gets a $105,000 makeover
  • How Google set a trap for Pwn2Own exploit team
  • Topics: Security, Apps, Browser, Google

    Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


    Log in or register to join the discussion
    • I'm shocked, shocked I tell you, to hear that there's another FF security

      hole. The fanbois said many eyes eliminates this sort of thing in FOSS code so this must not be true. Where is Linux geek to tell me this is a lie, a product of MS marketing spin?
      Johnny Vegas
      • I'm Not Shocked

        As the lead said: "The exploit was triggered against a use-after-free vulnerability in the open-source browser and successfully evaded DEP and ALSR, two anti-exploit mitigations built into the Windows operating system."

        Notice the part about successfully evading DEP and ALSR. So once Firefox was exploited, the OS let the exploit do whatever it wanted.
        • DEP and ASLR

          Are mitigation techniques and never claimed to protect 100% They still do turn a lot of potential vulnerabilities into relatively benign (security-wise) crashes. Vulnerabilities which goes un-mitigated on other platforms with non or weak ASLR (like Linux).
      • I'm equally shocked...

        that IE was rocked with multiple vulerabilities. The fanbois claim that since Microsoft has placed so much emphasis on security their software is now rock solid. I guess it isn't true that closed source is more secure than open source.
        • Stop listening to "fanbois"

          Is quick solution for your problem ;)
          (And his too)
        • It takes at least 2 vulns to bring down IE - hence multiple

          With Firefox which has no sandbox it takes just a relatively simple vulnerability. IE and Chromw sandboxes are widely recognized as *hard* to take down. Indeed, all indications are that at least in the Chrome case the sandbox was *not* breached - rather the attackers found a way to *bypass* the sandbox by finding a vuln in not-fully-sandboxed Adobe code.
      • Stop listening to what you want to listen to, and start to listent what...

        Others are saying...

        Then maybe you will notice difference between "certainty", and "better chances".
        • protect yourself

          and if you want the best chances, use Firefox with the NoScript addon.

          Cant beat that security on any stock browser!
    • Security?

      I use FF.
      People abused me for saying that Mozilla should concentrate on fixing code, rather than rushing out new versions with higher version numbers.

      "[i]Firefox does not have a sandbox, which made it an easy target at Pwn2Own, which unearthed multiple zero-day flaws in Microsoft???s Internet Explorer and the Google Chrome browser.[/i]"
      What was the point of that statement?

      IE (Protected Mode) and Chrome (Sandboxed) both got taken down.
      Anecdotal evidence would seem to suggest, the "protection" on those browsers is just marketing hype.
      • Apparently ...

        Apparently Mozilla knew about this bug, before the competition and it has been fixed in FF 11 (out now).
        So now I have to say, "good work Mozilla."
    • RE: Security?

      Without a sandbox on Windows, Firefox is an easier target. Sandboxing just raises the bar for the miscreants by requiring that they use multiple exploits. Thus, while sandboxes do provide defense-in-depth, they aren't bulletproof (or even close).

      Every web browser, by default, enables the following dangerous settings:
      o JavaScript
      o IFRAMES
      o Automatic loading of images (e.g., malverts, malformed images)
      o Plug-ins (e.g., Flash, Java)

      This is 'default allow'. Then they use a web site blacklist to warn users away from known bad sites (these blacklists never work for the rigged web sites used at Pwn2Own). Web site blacklists, just like AV signatures, are always a step or two behind the miscreants. In addition, IE (on Windows), Chrome/Chromium (on Windows, Mac OS X and Linux) and Safari (on OS X Lion) sandbox the browser, but not the plug-ins.

      I would love to know what percentage of web users create and manage whitelists for their frequently visited sites, aka 'trusted sites'. If web users were to use whitelists to manage frequently-visited sites where dangerous browser setting are allowed, these dangerous browser settings would be disallowed for all other web sites. This is 'default deny' and has much less reliance on security features such as sandboxing. However, so-called 'trusted sites' do get pwned, so having a sandbox as backup is a good thing. Chrome/Chromium, Opera and IE have whitelisting capability built-in to the browser, while Firefox requires an add-on such as NoScript for whitelisting capability.

      One can create a DIY sandbox for Firefox using Windows integrity levels. Open notepad and copy & paste the following commands into notepad:

      cd "C:\Program Files\Mozilla Firefox"
      icacls firefox.exe /setintegritylevel low
      cd C:\Users\USERNAME\AppData\Local
      icacls Mozilla /setintegritylevel (OI)(CI)low
      icacls Temp /setintegritylevel (OI)(CI)low
      cd C:\Users\USERNAME\AppData\Roaming
      icacls Mozilla /setintegritylevel (OI)(CI)low
      cd C:\Users\USERNAME
      mkdir Downloads
      icacls Downloads /setintegritylevel (OI)(CI)low

      Substitute your username for USERNAME, save the file as FirefoxSandbox.bat, as an example, and run the bat file in cmd.exe as Administrator. Note that all files downloaded with Firefox must be placed in folder C:\Users\USERNAME\Downloads as a medium integrity folder will not allow a low integrity level process to write to it (remember, it's sandboxed).

      I've tested this using Sysinternals Process Explorer. Firefox runs at a low integrity level (LIL) process, the Flash plug-in runs as a LIL process via plugin-container.exe and the Java plug-in runs as LIL processes via jp2launcher.exe and java.exe. While one can check for Firefox updates, the updater will not work at low integrity. Instead, download the updated Firefox installer from, install it over the current version and re-run the bat script.
      Rabid Howler Monkey
      • Or you can use sandboxie

        I use Firefox and don't bother with a sandbox, having never gotten a virus in >20 years using PCs. But if you are actually concerned about it, this program is free.
        x I'm tc
      • Windows Server

        using IE and Enhanced Security Configuration (default on) does exactly what you ask. Nothing is allowed to run scripts unless you trust the site. It can be a bit of a pain sometimes but totally worth it on a server. As of 2008 it's default off for standard user accounts that don't have admin rights anyway. This is helpful for terminal services, which is the only reason a standard user would ever login to the server anyway.

        In all honesty all this proves is that all software has vulnerabilities. Many of us have been saying that for years however people seem to think that it's just a Microsoft defense. It's not. Trusting any one thing to keep you safe is foolish.
        • How many users are running a Windows Server edition?

          For consumers (those without Windows sysadmins looking after them), the two most important security zones in IE are the 'internet' and 'trusted sites'. In IE8, the security level of the 'internet' and 'trusted sites' zones are both set to 'medium' by default, whereas in IE9 the security level of the 'internet' zone is set to 'medium' and 'trusted sites' zone to 'low' by default.

          In IE, I always set the security level of the 'internet' zone to 'high' and, sometimes, lower it to 'medium-high' on a case-by-case basis.
          Rabid Howler Monkey
    • Sandbox smandbox

      It's time Firefox caught up with Chrome and IE and added a Sandbox. Unless Firefox can fail like IE and Chrome there's a problem? Excuse me while I roll my eyes.

      DEP and ALSR are sandboxs too. It's time to stop sandboxing and start focusing on fixing the class of bugs. Use after free is detectable FFS.
      • DEP and ASLR is not sandboxing

        They are mechanisms which are designed to thwart exploits *after* they triggered a vulnerability. Essentially they are designed to keep malicious code from getting foothold. They are not in any way designed to monitor rights or privileges of processes like sandboxes.