CanSecWest Pwnium: Google Chrome hacked with sandbox bypass

CanSecWest Pwnium: Google Chrome hacked with sandbox bypass

Summary: The attack, which included a Chrome sandbox bypass, was the handiwork of Sergey Glazunov, a security researcher who regularly finds and reports Chrome security holes.


VANCOUVER -- A Russian university student hacked into a fully patched Windows 7 machine (64-bit) using a remote code execution vulnerability/exploit in Google's Chrome web browser.

The attack, which included a Chrome sandbox bypass, was the handiwork of Sergey Glazunov, a security researcher who regularly finds and reports Chrome security holes.

follow Ryan Naraine on twitter

Glazunov scored a $60,000 payday for the exploit, which targeted two distinct zero-day vulnerabilities in the Chrome extension sub-system.  The cash prize was part of Google's new Pwnium hacker contest which is being run this year as an alternative to the more well-known Pwn2Own challenge.

According to Justin Schuh, a member of the Chrome security team, Glazunov's exploit was specific to Chrome and bypassed the browser sandbox entirely.  "It didn't break out of the sandbox [but] it avoided the sandbox," Schuh said in an interview.

[ SEE: Charlie Miller skipping Pwn2Own as new rules change hacking game ]

Schuh described the attack as "very impressive" and made it clear that the exploit "could have done anything" on the infected machine.  "He (Glazunov) executed code with full permission of the logged on user."

"It was an impressive exploit.  It required a deep understanding of how Chrome works," Schuh added. "This is not a trivial thing to do.  It's a very difficult and that's why we're paying $60,000.

Glazunov is a regular contributor to Google's bug bounty program and Schuh raved about the quality of his research work.

Schuh said Glazunov once submitted a similar sandbox bypass bug but stressed that these kinds of full code execution that executes code outside the browser sandbox form a very small percentage of bug submissions.

Google's Sundar Pichai says the company is "working fast on a fix" that will  be pushed out via the browser's automatic update utility.

Topics: Apps, Browser, CXO, Google, IT Employment

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 chrome has security bugs

    The fanbois said it was secure. No that's of course myth, fantasy. There's no doubt hundreds more just waiting to be sold on the black market for more than google is paying.
    Johnny Vegas
  • As has been documented by Google Engineers in their Chromium 'Caveats'



    "The operating system might have bugs. Of interest are bugs in the Windows API that allow the bypass of the regular security checks. If such a bug exists, malware will be able to bypass the sandbox restrictions and broker policy and possibly compromise the computer. Under Windows, there is no practical way to prevent code in the sandbox from calling a system service.

    In addition, third party software, particularly anti-malware solutions, can create new attack vectors. The most troublesome are applications that inject dlls in order to enable some (usually unwanted) capability. These dlls will also get injected in the sandbox process. In the best case they will malfunction, and in the worst case can create backdoors to other processes or to the file system itself, enabling specially crafted malware to escape the sandbox."[/b]

    Windows 7 and all revisions share the same legacy WinNT kernel.

    The Windows kernel cannot police itself.

    Unlike Windows, Linux LSM can and does police the actions taken by the kernel.
    This is what makes Linux the more secure solution and with an App sandboxed in LSM, there isn't a worry about zero day exploits. They have no effect whatsoever.

    This exploit will be confirmed as a DLL injection attack which the Google Engineers cannot protect against.
    Dietrich T. Schmitz *Your
    • Questions ?

      Is LSM enabled by default ?
      Can my grandmother enable it without opening a terminal window ?
      If enabled will it break anything else ?
      • And ...

        What happens if a file protected by LSM is exposed via a hard-link and then compromized via a process that is NOT protected by LSM?

        I don't know why we bother with DTS: He keeps posting that LSM is the silver bullet and saviour from all malicious attacks. You, I and others keep pointing out the well-known flaws with LSM, which he continues to ignore.

        Sad really.
      • Answers

        "Is LSM enabled by default ?" - yes, in every Linux I install (home and work).

        "Can my grandmother enable it without opening a terminal window ?" Dear dear grandma-ma has passed (though she may be using Linux where she is now :-) ), but i'll answer for my mom - yes, she enables it by booting the machine, because I've configured it in.

        "If enabled will it break anything else ?" - no, because I test required apps.

        Less tongue-in-cheek, I understand what you're poking at - that it's not enabled by default in many distros, and that a non-IT end user might have difficulty doing so. But that's a criticism of the Linux business and distribution model, not the security capabilities of Linux. And certainly for a professional setting, where an IT dept appropriately controls the configuration of any client OS, it's completely relevant that LSM-leveraging implementations provide significant security benefit.

        So you're ignoring his point by deliberately poking at non sequiturs. No, Linux doesn't have the same business model as Windows, where one company takes near-complete responsibility for the security of the OS. Understood, there's advantages to that model (and to the Linux model as well -- not least of which is the non-homogeneity dilutes the value of any potential exploit).

        Now, bitcrazed's comment below is different - pointing out that exploits are still possible. True - but it has to be viewed from a defense-in-depth perspective, and such potential exploits understood in context. What would it take to create the environment needed for the exploit he lists? And what process is not LSM protected? Just saying "there's ways around it" doesn't mean there's practical exploits available. And it STILL doesn't mean it's not better than alternatives, e.g., the Windows security model.
      • RE: Questions ?

        [i]Is LSM enabled by default ?[/i]
        Depends on the Linux distro and specific app. Debian? No. Ubuntu/Linux Mint? Yes, for services such as cups, but not for Firefox.

        [i]Can my grandmother enable it without opening a terminal window ?[/i]
        Depends on the distro. Both openSUSE (uses AppArmor) and Mandriva (uses Tomoyo) include GUI tools for building LSM app profiles and policies. Still, users must adequately 'train' their apps. I suspect that many users would also be stumped with the GUI tools.

        [i]If enabled will it break anything else ?[/i]
        Depends on the default profile/policy provided by the distro and how one uses their web browser. Add-ons, plug-ins (e.g., Flash, Java, PDF Reader, media player), printing (to a printer or PDF/PS file), downloading files and starting one's email client when an email address hyperlink is clicked could easily be broken.

        What's interesting is that Google has chosen NOT to use LSM for sandboxing Chrome/Chromium on Linux. Why? There's too much variability among the distros wrt the LSM used (e.g., SELinux, AppArmor, Tomoyo) and whether or not an LSM is enabled by default (e.g., Debian). Instead of LSM, the default sandbox for Chrome/Chromium uses suid, chroot and clone. And most importantly, Chrome/Chromium is sandboxed by default on most Linux distros requiring no action by users.
        Rabid Howler Monkey
        • This confirms to me you don't understand.

          Google have written a 'sandbox' for Linux. Take the time to do the research and you'll find it.
          But a software vendor doesn't choose LSM for their App. LSM is part of the Linux Main Line Kernel (DKMS) installable by a 'User' who choose which application to sandbox with it.

          An exploit CANNOT propagate from a running App which is sandboxed in LSM.
          If you choose to not run LSM, then you are left with Linux default security matrix and Chrome's internal sandboxing defense measures, which by themselves are pretty good.
          Dietrich T. Schmitz *Your
    • If this was indeed the case here, don't you think Google would

      have refrained from awarding the 60K? You figure they are just being 'sports'? Face it, the exploit WAS in Chrome. Google admitted this, why can't you?
      "???It was an impressive exploit. It required a deep understanding of how Chrome works,??? Schuh added. ???This is not a trivial thing to do. It???s a very difficult and that???s why we???re paying $60,000."
      Didn't see a single reference to a deep understanding of how Windows allows Chrome to be exploited.

      I think you fib to further your agenda.
      • I think you miss the point.

        Chrome is making up for the deficits of the operating system.
        It is the role of the operating system to defend against attacks, not the app.

        This is the point of LSM standing outside the kernel and policing all the app and kernel (both) activities--it is a third party monitor.

        Windows has no such capability. LSM does not exist.
        Thus, placing any App generally speaking in LSM on Linux won't stop developers from writing code with bugs that can be exploited. What it does is stops zero-day exploits from gaining privilege escalation.

        Please educate yourself. Developers should not be the bearers of full responsibility for the security of the underlying operating system.

        There's no agenda here other than to educate the readers who may not know such as yourself.
        Dietrich T. Schmitz *Your
      • I think this time YOU miss the point.

        Could this have worked with any other browser running on Windows 7? No. Therefore the vulnerability was in Chrome NOT in Windows.
    • Windows "OS"

      This all is because, Windows is essentially GUI on top of DOS.

      Let's hope WinRT will change that. It's 21st century already.
      • go fans

        Go fans, Go. That won't change reality though. :)
    • Incorrect. This will not be confirmed by Google engineers as

      this in not an OS related exploit. Instead it will comfirmed that it is a Google (and highly likely) an LSM related issue as a result of poor coding.

      Making excuses for your misplaced trust in open sorce software will not change the facts.
      Tim Cook
      • An LSM related issue? On a Win7 box?

        Has MS publicized that they've adopted LSM?

        And "poor coding"? This guy isn't a script kiddie ...
    • Dietrich, Dietrich, Dietrich...

      [b]A Russian university student hacked into a fully patched Windows 7 machine (64-bit) [i]using a remote code execution vulnerability/exploit in Google???s Chrome web browser[/i].

      The attack, [i]which included a Chrome sandbox bypass[/i], was the handiwork of Sergey Glazunov, a security researcher who regularly finds and reports Chrome security holes.[/b]

      This quote from the article says it all. Emphasis mine.
  • google propaganda

    Its evident that all this google huha about the chrome security /speed is pure bulls**t.

    For cash I will do anything I thank you Firozali A.Mulla DBA