Slashdot Mirror

← Back to Stories (view on slashdot.org)

Revealed: Chrome Really Was Exploited At Pwnium 2013

Posted by timothy on from the for-some-values-of-exploited dept.

Freshly Exhumed writes with an "inconvenient truth" as reported at Internet News: "Google Chrome running Chrome OS was hailed as being a survivor in the Pwnium/Pwn2own event that hacked IE, Firefox and Chrome browsers on Windows. Apple's Safari running on Mac OS X was not hacked and neither (apparently) was Chrome on Chrome OS. Google disclosed [Monday] morning that Chrome on Chrome OS had in fact been exploited — albeit, unreliably. The same researcher that took Google's money last year for exploiting Chrome, known publicly only as 'PinkiePie' was awarded $40,000 for exploiting Chrome/Chrome OS via a Linux kernel bug, config file error and a video parsing flaw." Asks Freshly Exhumed: "So, was it really Google Chrome, or was Linux to blame?"

18 of 102 comments (clear)

  1. Linux or Chrome? by dintech · · Score: 4, Insightful

    So, was it really Google Chrome, or was Linux to blame

    Wasn't it both? They're both a component in the same vector.

    1. Re:Linux or Chrome? by R.Mo_Robert · · Score: 5, Interesting

      So, was it really Google Chrome, or was Linux to blame

      Wasn't it both? They're both a component in the same vector.

      If only there was "article" you could read that might tell you. From TFA: The same researcher that took Google's money last year for exploiting Chrome, known publicly only as 'PinkiePie' was awarded $40,000 for exploiting Chrome/Chrome OS via a Linux kernel bug, config file error and a video parsing flaw. So, it sounds like Linux. Google fixed this by patching Chrome OS, not Chrome per se.

      --
      R.Mo
    2. Re:Linux or Chrome? by dintech · · Score: 4, Insightful

      I do know this. The attack was via Chrome. It may have exploited a bug in Linux underneath, but so does any attack on Windows or MacOSX via browsers. Nice try at being at trolling but you'd be better off over at 4chan.

    3. Re:Linux or Chrome? by Sarten-X · · Score: 4, Informative

      Of course, but let's make it a polarized finger-pointing issue anyway! That's the American way!

      Yeah, it's Chrome's fault for letting the untrusted code claim to be somewhat trusted. It's the kernel's fault for letting that questionable code become fully trusted. It reminds me of one of my favorite exploits where the kernel would helpfully drop core dumps in any directory the application said it was running from... including /etc/cron.d. A crafted program segfaulting could run a cron job to do aything as root. The attack didn't really exploit either program's faulty behavior, but rather the interaction between them.

      --
      You do not have a moral or legal right to do absolutely anything you want.
    4. Re:Linux or Chrome? by jittles · · Score: 4, Interesting

      So, was it really Google Chrome, or was Linux to blame

      Wasn't it both? They're both a component in the same vector.

      If only there was "article" you could read that might tell you. From TFA: The same researcher that took Google's money last year for exploiting Chrome, known publicly only as 'PinkiePie' was awarded $40,000 for exploiting Chrome/Chrome OS via a Linux kernel bug, config file error and a video parsing flaw. So, it sounds like Linux. Google fixed this by patching Chrome OS, not Chrome per se.

      I don't know that it guarantees that it is a Linux problem. Did they modify the Linux source to do something specific for Chrome OS? Is the video parsing issue specific to Chrome OS? Did they do something non-standard or inherently unsafe with the config file?

    5. Re:Linux or Chrome? by dintech · · Score: 5, Insightful

      You are mistaken. If Chrome allowed a bug in the OS to be exploited via Chrome, both are at fault. Please consider that no OS is secure. That doesn't mean that browser developers should just give up on security.

    6. Re:Linux or Chrome? by dintech · · Score: 4, Insightful

      If we're talking about a kernel call that may allow escalations of privileges and you are not yourself sanity checking what that what's coming from some box on the internet, then fucking yes, be suspicious. You know something about code but seem to know very little about security in the real world. You my friend are the most dangerous kind of programmer around.

  2. It's not a bug ... by Thing+I+am · · Score: 5, Funny

    it's a feature. Obligatory

    --
    That sucking sound you hear is my bandwidth.
  3. The answer is: Yes by ByOhTek · · Score: 3, Insightful

    The kernel shouldn't have had the bug, so Linux is to blame.
    Chrome OS is built on Linux by choice, not necessity (they could have used FreeBSD, Minix, or even done a UI replacement of Windows if they wanted to spend more $$$), so... since they didn't fix the bug in their chosen, and open source OS, it's their fault too.

    Blame doesn't always have to fall on one party, it can fall on multiple parties who all didn't do due diligence, or no parties when the problem was from nature, and nobody could have reasonably predicted it.

    --
    Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
    1. Re:The answer is: Yes by L4t3r4lu5 · · Score: 4, Insightful

      I would argue that if the bug is exploitable in non-ChromeOS kernels then Linux is to blame. If the bug was introduced by the ChromeOS implementation, then it's the fault of ChromeOS.

      --
      Finally had enough. Come see us over at https://soylentnews.org/
    2. Re:The answer is: Yes by LordLimecat · · Score: 3, Interesting

      Thats like arguing that your supermarket isnt to blame if they sell horsemeat as steak or something. You blame them (they are responsible for vetting the product they provide), and they will blame their vendor (who sold them a bad product).

      As parent said, blame isnt this binary thing; multiple people can be at fault simultaneously, but as Chrome's vendor, the end user should look to Google for answers-- its not Linus' job to fix Chrome OS, its Google's.

  4. Re:Misleading by BasilBrush · · Score: 5, Insightful

    You don't seem to understand how Pwn2Own works. People don't arrive at the contest, pick an OS/Browser and then start looking for an exploit.

    They begin weeks in advance looking for exploits. IF they find one, then they go to the contest and select the appropriate platform and demonstrate the exploit. Their demonstration may fail, because the versions of the software on the contest platform might be different from what they were practicing with.

    That no one "attempted to hack" OSX and Safari at the competition this year is because in the past few weeks of trying, no one has found an exploit for it. It's certainly not the case that they could have won the prize, but couldn't be bothered.

  5. XEN para-virtualized browsers in Qubes OS by Burz · · Score: 5, Interesting

    The browser is a rather complex beast and there is probably no way that the application itself can ensure system integrity... at least with any consistency.

    Some of us are migrating our online activities to Qubes OS which is a desktop distro (I know...) that allows you to create App VM domains for things like "personal", "work", "unsafe", etc. and also a "disposable" one that gets reset on exit. Each domain of apps is displayed in window borders that have an associated color.

    Taking it further, some of the commonly-attacked system components like the network stack are virtualized as well.

    Qubes employs VT-x and VT-d/IOMMU hardware to allow you to operate different types of peripherals (like bluetooth) without incurring all of the risk they normally carry. Even device drivers are paravirtualized! So the attack surface that can be used against the core system (or any other domains in the system) is kept to a bare minimum.

    An added benefit of this approach is that user activities are tracked somewhat less than normal (especially if you use disposable VMs).

    1. Re:XEN para-virtualized browsers in Qubes OS by ledow · · Score: 4, Interesting

      You mean the same idea I've been asking for for about 15 years, otherwise known as bottling, process separation and lots of other fancy terms?

      Your browser doesn't need access to the hard disk, except a single, solitary folder for downloads. That's it. It shouldn't even KNOW where that folder is, nor if it's in memory or a disk, or a network share. Hell, it shouldn't even be allowed to have the capability to look, let alone actually find out.

      For uploads, the browser requests that YOU supply the information to the browser process bottle, and it takes it once supplied and does what's necessary. It has no need to have arbitrary access to every file visible on your system, only those it creates itself inside its bottle, or those you explicitly provide it with through some system mechanism. Similarly, it has no need to do anything more than put out a HTTP request and get a response.

      Something else, somewhere, will handle, authorise and sanitise that request and response and do NOTHING else. Yes or NO. The program should have NO way to detect what that process is (so if the user wants to run in a zero-privilege environment, the browser just has to cope with that rather than say "I can't run without admin").

      Now replace "browser" with "word processor", "spreadsheet", "hardware utility" or anything else that you use on your system.

      The problem we have is that we've come from general purpose OS that were designed to let all processes have access to anything that wasn't explicitly locked away from them. The fix is to give processes the absolute bare minimum they require to do their work, make them ASK for everything, and refuse any request that you don't like. And make every process work (for the correct definition of work) even when tested inside a bottle that ALWAYS gets No to every request.

      We've sort of tacked on such security features to today's OS (Unix-likes are certainly closer than, say, Windows), which historically always said "Yes", and now we have to start with one that says "No" all the time, for everything, and gives nothing to a process that isn't 100% necessary.

      Replace all "file open dialog" actions with a system component that does NOTHING but let the user choose a file (Windows started out with the right idea here, but fails terribly in implementation). Hell, theming is then permanent and to the user's preference (and the program needs know NOTHING of the theme chosen or anything else) and nobody has to (or can) run around recreating an official file-open dialog. You can even "green-bar" official file-open dialogs (like we do with padlocks on SSL sites) so that they are distinguishable from rogue processes trying to create fake file-open dialogs (even though those would not be able to escape the bottle to read files anyway!). Make it so that NO other process can green-bar a file-open window except the file-open process.

      Hell, why should a process even be able to know or change whether it's full-screen, windowed, the window size, etc.? Instantly you take ten options out of every game that has "recreated" those options and decisions for you and leave it to the user to decide. Game X will ALWAYS load fullscreen. Any process marked as a "Game" will only be fullscreen when I press this button. Or even "No process can EVER go fullscreen because I always like to see my Start Bar". And the process will have no way to know, and no way to override the decision of the user. All it knows is that it has a bitmap area it can draw to which is copied to the screen when it asks. It can't tell if that copy is a copy-and-scale into a window bitmap, or direct copy to video memory, or even just copy to a screenshot / VNC program.

      Assuming a program wants to open a file, the program calls the function to open said dialog and is blocked until it returns. It can't do anything else but request it. The dialog is run in a process all of its own and has access to read file names in user-allowed folders, display things in a file-open dialog on-screen (again, subj

  6. Chrome hack to get GPU by Halotron1 · · Score: 3, Interesting

    Chrome OS bug:
    The CVE-2013-0913 hack was was a buffer overflow in the GPU for Chrome OS / Linux.
    http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0913

    Chrome browser bug:
    Last year's PinkiePie hack chained multiple Chrome (browser) bugs together to be able to get to the GPU.
    http://www.webpronews.com/google-chrome-cracked-by-six-bug-combo-2012-05

    They didn't release details yet, but odds are since it's the same person he probably used a similar method to hack the browser and get access to the GPU of the OS.

  7. Re:PinkiePie by happy_place · · Score: 5, Informative

    PinkiePie is one of the My Little Ponies. That handle's kinda cute, considering that that those that are pwn'd are sometimes called Pwnies and there are the Pwnie Awards. And all the bronies know that PinkiePie is the funniest of the ponies... not that I'd admit watching the show... wink, wink... ahem...

    --
    http://www.beanleafpress.com
  8. Re:PinkiePie by Anonymous Coward · · Score: 3, Insightful

    Appropriate too. Pinkie Pie has a reputation for breaking the fourth wall and using that as a readily available exploit. Normal reality and it's laws of physics simply don't apply.

  9. It's up to you who to blame. by Requiem18th · · Score: 3, Insightful

    The blame falls to neither or both of them. It's completelly up to you.

    If you are a Linux developer you want to make that sure it remains secure even if Chrome fucks up. If you are a Chrome developer, you want to make sure you have covered all your bases for all the different OS you are developing for. If you are a fanboy, you want to blame whatever product you aren't a fan of. If you are just a practical person, you care little about the blaming game and simply chose dependinig on which platform you are more invested in, Linux or Chorme.

    PS: I still can't believe Google named its browser after an internal technology of Mozilla. Hell, I still can't believe MS named its VM after a TLD.

    --
    But... the future refused to change.