Slashdot Mirror
Revealed: Chrome Really Was Exploited At Pwnium 2013
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?"
Wasn't it both? They're both a component in the same vector.
it's a feature. Obligatory
That sucking sound you hear is my bandwidth.
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).
What a truly unique handle to blend into communities with.
Saying that Safari on MacOS "was not hacked" is slightly misleading. Nobody attempted to hack it, so contrary to some reports (and posts) it didn't survive anything.
PinkiePie should be given at least 41 months behind bars!! Down with all "Hackers". Put them all in Jail!!!! PFFFFTTTTTT!!!!!
This is an unashamedly attack Linux/Chrome from those, with some of the most emotive language I have ever seen [Seriously "inconvenient truth"(sic)]. The only truth here is Operating Systems are not impenetrable. Words like blame should only be thrown around, when the part of the OS is designed without security in mind; fixes are not implemented in a *timely* manner. I don't have to provide examples.
The only "inconvenient truth*(sic) is that Google and Intel are *responsible* [and others] for securing that Driver [i915], which I use on GNU/Linux, and due to this event and $4000 Google have made my computer a little more secure. It shows how incredibly successful Stallmans Licence GPL2 can be used by Linus as a "Tit for Tat" License, for an Open source graphics driver.
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).
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.
I mean apart from academic curiosity, who does give a fuck if the fault should be blamed on Linux or on Chrome ?!
The REAL ACTUAL IMPORTANT part is that the problem got discovered, so you can expect that the kernel, the config file parser and the video decoder (or the video driver if it's hardware accelerated) will get patched, sent upstream and then a wave of updates will be pushed to all the various distributions affected by said bugs.
The world will be a safer place AND THAT'S WHAT MATTERS for everyone.
Not only that, but thanks to the open nature of the whole stack (Linux kernel, rest of the ChromeOS distro, Chrome browser, or to be more precise the -ium variations of these), it's possible to scan the rest of the source to see if similar problems exist elsewere, maybe change policies or update tools to better detect such problems, inform the contributors of the affected slices of code... So a discovered exploit can even help making an even safier place.
There's no point in playing the blame game, when there are much more interesting things to do with the exploit.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
How do these winners of pwn2own compare to the average programmer? It seems you'd have to be pretty bad ass to find these flaws and exploit them in one sitting, no?
They paid this 'PinkiePie' character to badmouth both Chrome OS and Linux, with Microsoft sympathizers at Google playing along.
If you're using VT-d/IOMMU to assign a particular piece of hardware to a particular VM then that is not actually paravirtualized...you're basically running the normal driver in the VM.
Paravirtualized hardware would require the host OS to have the driver for the hardware, then present a different (usually simplified) API to the guest to allow it to do things more efficiently than fully virtualizing the hardware.
The first thing I wonder is if it also affects Chrome / Chromium when installed *without* root privileges. I hate it when you install Chrome from a .deb / .rpm because it does lots of weird stuff, like modifying /etc/apt/sources etc. and even if you then remodify it there are scripts run automatically which shall turn back on automatic updates. I hate this kind of stuff with a passion so I install Chromimum from the .zip / .tgz in a user account, without ever giving my root password. Could this hack affect me with such a setup?
Second thing which comes to mind: this is yet another buffer overflow, this time in a GPU driver apparently (which seems to be part of the exploit). We're in 2013 and there *are* solutions against this. For example the 7000 lines or so of the esL4 microkernel have been formally verified by a prover and are guaranteed to be free of any buffer overflow/overrung. During the verification hundreds of potential bugs have been found and fixed.
Why couldn't code for GPU drivers be formally verified using theorem provers?
At one point people will have to start to look into what others are doing, like the guy on that esL4 microkernel team... Because the benefits of a codebase which is guaranteed to not contain any weird pointer dereferencing exploit or any buffer overflow/overrun already goes a very long way towards more security. As I understand it the problem is that the more lines, the more times it takes and it's exponential: so we can't say "verify the entire Linux kernel" or "verify the entire Chrome codebase". But if we split things in tiny chuncks (7000 lines of code is nothing to sneeze at: it's enough to have a micro-kernel running) then we can already, today, use theorem prover to make sure the code is immune against what constitutes 99.99% of all the security exploits out there (once again, this Chrome OS / Linux / Chrome exploit was based in part on a buffer overrun). So what about we start using theorem prover on GPU drivers?
Crossing fingers and waiting for this better world...
The particular parameters of Chrome exploits aren't the big issue. Ultimately the winners disclosed serious vulns in widely-used software to the software maker, and received a big enough prize total (Google put out $xM for pwn2own) to make security matter more and motivate more of the same in the future. Meanwhile, Microsoft gives away an Xbox. Yeah, you can talk all you want, but your budget tells the truth.
During the apple / java problem debacles the consensus arose that even though the flaw was in java, apple was to blame. Surely the same apples here.
FTFY
Questions raise, answers kill. Raise questions to stay alive.
So OSX/Safari was the only one standing?
Waiting for you by the bridge
Give me a fucking grape!!
http://www.activistpost.com/2013/03/what-happens-when-2-monkeys-are-paid.html
Not a lot of info available, but one vulnerability seems to be with the i915 video driver (hence, would be limited to devices using embedded Intel graphics), and the other a Chrome bug related to GPU usage (hence, hardware acceleration) that is listed as resulting in a potential denial of service or more.
... DoS? Shell?
So the attack would likely involve a web page employing hardware acceleration, that leaks an overflow into the i915 driver, resulting in
Calling it not reliable means that there isn't a deterministic way to establish the system state needed for the exploit to work.
Google has fixed Chrome already - and now we need to watch what gets upstreamed in the i915 driver for the next week or so.
p.s. PinkiPie da Man (or woMan, don't know gender).
"Ahh! I see you're in that indeterminate Schrodinger state where - oh, uh
So, was it really Google Chrome, or was Linux to blame?
I hate to tell all you Linux dislikers this, but here it is: Chrome is just another Linux/GNU/X-windows distribution. What differentiates "Chrome" from others? A thin layer of links to Google web sites on the user interface.
How does this garbage get past a so called editor ?
In the real world does it really matter who you blame after a successful penetration of a system? Yes, they made Chrome as bulletproof as possible, yes, the platform specifics made this exploit possible, it's not a large scale out-in-the-wild kind of exploit both because it targeted a unique configuration and also, well, because there aren't many ChromeOS devices out there. Still, a successful exploit is a successful exploit. Fix it and while you're at it get off my lawn.
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.
Go ahead, it's at http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915?id=HEAD ...and there's about 19,000 lines in that particular directory (find drivers/ -name i915*|xargs cat|grep -ve '^[/ ]\*' -e ^$ |wc -l), and it depends very heavily on a few other modules (agp, ~2kloc for intel-*; there's a couple more I think...)
That's 21kloc right there, or 3 years if you have the same team that reviewed L4...and almost all of that's changed in the year from 3.4 to 3.8, if I read the output of git diff properly.
Meanwhile, Intel's working on a couple new gpus.
Chrome OS (which I assume you mean, when you say it's another Linux/GNU/X-windows distro) has a number of things that differentiate it from most other distros, including some of their own innovations and coding efforts that are being upstreamed.
See: this discussion, for example.
"Ahh! I see you're in that indeterminate Schrodinger state where - oh, uh