Hacker News new | comments | show | ask | jobs | submit login
Reducing Chrome crashes caused by third-party software (chromium.org)
103 points by discreditable 7 days ago | hide | past | web | favorite | 41 comments





Related reading:

Robert O'Callahan's (ex-Mozilla employee) blog post on anti-virus injecting code into browsers.[1]

And then read this fun Twitter thread from Justin Schuh, head of Chrome's security team, arguing with AV author Vess on the very issue.[2]

And then read the HN thread on that Twitter thread.[3]

[1] - http://robert.ocallahan.org/2017/01/disable-your-antivirus-s...

[2] - https://twitter.com/justinschuh/status/802491391121260544

[3] - https://news.ycombinator.com/item?id=13079569


The shit that Norton does to Chrome is impressive, they hijack the search engine, install two addons to your top bar, and add a few hundred ms of latency to every web page load.

Essentially crappifying the internet for their users, while charging them for the privilege.


Is there anyway to detect this via a web page to report the presence of the broken plugins to the end user? I guess I should just install it and figure it out but was hoping maybe someone had already done the heavy lifting.

[edit]. Found this https://vah13.github.io/AVDetection/


I'll tell you right now that it's a terrible idea.

As much as this sucks, if you tell the user that their antivirus is the problem (the antivirus program that they paid for and trust), you will lose a customer.

Many people who aren't comfortable with technology have been taught to NEVER disable their antivirus, and that anyone that is telling them to is trying to hack them.

That leads to the situation where they instantly and completely distrust anyone telling them to disable/replace/edit their Antivirus in any way.


Once Chrome opens the file save as or open dialog, they basically run a copy of explorer in their address space. Right clicking there on any file opens the context menu with things like "Extract to subfolder with 7zip" or "Merge as Adobe PDF". Even showing this loads DLLs in their address space and runs them.

How do they deal with that?


Most likely they will start new process for the dialog window (or they already do that).


Well, yes, that API call comes with linking to shell32.dll, which effectively hosts parts of Explorer (including shell extensions) in your process. The person you replied to probably suggested that Chrome would sandbox the common dialogs in its own new process to avoid potential issues. Just like they put, e.g. Flash into its own helper process without Flash being its own executable.

This is what Chrome already does: it uses a utility process to host the common file dialog. See https://cs.chromium.org/search/?q=CallGetOpenFileName&sq=pac...

Thanks for finding this. But does it really open a helper process? In the code I can't find anything about that.

Is it possible to launch a process and have it display a modal dialog which blocks the parent's dialog?

(I don't use Chrome at the moment and will install a new version later to check it out using Process Explorer)


So this is pretty much Chrome declaring war on any antivirus software not named "Windows Defender", yes?

> IME software will not be affected

"IME"?


> So this is pretty much Chrome declaring war on any antivirus software not named "Windows Defender", yes?

See Robert O'Callahan's (ex-Mozilla employee) blog post on it.[1]

And then read this fun Twitter thread from Justin Schuh, head of Chrome's security team, arguing with AV author Vess.[2]

And then read the HN thread on that Twitter thread.[3]

[1] - http://robert.ocallahan.org/2017/01/disable-your-antivirus-s...

[2] - https://twitter.com/justinschuh/status/802491391121260544

[3] - https://news.ycombinator.com/item?id=13079569


It's referring to software that enables typing in non-latin languages. Most OS's ship everything needed as far as localization is concerned these days, but many users prefer third party software that is optimized specifically for their language, so it makes sense for them to be concerned by this announcement.

Virus scanners should not be injecting code into a process.

They shouldn't be creating security holes either, but they do!

See https://en.wikipedia.org/wiki/Input_method, (alternative) ways to enter characters, for example for non-Latin alphabet characters or to solve accessibility issues.

Input Method Editors, for other language input.

IME typically means a software keyboard. https://en.wikipedia.org/wiki/Input_method

More like, declaring war on any software they don't like.

> Microsoft-signed code will not be affected

Why?


Nice gesture, when Microsoft has 4+ layers of adware on Windows 10 getting you to use edge:

1. When you search for "Chrome" in IE, 2/3rds of the page is taken up by a special Microsoft ad.

2. When you switch default browsers to Chrome, Microsoft pops up a modal convincing you to keep Edge as the default, with a tiny "Switch anyway" button

3. Sometimes, the bottom tray will pop up with a tooltip saying 'Microsoft Edge is XX% faster than Chrome', and convince you to use Edge

4. The Battery icon in the OS will sometimes pop up a 'Chrome is draining your battery' message, while touting an Edge message. I'm not kidding.

https://www.theverge.com/2016/8/3/12369326/microsoft-windows...


I find it extremely funny that I'm defending Microsoft's spam, especially considering their history, but I think at this point that Microsoft is just fighting fire with fire.

I get at least 1 weekly notification to use Chrome. Either directly on google.com or on translate.google.com or several of their other properties. Despite me clicking "No" on the damned thing across as many devices as I can remember since Chrome appeared back in 2008.

I highly doubt that the Google Skynet isn't able to identify that's it's me across all these devices, considering my usage patterns. Or even better! Considering that I'm actually logged in to the Google Account permanently via Gmail...


Microsoft has been presenting a top banner ad asking you to switch to Edge for some time when you visit their properties.

Cause they make the OS....

How is this going to be achieved? As far as I know, programs have no say on whether a DLL can be injected into their module list / address space by an elevated process.

We've had a blocklist in Firefox for specific DLLs that cause major issues (usually crashes) for ages: https://dxr.mozilla.org/mozilla-central/rev/574f4f58fe09dd59...

I assume Chrome is just planning to make that block everything that's not Google or Microsoft code, probably with a short whitelist of things that are necessary.



Hmm. I guess trashing your local LoadLibrary copy will stop 90% of software not specifically targeting Chrome... but that's still trivial to circumvent. I thought perhaps there is some Windows feature that could be taken advantage of, something like Internet Explorer's protected mode.

There is also "Protected Processes".

http://www.alex-ionescu.com/?p=34


The AV vendors need to ship the Chrome injection code to their customers, which includes the Chrome development team. And the Chrome announcement says explicitly that Google is willing to stop Chrome, so the AV vendors have to carry out the injection in such a way that it cannot even be detected after the fact.

A real challenge.


And DLL injection is just the userspace solution. How will they deal with kernel-based code injection ?

This probably won't affect many users, but I imagine it will make it impossible to use stuff like MacType. It's also rather curious that Windows is the only OS where this really is a problem.

Funny. Gmail is crashing on Chrome for me this very morning.

I can see the valid points of the argument being made here, and I've seen it with a lot of other companies too, but personally I hate this (protectionist? paternalist?) attitude. Your software does not exist in a void. It will interact with other software, sometimes badly. That's just the nature of an open system. Stop trying to isolate yourself from everything else, because while that stops the bad, it also stops the good.

Besides, as mentioned in the other comments here, DLL injection is basically impossible to stop completely, so this will just lead to a bit of an "arms race" with no benefits to anyone. (Injecting into processes that try to stop it is pretty easy. I've done it before. But we shouldn't have to fight our software anyway.)


It's true that AV software has root so it can always win but it's hard for AV vendors to claim they're making legitimate software if they enter into a very public arms race to crack a browser's security.

And all just so they can put an extra bullet point on their marketing. It'd be easier and less damaging just to make a standard extension.


FYI: Chrome did the same thing with the OS Security.

On Windows and on most OSs, software is installed in a location that the standard user doesn't have write access to, and you require root/admin authorization to install. Chrome bypasses the OS security by installing itself in a way so that it can auto-install software/updates without the explicit consent of the user. If all software did this, it would soon be a security nightmare.


Those 'standard extensions' are pointless though, aren't they? Capable of absolutely nothing of importance? They're just scraps of HTML and some CSS with extreme limitations on what they can access is my understanding. If Chrome has a security hole that AV vendor X knows about, would such an extension have the power to prevent Chrome from loading it and getting exploited anyway?

> If Chrome has a security hole that AV vendor X knows about, would such an extension have the power to prevent Chrome from loading it and getting exploited anyway?

Very probably yes. One of the best ways to fend off viruses is ublock, after all.


In principle an AV extension could read the scripts on a page and either analyze them there (or background web worker or something) or (if the APIs allow) pass them off to the native AV process for examination; it could theoretically be useful to go beyond simple blocklists and try to identify badly behaved or malicious scripts before they actually get executed in the users browser.

Unfortunately, AV vendors have not really demonstrated the ability to do anything like that in a reliable or secure way.


They can message between native applications (e.g. the AV software) and Chrome. They can also inject scripts into every page (something AV software loves doing for some reason).

If Chrome has a security hole that the AV vendors know about then they can fix it at source. This is a lot more robust than opening a giant hole in Chrome's sandbox in order to insert its own code inside.


There could be a DMCA anti-circumvention case here, since Chrome is proprietary (Chromium is licensed under open source terms).

I recall game makers using DMCA to sue cheat makers.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: