Google Engineers Deny Hack Exploited Chrome
CWmike writes "Several Google security engineers have countered claims that a French security company, Vupen, found a vulnerability in Chrome that could let attackers hijack Windows PCs running the company's browser. Instead, those engineers said the bug Vupen exploited to hack Chrome was in Adobe's Flash, which Google has bundled with the browser for over a year. Google's official position, however, has not changed since Vupen said it had sidestepped not only the browser's built-in 'sandbox' but also by evading Windows 7's integrated anti-exploit technologies. But others who work for Google were certain that at least one of the flaws Vupen exploited was in Flash's code, not Chrome's. 'As usual, security journalists don't bother to fact check,' said Tavis Ormandy, a Google security engineer, in a tweet earlier Wednesday. 'Vupen misunderstood how sandboxing worked in Chrome, and only had a Flash bug.' Chris Evans, a Google security engineer and Chrome team lead, tweeted, 'It's a legit pwn, but if it requires Flash, it's not a Chrome pwn.'"
Time to treat it as such.
its a Chrome "pwn". If you bundle it, you own it. You see Apple going the opposite direction by un-bundling Flash because it didn't want to own the security issues and battery draining properties associated with it. They recognized their brand was getting tarnished via that association and decided to make Adobe stand on their own.
If google bundles Flash with Chrome and the user's exposed to exploit, then it's pretty much google's responsibility for letting this happen in the first place. Doesn't invalidate VUPEN's claim one bit, as every chrome installation is still susceptible to direct exploitation.
You're saying Flash, running "inside" Chrome, is by definition outside of Chrome's sandbox? So it's not Chrome's fault, it's Flash's?
Wrong. Flash is running inside the browser, the browser is running inside the OS, and the OS is running on the hardware. Clean encapsulation, and any leakage from one layer to the other is per definitionem the responsibility of the leaking layer.* So Flash is leaking through Chrome to the OS. Deal with it and stop lying.
*BTW, GOOG, if you engineered it so that Flash runs "alongside" the browser, and not within the sandbox... you fail it. Your sandbox is worthless, your browser is worthless, and your word is less than worthless.
Welcome to the Panopticon. Used to be a prison, now it's your home.
I thought the main reason Google had taken to distributing flash with Chrome was so they could sandbox it better than the regular shared version of flash the other browsers use? And better keep it up to date, as well, but mainly the former.
I guess I was mistaken.
All the Malware/Virus problems windows has that can be attributed to 3rd party programs, this means now Microsoft is vindicated? My question is, does this Flash exploit work in other browsers? Or does it specifically take advantage of something wrong with Chrome? Cos if it's the latter, then whether it's a "Flash problem" or not, it still means Chrome is the vector.
The Google response reminds me of when MS was in the habit of using PR to quash security reports instead of writing code good. Someone would come up with an exploit and MS would say it was not a well configured updated system so the fixing the code that fell to the exploit was not the responsibility of MS. The security people would then run the exploit again with an fresh out of the box installation with all updates, and the machine would again be compromised. MS would then respond by saying that user could easily configure the machine to not fall to the exploit, so it was a user issue and not a MS issue. The thing is that is the out of the box configuration is not secure, then the machine is not secure. If an Android phone comes with flash out of the box, and Flash is not secure, then the machine is not secure. It does not matter how fancy and pretty and secure the rest of the code may be.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
Anything short of running in a VM (hardware supported or purely in software), is not a "sandbox" in my book.
It is a Chrome flaw introduced by Google's use of the word "sandboxed" that really doesn't imply a sandbox at all.
Additionally, compiling JS to machine code and having Chrome execute that data is not "sandboxing" either.
A flaw in my VM's interpretor that allows code to escape the sandbox is one thing, running non-virtualized machine code that itself can be exploited is quite another.
At some point, you must stop, wipe your brow, and consider your trek through the desert -- Is there really an edge to this sandbox? Did I miss the line drawn in the wind-swept sand or have I been lied to yet again?
Really? I just did about:plugins and clicked disable on Flash.
Or use flashblock.
Or start Chrome with -disable-plugins
Does anyone else find "pwn" to be fucking annoying?
Render them as WebM or MP4 and deal with the size increase.
How would one deal with the bandwidth bill that the size increase causes? And especially for users on dial-up, satellite, or low-end DSL, the order of magnitude size increase means there's an order of magnitude chance that the user will click away from your site in favor of another site that uses Flash.
Let people download them if necessary, rather than streaming them.
Owners of copyright in the underlying work, such as background music in a video, charge substantially more for downloads than for streams.
Use SVG or Canvas and tell the users to upgrade to another browser that supports these.
As I understand it, one has to be an administrator, as opposed to a limited user, in order to install Chrome or Firefox. And instead of installing Chrome Frame, which supports these, users with Flash Player installed are more likely to click away from your site in favor of another site that uses Flash.
Skype
As I understand it, one has to be an administrator, as opposed to a limited user, in order to install Skype software.
Or make a special browser plug-in for this, as Google does with Gmail video chat.
Can the Google plug-in be used by other than applications hosted by entities other than Google? Or will each entity have to write its own plug-in for all six major platforms (Windows ActiveX, Windows NPAPI, Mac OS X, Linux, iOS, and Android) and get it signed with an Authenticode certificate and an iPhone Developer Program certificate?
If the bug is in SQLite's code it isn't really your bug now, is it?
When a bug is in a library you link with, you should warn your users of it and file a bug report if it's a bug that hasn't been fixed yet. If a new version has been released that fixes said bug, you update your program to use the new version. A developer can't be expected to be responsible for each and every bug in every library he uses in his program, but he should be held responsible for warning his users and updating his program to the newest versions of the libraries.
Google, while being a tad bit arrogant about it, is not the owner of the exploit if the exploit comes from the flash plugin. Their responsibility right now is to file bug reports with Adobe, warn their users about said exploit, and keep improving their sandbox to strengthen their defences... Not that I think Adobe would ever be able to fix the piece of junk they call Flash, but blame should be put where it is deserved.
Safari will play any audio/video codec that is supported by any of its plug-ins. HTML5 Ogg videos play just fine with the QuickTime Ogg Component.
Fandroids hate facts.
You see, that's exactly the kind of things people should never have to hear about a product. If I get a product, whether at $0 or $10,000, it should always be responsible for its own integrated tools.
Let say I buy an integrated specialized medical database using Oracle as backend. First, I shouldn't really have to care it uses Oracle. Is the product working or not? Yes or no. The reason why a specific request would fail "because its an Oracle bug" is moot, the vendor decided to use Oracle, it should vouch by it.
Let say again I buy M$ Outlook. It uses M$ Jet as its backend. Should I really care? Absolutely not! Actually, you learn about that part when you (used to) go over 2GB and the system would balk with a corrupted archive. To have the vendor tell me it's a Jet bug shouldn't be taken seriously, they chose to use it, they live with the limitations, and it now becomes an Outlook bug.
Same for Chrome. I decide to install Chrome on my computer. It uses WebKit. It comes bundled with multiple DLLs and tools, D3DX, Gears, AVFormat and so on. Some are even signed by Google themselves, some files even contain Flash provisions inside them. They should vouch for what they have, and actually consider their bundled tools as part of their software, no matter what.
(extrapolation) I wonder how it would go with my mom, trying to make her understand that she uses a software she installed, but the fact her computer became infected with malware is because of some extraneous tool she unwittingly installed at the same time she installed Chrome, is part of the default package, and is bugged down. :) She'll remove Chrome and never go back to it because it's ITS fault. :)