Revealed: Chrome Really Was Exploited At Pwnium 2013 102
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?"
Re: (Score:2)
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
Linux or Chrome? (Score:4, Insightful)
Wasn't it both? They're both a component in the same vector.
Re:Linux or Chrome? (Score:5, Insightful)
Re:Linux or Chrome? (Score:5, Insightful)
Re: (Score:1)
Please consider that no OS is secure.
Maybe ther is no "perfect security", but where is Microsoft $40,000 for each exploit?
Re:Linux or Chrome? (Score:5, Insightful)
Re: (Score:2)
If a particular sequence of events is discovered that leads to a bug in the kernal being exposed, by all means push for that kernal bug to be fixed. But in the interim and for added safety, you might also want to hamstring access to that bug in your own code (Chrome in this case). That is my whole point, s
Re: (Score:1)
At least in the case of ChromeOS, where they maintain a fork of the kernel, it would make more sense to just fix the kernel bug and push the update to users. That they didn't do this suggests they were unaware of the bug.
The problem with Linux is that kernel bugs are committed constantly. It's just ridiculous how bad things have gotten. While everybody is arguing about namespaces, SELinux, etc, etc, these same people are committing egregious exploits.
I wouldn't share resources on a Linux instance if my life
Re: (Score:1)
Interesting theory... So, if buggy kernel returns true instead of (expected) false -- application should have logic that expects kernel to misbehave and somehow work out that kernel is lying? At this point I have only one question left -- do you have any programming experience?
To turn your question around, is it your position then that IE and Safari isn't at fault for being compromised here either, if the attack also relied on bugs in Windows and OS-X (as they almost always do)?
Re: (Score:2)
If that ChromeOS box had been sitting minding it's own business with no ports open, it wouldn't have been compromised. It WAS compromised, because the Chrome browser opened ports, received data, and did things. Chrome is at fault.
That doesn't mean the bug in Linux shouldn't be fixed, but Chrome is the program that wasn't properly sanitizing outside data.
Re:Linux or Chrome? (Score:5, Interesting)
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.
Re: (Score:2)
Are you saying they didn't also patch Chrome?
Re:Linux or Chrome? (Score:5, Interesting)
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?
Re: (Score:2)
So, it sounds like Linux.
Nope. It sounds like Chrome OS. It is a component of the Linux codebase that Google included in the Chrome OS codebase of their own volition, that included an exploitable bug that they did not catch in testing.
Most manufacture these days is simply the assembly of components. Do Acer get absolved of all responsibility if a batch of hard drives fails? "Not our fault, blame Hitachi"? Exploding iPhone batteries -- "Don't blame Apple, they didn't make it"?
Re: (Score:2)
It sounds like both. Video drivers in the kernel and a config file error in Chrome.
Re:Linux or Chrome? (Score:5, 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.
Re: (Score:2)
Were the core dumps marked executable, or was cron sourcing the scripts instead of just executing them?
Re: (Score:2)
cron.d files aren't scripts and don't need to be executed or sourced (doing so wouldn't work anyway).
But if you arrange for
* * * * * root /home/me/something
to be at the start of a line in a file that is in /etc/cron.d and the file also manages to be parsable by cron then your something executable will be run as root.
It's up to you who to blame. (Score:4, 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.
It's not a bug ... (Score:5, Funny)
The answer is: Yes (Score:4, 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.
Re:The answer is: Yes (Score:5, Insightful)
Re:The answer is: Yes (Score:4, 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.
Re: (Score:2)
Thats like arguing that your supermarket isnt to blame if they sell horsemeat as steak or something.
Well, sort of. I expect them to do their due diligence. If someone misleads them intentionally, that's a mitigating factor. You blame them, and identify the party at fault, and they remedy the situation. That's how it's supposed to work, anyway.
Yes, absolutely. The end user will get recompense, and internal auditing will identify the weak link and (hopefully) resolve the issue. However, this is totally separate from:
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.
True, but all I'm saying is either the ChromeOS team screwed up something in the kernel, or
Re: (Score:2)
Well, sort of. I expect them to do their due diligence.
And at the software level, due diligence means "testing".
True, but all I'm saying is either the ChromeOS team screwed up something in the kernel, or the kernel was already exploitable.
The kernel was already exploitable. But the ChromeOS team failed to catch it in testing.
Re: (Score:1)
Um, no. If ChomeOS introduced a bug into their version of the Linux kernel, then it's their fault. A more apt analogy would be that the store bought the meat, then added some horsemeat to it, and that horsemeat made people sick.
Not that it happened that way, of course, since we don't know if it was a Linux bug (more likely) or a ChromeOS bug.
Re: (Score:2)
If a can of 'black beans' turns out to contain pork and beans, that is NOT the supermarket's fault even if it is their responsibility to handle the situation with their supplier.
Re: (Score:2)
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.
I would say that if the bug is exploitable in Chrome on other OSs, particularly non-Linux OSs, then the Chrome browser is to blame. If it is not exploitable in those OSs, but is exploitable under Linux based OSs, then Linux is to blame.
Of course, there is the possibility, indeed the probability, that every browser failed everywhere, in which case, both browser & OS were to blame.
Re: (Score:2, Funny)
But wait! The config file was really the kernel .config, and the error was setting CONFIG_ESCALATE_TO_ROOT_RANDOMLY=M.
Re: (Score:2)
Re: (Score:1)
Before we know details, we can't tell.
Generally, if kernel wasn't doing something as advertised, or at least not at the "sanity" level expected, it's a kernel problem.
If it is about the interface that is easy to misuse, or not guaranteed to be safe in the sense expected by Chrome sandbox (misuse or wrong assumption), then it's a bug in Chrome.
Rationale is that we sometimes can't draw a line and have to look at the system as a whole.
Who gives a fuck ? (Score:3, Insightful)
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
Re: (Score:3)
I mean apart from academic curiosity, who does give a fuck if the fault should be blamed on Linux or on Chrome ?!
The Brand-tribes have to know so that the guilty tribe can sacrifice a virgin[0] to the volcano gods.
[0] obSlashdot: Insert slashdot "virgin" joke of your choice here.
Re: (Score:1)
Just like the hardware world of OEM using someone's component for building a system, Google might not be directly responsible for the bug, they should be held responsible for fixing it.
Just because something is software, the vendor that sold it to you should not be able get away with it.
Re:PinkiePie (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 [wikipedia.org]. And all the bronies know that PinkiePie is the funniest of the ponies... not that I'd admit watching the show... wink, wink... ahem...
Re: (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.
Re: (Score:2, Funny)
Comment from a happy_place calling PinkiePie "kinda cute" is a bit amusing in itself, but not going to crack jokes on it here when what I find more interesting is the hint that there potentially is a hacker/cracker group out there called "My Little Pwnies". Will leave the humor and fact finding to those more interested and better suited for each of those categories.
Re: (Score:2, Funny)
All we need is the OCD freak who tests everything meticulously, the simple hard-worker who keeps at it, the rock-star coder obsessed with speed, the hacker who's all about style, and the shy introvert with a menagerie of botnets and they could summon the freaking elements of exploitation.
Re:Misleading (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.
Re: (Score:1)
The OS X kernel and POSIX layer are all open source. There is no security through obscurity.
Re: (Score:1)
Re: (Score:2)
Right... that's why it was gleefully hacked in all of the preceding years. It's time to put that tired old chestnut to bed and think up some new material.
Re: (Score:1)
Well, yes and no. I would remind our readers that both Chrome and Safari are based on WebKit and soon, because I can't stop it, Opera too. So it's at least interesting that, despite this commonality, the attack was executed and somewhat sucessful on Chrome but not Safari. The point is with BSD and WebKit at the core of MacOS X and Safari, neither of them are completely obscure. Though I won't argue the disinterest part.
Re: (Score:2)
Yes, people just didn't want that money.
Re: (Score:2)
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.
As it was slightly misleading in the previous few years when it was "the first browser" hacked (or some variation thereof). Someone found an exploit and they were first up.
Where is the justice? (Score:2, Funny)
PinkiePie should be given at least 41 months behind bars!! Down with all "Hackers". Put them all in Jail!!!! PFFFFTTTTTT!!!!!
XEN para-virtualized browsers in Qubes OS (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 [qubes-os.org] 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).
Re: (Score:2)
"Even device drivers are paravirtualized"
How can you virtualise device drivers? Either they access hardware directly or they don't. If they don't then what runs the hardware?
Re: (Score:2)
IOMMU hardware in recent CPUs translates the device into the VMs address space. Then the kernel running inside the VM can use its normal drivers to operate the device at essentially full speed.
The kernel that runs the hypervisor only runs a limited set of drivers by default.
Re: (Score:1)
http://en.wikipedia.org/wiki/Paravirtualization [wikipedia.org]
drivers *not* paravirtualized (Score:2)
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.
Re: (Score:2)
OK, thanks for correcting my terminology there!
Re:XEN para-virtualized browsers in Qubes OS (Score:5, 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
Re: (Score:2)
Re: (Score:2)
It's only evil when it's forced on the user. User access to the entire filesystem on their own device IS a right.
Re: (Score:1)
the problem being that when apple sandboxes, it doesn't give the program the option to offer the user the ability to access files elsewhere or to raise its priviledges. It just defaults to "no" and there's no way to change it to "yes," even if you want to. So yes, it's evil because it assumes you'll never be smart enough to make the choice "yes" instead of "no."
Re: (Score:2, Informative)
the problem being that when apple sandboxes, it doesn't give the program the option to offer the user the ability to access files elsewhere or to raise its priviledges. It just defaults to "no" and there's no way to change it to "yes," even if you want to. So yes, it's evil because it assumes you'll never be smart enough to make the choice "yes" instead of "no."
Total nonsense. Apple's approach to sandboxing is centered around giving users the very power you claim they're denying. Say a user wants to open a file in a sandboxed app, and that file doesn't reside inside the app's private storage area (the isolated chunk of filesystem where it is free to create/open/delete files at will). The user uses the "open" command from the menu or the keyboard, same as any pre-sandbox GUI app. But instead of presenting its own UI for file opening, the sandboxed app makes a l
Re: (Score:2)
Cliff Notes version: Modern OSes should adhere to the principle of least privilege.
Re: (Score:2)
The principle has always been good, but implementing it in a way where you can actually work with it has always been harder. Most systems that try to do this don't have a good answer to letting the user deal with it.
Re: (Score:2)
IMHO this is more like a work-around that a real solution. You have to allocate RAM for each application VM, which is really unpractical and will impact performance. A better approach seems to be to build security from the top down by extending chroot into things like Linux Containers and FreeBSD jails. You get similar isolation for applications, but full system performance. You don't have the extra security of isolation for the drivers, that wouldn't be possible in Linux without virtualisation. However, i
Re: (Score:2)
Yes, nothing is 100% efficient or safe. I don't mind throwing a couple extra GB at the problem of security, however, especially if it gets me robust hardware-backed isolation.
Chrome hack to get GPU (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 [nist.gov]
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 [webpronews.com]
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.
Re: (Score:2)
They find them ahead of time.
Re: (Score:2)
Microsoft sympathizers at Google
OK, that was funny.
OSX/Safari (Score:2)
So OSX/Safari was the only one standing?
Re: (Score:1)
Considering OS X has a much higher share VS. Linux, and the fact that Safari is used on hundreds of millions of iOS devices...your comment is...full of shit?
Re: (Score:1)
Yea, call it what you want AC but Safari was apparently the most secure among the bunch. Like it or not.
Sent from my iPhone
Analyzing the exploit (Score:3)
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).
Chrome IS Linux/GNU/X (Score:2)
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.
Wrong wrong wrong (Score:2)
See: this discussion [slashdot.org], for example.
Obvious troll article (Score:2, Insightful)
Re: (Score:1)