Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Revealed: Chrome Really Was Exploited At Pwnium 2013

timothy posted about a year and a half ago | from the for-some-values-of-exploited dept.

Google 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?"

Sorry! There are no comments related to the filter you selected.

The Muzzies are coming (-1)

Anonymous Coward | about a year and a half ago | (#43212587)

The Muzzies are coming
The Muzzies are coming
Everyone keep calm
They're evil and they're violent
and they mean to do us harm

Chrome to blame (-1)

noh8rz10 (2716597) | about a year and a half ago | (#43213487)

During the apple / java problem debacles the consensus arose that even though the flaw was in java, apple was to blame. Surely the same applies here.

Re:Chrome to blame (1)

c0lo (1497653) | about a year and a half ago | (#43213649)

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

Re:The Muzzies are coming (-1)

Anonymous Coward | about a year and a half ago | (#43216697)

Shut up Chrisq, you racist bastard. Next time you post this filth, at least log in so you're filtered.

Linux or Chrome? (4, Insightful)

dintech (998802) | about a year and a half ago | (#43212597)

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

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

Re:Linux or Chrome? (-1, Flamebait)

Anonymous Coward | about a year and a half ago | (#43212611)

In other words, you have no idea either. Nice attempt at whoring for karma though, but that kind of thing gets you more points on reddit these days.

Re:Linux or Chrome? (4, Insightful)

dintech (998802) | about a year and a half ago | (#43212663)

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.

Re:Linux or Chrome? (-1)

Anonymous Coward | about a year and a half ago | (#43212857)

That's a load of crap, you can't secure a program on an insecure OS. If the fault lays in the lap of Linux, Chrome is innocent, if Linux returned a poor or undefined value, and chrome freaked out over it, then the OS didn't fail, and Chrome was pwnd.

This can only be determined once the method is revealed.

Re:Linux or Chrome? (5, Insightful)

dintech (998802) | about a year and a half ago | (#43213025)

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.

Re:Linux or Chrome? (-1)

Anonymous Coward | about a year and a half ago | (#43213489)

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?

Re:Linux or Chrome? (4, Insightful)

dintech (998802) | about a year and a half ago | (#43213551)

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.

Re:Linux or Chrome? (0)

Anonymous Coward | about a year and a half ago | (#43214693)

Every kernel call can potentially escalate privileges if the kernel code has a bug.

Have you ever heard of TOCTTOU? There's a similar phenomenon w/ input formatting. The only code which has all the necessary information regarding the proper data format is the code actually consuming the input.

Sanity checking input is not good security practice. It should be a last, last resort. Most input sanity checking code simply adds more attack surface.

As a general rule, more code is bad. You want less code.

And not every kernel is as vulnerable as you think. The Linux kernel is as bug ridden as the Windows kernel. There are other open source kernels where people are more concerned with simple code, and removing code, instead of furiously adding features every hour. The number of local root exploits tends to be an order of magnitude less, not because they're smarter, but because code churn breeds bugs.

Re:Linux or Chrome? (1)

dintech (998802) | about a year and a half ago | (#43215027)

I strongly agree that excess code can mean more bugs, I often code in one of the most terse lanugages [wikipedia.org] in existence for that reason. However, in this case, clearly some required defensive code was absent.

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, security does not have to be in one direction only. There isn't a hard requirement that you trust the platform you run on implicitly. I agree that you can't second guess everything that goes to and from the kernal but it's very clearly misplaced trust in this instance.

Re:Linux or Chrome? (1)

Anonymous Coward | about a year and a half ago | (#43215637)

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 depended on it. Security policy is worth nothing if the code implementing it is crap, and there's too much broken code in the kernel, unfortunately. Linux long ago crossed the threshold where there aren't enough eyes to sanity check the thousands of lines of features and refactoring committed every day.

Re:Linux or Chrome? (1)

Anonymous Coward | about a year and a half ago | (#43214115)

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: Linux or Chrome? (0)

Anonymous Coward | about a year and a half ago | (#43216029)

Yes, Safari isn't at fault for being compromised because it was the only browser that wasn't.

Re:Linux or Chrome? (1)

peawormsworth (1575267) | about a year and a half ago | (#43228835)

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? (1)

ceoyoyo (59147) | about a year and a half ago | (#43214809)

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? (5, Interesting)

R.Mo_Robert (737913) | about a year and a half ago | (#43212651)

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.

Re:Linux or Chrome? (1)

dintech (998802) | about a year and a half ago | (#43212681)

As is typical for Google, they offer very little in the way of full-disclosure or detail on the flaw fixed.

Are you saying they didn't also patch Chrome?

Re:Linux or Chrome? (4, Interesting)

jittles (1613415) | about a year and a half ago | (#43212993)

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?

Re:Linux or Chrome? (1)

Half-pint HAL (718102) | about a year and a half ago | (#43214347)

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:Linux or Chrome? (1)

sjames (1099) | about a year and a half ago | (#43214819)

It sounds like both. Video drivers in the kernel and a config file error in Chrome.

Re:Linux or Chrome? (4, Informative)

Sarten-X (1102295) | about a year and a half ago | (#43212785)

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:Linux or Chrome? (1)

characterZer0 (138196) | about a year and a half ago | (#43212835)

Were the core dumps marked executable, or was cron sourcing the scripts instead of just executing them?

Re:Linux or Chrome? (1)

nedlohs (1335013) | about a year and a half ago | (#43212961)

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.

Re:Linux or Chrome? (0)

Anonymous Coward | about a year and a half ago | (#43213743)

Hmm really easy.

1. mmap NULL.
2. Write that buffer to NULL.
3. mmap remove the entire rest of the address space. Presto segfault returning from mmap.

It's up to you who to blame. (3, Insightful)

Requiem18th (742389) | about a year and a half ago | (#43216071)

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.

Re:It's up to you who to blame. (0)

Anonymous Coward | about a year and a half ago | (#43242225)

I wouldn't call Chrome an internal technology of Mozilla so much as a descriptive label for UI presentation components.

It's not a bug ... (5, Funny)

Thing I am (761900) | about a year and a half ago | (#43212605)

it's a feature. Obligatory

Re:It's not a bug ... (0)

Anonymous Coward | about a year and a half ago | (#43212729)

Wrong company.

The answer is: Yes (3, Insightful)

ByOhTek (1181381) | about a year and a half ago | (#43212617)

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 (4, Insightful)

L4t3r4lu5 (1216702) | about a year and a half ago | (#43212649)

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.

Re:The answer is: Yes (3, Interesting)

LordLimecat (1103839) | about a year and a half ago | (#43213087)

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:The answer is: Yes (1)

L4t3r4lu5 (1216702) | about a year and a half ago | (#43213685)

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 the kernel was already exploitable. ChromeOS may well have provided a path to execute the exploit, but ultimately the kernel should have given a big fat DENIED message when told to do the naughty.

Re:The answer is: Yes (1)

Half-pint HAL (718102) | about a year and a half ago | (#43214391)

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:The answer is: Yes (1)

Anonymous Coward | about a year and a half ago | (#43214237)

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:The answer is: Yes (1)

sjames (1099) | about a year and a half ago | (#43214851)

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:The answer is: Yes (1)

unixisc (2429386) | about a year and a half ago | (#43214581)

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:The answer is: Yes (0)

Anonymous Coward | about a year and a half ago | (#43212695)

Considering that there was a config file error and video parsing area I'd say Chrome was also at fault.

Re:The answer is: Yes (2, Funny)

Anonymous Coward | about a year and a half ago | (#43212727)

But wait! The config file was really the kernel .config, and the error was setting CONFIG_ESCALATE_TO_ROOT_RANDOMLY=M.

Re:The answer is: Yes (2)

Gr8Apes (679165) | about a year and a half ago | (#43212739)

The kernel is a general purpose manager. Was the error really in the kernel? Without a detailed analysis, saying that it's a kernel flaw, but requiring a configuration that's considered an error is more than a little disingenuous. I think the video processing error was just a vector for the attack, I'd be willing to bet that there are other vectors available as well.

Re:The answer is: Yes (1)

Anonymous Coward | about a year and a half ago | (#43212867)

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 ? (2, Insightful)

DrYak (748999) | about a year and a half ago | (#43212943)

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.

Re:Who gives a fuck ? (2)

geminidomino (614729) | about a year and a half ago | (#43213375)

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:The answer is: Yes (1)

Anonymous Coward | about a year and a half ago | (#43212967)

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.

PinkiePie (0)

Anonymous Coward | about a year and a half ago | (#43212715)

What a truly unique handle to blend into communities with.

Re:PinkiePie (-1)

Anonymous Coward | about a year and a half ago | (#43212771)

(S)he's known publicly as Pinkie Pie. Obviously this is a case of parents who hate their children, and named them accordingly.

Let the schoolyard-beatings and lunch-money-stealings resume!

Re:PinkiePie (5, Informative)

happy_place (632005) | about a year and a half ago | (#43212971)

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:PinkiePie (3, Insightful)

Anonymous Coward | about a year and a half ago | (#43213291)

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:PinkiePie (2, Funny)

Anonymous Coward | about a year and a half ago | (#43215025)

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:PinkiePie (2, Funny)

Anonymous Coward | about a year and a half ago | (#43216949)

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.

Misleading (0, Informative)

Anonymous Coward | about a year and a half ago | (#43212747)

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.

Re:Misleading (5, Insightful)

BasilBrush (643681) | about a year and a half ago | (#43212831)

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:Misleading (-1)

Custard Horse (1527495) | about a year and a half ago | (#43213115)

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.

It survived due to disinterest = security through obscurity

As an aside, security issues can be instantly fixed on ChromeOS by putting a nail through the NIC or, if you prefer the analogy and theatricality, by using a silver bullet.

Re:Misleading (1)

Anonymous Coward | about a year and a half ago | (#43213163)

The OS X kernel and POSIX layer are all open source. There is no security through obscurity.

Re:Misleading (1)

WhatAreYouDoingHere (2458602) | about a year and a half ago | (#43213419)

The fine folks running ioccc.org [ioccc.org] may disagree... just because you have the source code doesn't mean every thing therein is perspicuous.

Re:Misleading (1)

ceoyoyo (59147) | about a year and a half ago | (#43214845)

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:Misleading (1)

Anonymous Coward | about a year and a half ago | (#43214911)

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:Misleading (1)

Goaway (82658) | about a year and a half ago | (#43215369)

Yes, people just didn't want that money.

Re:Misleading (1)

RatPh!nk (216977) | about a year and a half ago | (#43213531)

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? (2, Funny)

Anonymous Coward | about a year and a half ago | (#43212749)

PinkiePie should be given at least 41 months behind bars!! Down with all "Hackers". Put them all in Jail!!!! PFFFFTTTTTT!!!!!

Re:Where is the justice? (-1)

Anonymous Coward | about a year and a half ago | (#43212895)

+1, Funny

Google is a responsible firm (0, Redundant)

tuppe666 (904118) | about a year and a half ago | (#43212829)

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.

XEN para-virtualized browsers in Qubes OS (5, Interesting)

Burz (138833) | about a year and a half ago | (#43212855)

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:XEN para-virtualized browsers in Qubes OS (1)

Viol8 (599362) | about a year and a half ago | (#43212953)

"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:XEN para-virtualized browsers in Qubes OS (1)

Burz (138833) | about a year and a half ago | (#43213043)

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.

drivers *not* paravirtualized (1)

Chirs (87576) | about a year and a half ago | (#43213157)

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:drivers *not* paravirtualized (1)

Burz (138833) | about a year and a half ago | (#43213175)

OK, thanks for correcting my terminology there!

Re:XEN para-virtualized browsers in Qubes OS (4, Interesting)

ledow (319597) | about a year and a half ago | (#43213577)

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, subject to user overrides) and NOTHING MORE. It returns either a file content, or nothing at all. Hell, if you like, prevent it from allocating memory. The program that asked for the file then takes the content returns and opens it (and is thus no more aware of where it came from than anything else, and can't just run off and access your files willy-nilly).

Send a token with the file (say, a file handle of 1 for the first file for that process, a file handle of 2 for the second file for that process, etc. so that they can't stamp on other file handles) when it's opened and if the process makes any changes to it and asks for them to be saved, it makes a REQUEST, sends the data it would like to be saved back, and waits for the result.

The "save" process backs up the original file, asks the user (if necessary, but at least it has a say if necessary) and puts the saved content where it needs to go (checking appropriate permissions). Every single action is hooked by a minimum -privileged process that does nothing else. At no point does the browser have any need to do anything more than request the user/system to give it a file's contents, which can be denied in a trice.

It does not *get* to fopen() all the users files in arbitrary locations. At no point do the save or open processes need to interpret file information (if they need to - e.g. to extract an icon from them, then have ANOTHER process do that for the file that does nothing more than read a file given to it by such processes and returns a bitmap). They simply aren't acting on user input at all, which really cuts down the attack surface.

Extend to all necessary system calls. Hell, make every process run in a chroot with only a method of input and an output (which could be as simple as a folder inside the chroot for "incoming" data that is read-only, and a folder for "outgoing" data that is write-only - Unix demonstrates that "everything as a file" can work very efficiently). Make that output UNIQUE to that process (i.e. the word-processor may be acting on a local copy of your document only and not the original) and can only go to other processes via intermediate measures.

Make every interaction with outside processes a minimum-data request. "I'd like you to print this" (no, the program doesn't get to choose where or even know anything about the printer, but the user may have their own policy about what programs see what printers, in what order and with what settings - no more "this program only prints to things that aren't PDF printers, etc.", or "this program has its own idea about using Tray 2", and putting control back to the user or - ultimately - the administrator), "I'd like you to let the user select a file", "I'd like you to tell me what the time is".

And FORCE programs to cope with any of the possible (limited) responses such a request can receive. Hell, make it part of the requirement that they operate fully at all times even if every request (for memory, files, sockets, whatever) is no at random.

At no point does Word need to read every file in My Documents. At no point can a macro run riot and delete all your files or overwrite them with junk, even if it's run "as you". Rogue processes are quickly spotted and no permanent damage can be done (all they see is a virtual filesystem anyway, so rollback is proper and not at the whim of processes co-operating by closing file handles etc.). And even something running as admin can't run off, change all your clocks, delete your users or whatever else.

Performance hit? Recouped by not having to have a privileged process that's the ideal attack surface scanning every file on my disk every hour or whatever it is that antivirus programs do.

Sure, such things exist in parts, but there's no complete implementation of such a thing, and few even try. Things like SELinux still work the other way around - having to cope with a process being ABLE to do anything and then finding a way to block it when it tries. Processes should be able to do nothing more than REQUEST an action and see what the result is, not run off and try anything themselves.

(Hell, I always thought the perfect method of processes making a request would be to create a file in a virtual /proc-like part of a processes private chroot which the system looks at WHEN IT CAN BE BOTHERED - things like inotify would make it a cinch and the processes cannot "break" the request mechanism if it consists of only a filename in a certain folder, appropriately rate-limited for processes with "suspicious" amounts of requests. The process does not get to "do anything special" and can be ignored all day long until the user/policy grants the permission by, say, performing the requested action and putting the result into the internal /proc filesystem of that process)

And then group policy, firewalls, anti-virus measures, system security, user privileges etc. become nothing more than an bunch of isolated processes saying Yes or No based on the system and user policy (similar to what we have now, but without having to give admin rights to a separate piece of firewall software that has its own security problems, etc.).

Do it right and even a compromise of such a process gets you nowhere - all it can do is return Yes or No for that particular action and nothing more - and you can run some heavy detection / restarting / whatever logic on the critical processes all the time.

Hell, you could even run two or three such processes in tandem, all in isolated processes, that use different methods to come to the answer ("Can this user open files in this folder?", "Can this user open this particular file?", "Has the memory of check-process X changed since the last request?", "Does network policy allow this user to talk out to this network share at all?") and - if any one disagrees - the whole request is denied and further investigation is requested.

And entering passwords. Why, in 2013, is it still possible for programs to switch my input focus at will? I get this on Windows and Linux, where I could (in theory) be typing out a password and suddenly I'm typing into a dialog that's popped up in front of the one I was typing in. There should be a single, official, dialog for entering ANY password that -when active - takes all keyboard focus, prevents all keyboard snooping, and does nothing more than provide a password (or token) to the calling process. And the damn user should have a light, buzzer and button on their keyboard. Until the light and buzzer go off and they click the "padlock" button, they know they aren't entering a password and when its on, they know they aren't typing a password into anything else. Windows Vista tried it and (deliberately, I think) broke it by just not involving the user/administrator enough in the policy of when it could pop up. How about "this process will NEVER generate a password prompt", and a default of "all other processes will ALWAYS generate a password prompt", and the let the user/policy/admin sort things out as necessary so they NEVER have to make a million decisions?

The user and administrator should be in control by a policy of what requests are fulfilled, denied, or are conditional (and there's some pretty hefty decisions to make on those conditions that power-users would tinker to suit their workflow - i.e. NOTHING gets to ask me for a password at all, ever, unless I press the "password" button). We have most of that sorted. What we don't have is a way to make programs work when they are told "No", so we have to fake our way around it and pretend to them that they have privileges that they don't with pseudo-layers.

We have to stop that and start writing programs that get the bare minimum, output the bare minimum, and can get told No to ABSOLUTELY ANYTHING they want to do. You don't get to use system calls. There are no system calls. You request what you want and I tell you - when convenient - the result. You want more RAM? malloc tells you no. (and, today, most programs then crash). You want to run at startup for this user? Not unless they've let you do that, or they answer Yes, and we can give the user the option to revoke that privilege AT ANY TIME. No more programs inserting themselves into your startup, or making you reboot, or re-inserting themselves on every reinstall or whatever other insanity currently exists.

You want to open a socket? Firewalls have to jump through hoops to detect, intercept, have their own policies, and deny that already. Just system-ise it with a set of zero-privilege processes and we're done. Why can't I just categorise programs as "games", "office", etc. at my whim and let them have certain permissions for everything from opening files (games need not open ANY files but the ones it came with, especially not my documents) to opening ports, but NEVER switching to fullscreen, or stealing my focus, or playing sound when in the background? At the moment, it's all or nothing or HUGE amounts of work to categorise programs like that.

At the moment we work on a trust system. We have to trust that the guy who wrote Angry Birds doesn't just read all my files for passwords and email them to someone. We have to trust that the utility we downloaded from Microsoft doesn't just run through our system files and put itself in startup. And so on. And most of the time, that trust is misplaced, abused and ignored by the programmers.

Force them into a privilege vacuum, and they have no choice. They can only ask, and get told no. And if they ask too much, the system keeps telling them no so the user isn't disturbed. And if they keep abusing the process, they are forcibly shutdown and the system tells the user "Sorry, but this process is really taking the piss now, so I've shut it up. You might want to blame Corporation X whose signature is on the program for writing junky software". Of course, the user can override if necessary.

Let's put some users back in control of their software "sheep" instead of letting the sheep rule the country and telling the user what hoops he should jump through to tolerate their presence.

(And then go look at something like Adobe Flash, which would be made a sensible program in about a second with such restrictions because it would ONLY be able to take a given swf file, a mouse position when the user wants it to have one - e.g. when the mouse is on the video - and return a given bitmap/video to the browser. No crap install process. No auto-updates at inconvenient times against the users will. No processes sneaking into startup to "help". No bundling of toolbars into the installs. All it needs to do is draw a damn YouTube video by being given the data for that video and given the output back. And if it crashes - so what? The process bottle just returns NULL, even if its the system that has to do that for it, and the browser carries on as per normal without that particular Flash).

I find it incredibly annoying that we have the capabilities, the policies, the technical ability and the desire to have a system that does EXACTLY WHAT IT NEEDS AND NOTHING MORE, and we don't use it, or over-complicate it to the point where an SELinux policy makes me recoil in horror.

Your process gets sod-all. If it wants it, it can make a request. The request is fulfilled by the absolute minimum of response necessary, which can be nothing more than No. Get that, and 90% of our other problems just disappear. But no, we still have systems where you can craft a file which crashes Samba when it's served, which gives a remote terminal shell into a system with full root access to all files. At no point should ANY process have that sort of privilege and access, and certain NEVER one that deals with user-input in any way, shape or form.

Re:XEN para-virtualized browsers in Qubes OS (1)

tlhIngan (30335) | about a year and a half ago | (#43213819)

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.

OS X started doing this by default on a limited basis. For all Mac App Store apps, sandboxing is required and enforced by the OS. Of course, it's lead to more than a few difficulties which result in apps having to be removed from the MAS because the sandbox restrictions were too tight (i.e., they cannot access system files, so if you're a text editor, that's a fairly significant limitation).

Likewise, general apps cannot access cloud-saved data (with good reason - it's possible for clever malware to embed itself into the cloud storage which results in that app continually reinfecting itself, and since it doesn't sandbox (not enforced for non-MAS apps), result in the machine continually getting reinfected.

Of course, if you ask the /. crowd, when Apple tries to do sandboxing and such, it's evil and results in the iOS-ization of OS X. And that access to the whole filesystem is a right and the MAS should die because it's sandboxing...

Re:XEN para-virtualized browsers in Qubes OS (1)

sjames (1099) | about a year and a half ago | (#43215007)

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:XEN para-virtualized browsers in Qubes OS (1)

Anonymous Coward | about a year and a half ago | (#43215217)

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:XEN para-virtualized browsers in Qubes OS (2, Informative)

Anonymous Coward | about a year and a half ago | (#43220267)

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 library call telling the OS to present the standard file picker UI. The OS does so, using a separate process heavily guarded against outside interference (so it can be sure that the user is the one choosing the file). Once the user has picked a file, the OS opens a hole in the sandbox permitting the app to access the file. So it all works, using the same flow users always used to pick files before. (It doesn't even look any different.)

That said, this approach isn't perfect. It works well for application types which need access to user-created documents, but not so well for apps which might want to touch a large quantity of files outside the app's sandboxed directory without requiring the user to pick each and every one. So there's a lot of cases where it doesn't work too well yet. It's clearly a work in progress. (Which is why Apple isn't denying the ability to install and run non-sandboxed apps, despite all the sky-is-falling paranoia.) But to claim that Apple is denying users the ability to raise an app's privilege? Just shows you have no fucking clue what you're talking about.

Re:XEN para-virtualized browsers in Qubes OS (1)

theurge14 (820596) | about a year and a half ago | (#43214553)

Cliff Notes version: Modern OSes should adhere to the principle of least privilege.

Re:XEN para-virtualized browsers in Qubes OS (1)

Electricity Likes Me (1098643) | about a year and a half ago | (#43214917)

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:XEN para-virtualized browsers in Qubes OS (1)

fa2k (881632) | about a year and a half ago | (#43215801)

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, in Qubes you still need some protocol for the other parts of the system to talk to the network VM, so if someone owns the network VM, they can quite possible also get at the other parts of the system (admittedly much more difficult than the instant root (or better) that can be obtained by owning a driver in standard Linux).

Qubes OS has created a nice innovation on the main X11 desktop. Applications from different security domains are clearly marked, so that it is difficult to fool the user into entering information in the wrong place. X11 is usually a bottleneck when it comes to isolation, and Qubes fixes this.

Re:XEN para-virtualized browsers in Qubes OS (1)

Burz (138833) | about a year and a half ago | (#43216299)

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 (3, Interesting)

Halotron1 (1604209) | about a year and a half ago | (#43212889)

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.

So, how badass do you have to be... (0)

Anonymous Coward | about a year and a half ago | (#43212985)

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?

Re:So, how badass do you have to be... (2)

Desler (1608317) | about a year and a half ago | (#43213149)

They find them ahead of time.

Microsoft was to blame, obviously. (0)

Anonymous Coward | about a year and a half ago | (#43213081)

They paid this 'PinkiePie' character to badmouth both Chrome OS and Linux, with Microsoft sympathizers at Google playing along.

Re:Microsoft was to blame, obviously. (1)

symbolset (646467) | about a year and a half ago | (#43214241)

Microsoft sympathizers at Google

OK, that was funny.

Two things comes to mind... (0)

Anonymous Coward | about a year and a half ago | (#43213229)

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...

Go ahead, the code's out there (1)

idunham (2852899) | about a year and a half ago | (#43217051)

Go ahead, it's at http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915?id=HEAD [kernel.org] ...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.

and meanwhile, Microsoft gives away an Xbox. (0)

Anonymous Coward | about a year and a half ago | (#43213407)

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.

OSX/Safari (2)

programmerar (915654) | about a year and a half ago | (#43213727)

So OSX/Safari was the only one standing?

Re:OSX/Safari (0)

Anonymous Coward | about a year and a half ago | (#43214167)

More like left sitting.

Re:OSX/Safari (0)

EGSonikku (519478) | about a year and a half ago | (#43215793)

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:OSX/Safari (1)

programmerar (915654) | about a year and a half ago | (#43221681)

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

cheating programmer monkies (0)

Anonymous Coward | about a year and a half ago | (#43213803)

Give me a fucking grape!!
http://www.activistpost.com/2013/03/what-happens-when-2-monkeys-are-paid.html

Analyzing the exploit (2)

daboochmeister (914039) | about a year and a half ago | (#43214287)

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.

So the attack would likely involve a web page employing hardware acceleration, that leaks an overflow into the i915 driver, resulting in ... DoS? Shell?

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 (1)

Kludge (13653) | about a year and a half ago | (#43214913)

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.

Re:Chrome IS Linux/GNU/X (0)

Anonymous Coward | about a year and a half ago | (#43216473)

ChromeOS doesn't use X. Nor does it use GNU userspace.

Wrong wrong wrong (1)

daboochmeister (914039) | about a year and a half ago | (#43217149)

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 [slashdot.org] , for example.

Obvious troll article (1, Insightful)

Pop69 (700500) | about a year and a half ago | (#43215265)

How does this garbage get past a so called editor ?

Re:Obvious troll article (0)

thetoadwarrior (1268702) | about a year and a half ago | (#43215751)

Please explain why it's garbage and causes you so much butt hurt.

Re:Obvious troll article (0)

Anonymous Coward | about a year and a half ago | (#43215981)

Look at the OP's Slashdot number. He is a beard, not a troll.

The question is wrong. (0)

Anonymous Coward | about a year and a half ago | (#43215999)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?