Reducing Chrome crashes caused by third-party software (blocking code injection)

[michael....@gmail.com]

Hi everyone,
Chris Hamilton anounced at https://blog.chromium.org/2017/11/reducing-chrome-crashes-caused-by-third.html that the Chrome Stability Team plans on blocking code injection in Chrome. In that same article it says that e.g. Accessibility Software will still be able to inject code into Chrome. As it happens to be, our software product makes use of code injection in order to provide accessibility features. How can I make sure that our product still works as intended, ideally without modification? Do you have to whitelist our Products? To whom could I reach out for further information?

We would like to refrain from additionally supporting a Chrome extension for our software suite in order to use native messaging.

Until now I did not find any other useful information on this matter except the blog post.

[Chris Hamilton]

(chromium-dev to bcc)

Sorry for the slow reply here, I was on vacation and then traveling for work.

Currently, we whitelist any applications that inject and make use of the accessibility API. However, the pipeline that gathers this data relies on the application being sufficiently popular (seen enough times) in order to weed out one off developer builds and experiments, etc, and for various other reason may not be 100% accurate. If you send me a copy of the DLL that is being injected (or at the very least summary stats: typical install path, basename, linker time/date stamp, module size) then I can tell you if your product made it into the whitelist as it currently stands.

Once the messaging phase of the mitigation rolls out (M66 through M69) you'll be able to see if your injected module will be whitelisted or will be blocked by running Chrome, having your software inject, and then visiting chrome://conflicts.

Note that our long term plan is to work with other browser vendors to develop a saner more performant accessibility API that doesn't need to use native injection (or in the worse case, allows injection into a sacrificial process). Once this API is available and sufficient transition period has elapsed, we intend to eventually stop whitelisting old a11y products as well.

Regards,

Chris

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/2bcfd56d-4e47-463f-acb6-2b54c82f1de8%40chromium.org.

[michael....@gmail.com]

It seems, that my last message was scrambled. Here it is as it should have been:

Hi Chris,

Thank you for your reply. We have several dlls that we inject into chrome. For example the following dlls for 64 bit software (with their typical install paths and names):

C:/Program Files (x86)/tts/tt knowledge force/jre/bin/x64/com.tts.at.spi.x64.dll (timestamp: 2017-11-28 11:17:24; Size: 594432 Bytes)
C:/Program Files (x86)/tts/tt knowledge force/jre/bin/x64/com.tts.at.spi.ip.win32.x64.dll (timestamp: 2017-11-28 11:17:58; Size: 125440 Bytes)
C:/Program Files (x86)/tts/tt knowledge force/jre/bin/x64/com.tts.toolkit.core.x64.dll (timestamp: 2017-11-28 11:17:02; Size: 784384 Bytes)
C:/Program Files (x86)/tts/tt knowledge force/jre/bin/x64/com.tts.toolkit.win32.x64.dll (timestamp: 2017-11-28 11:17:40; Size: 968704 Bytes)

For 32 bit installations we inject amongst others these:

C:/Program Files (x86)/tts/tt knowledge force/jre/bin/com.tts.at.spi.dll (timestamp: 2017-11-28 11:11:48; Size: 539648 Bytes)
C:/Program Files (x86)/tts/tt knowledge force/jre/bin/com.tts.at.spi.ip.win32.dll (timestamp: 2017-11-28 11:12:06; Size: 114688 Bytes)
C:/Program Files (x86)/tts/tt knowledge force/jre/bin/com.tts.toolkit.core.dll (timestamp: 2017-11-28 11:11:22; Size: 672768 Bytes)
C:/Program Files (x86)/tts/tt knowledge force/jre/bin/com.tts.toolkit.win32.dll (timestamp: 2017-11-28 11:11:48; Size: 855040 Bytes)

The data to these files I gave you was from our version 13.0.0.79. Since we also make improvements and bugfixes on our products, the fingerprint of these files may vary depending on the version. How do you handle these cases? Do you look primarily at the paths? I guess that the list of allowed binaries is not openly available?

Best regards,
Michael

[Keith Lammers]

Is this injection blocking no longer a thing in Chrome? A couple of months ago the dev channel was blocking them and showing the warnings, but I've just re-tested and everything is allowed through again. The page that used to show the list of blocked dlls is also seemingly gone: chrome://settings/incompatibleApplications

[Chris Hamilton]

We've temporarily reverted due to issues with IME support (tracking bug here). Once the IME issue is resolved we'll be rolling out again slowly. Expect the blocking to start rolling out again sometime in 2019Q1.

The incompatibleApplications settings page is tied to the feature being enabled, but the logic still exists in the code to generate it. You can visit the chrome://conflicts page for full diagnostics. This page will also tell you how Chrome will treat your binary when the feature is enabled again. See also this document for help in testing.

Cheers,

Chris

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/95c2e18c-cc08-4491-8bd0-48421aeee02b%40chromium.org.

[Keith Lammers]

Thanks Chris! Is there a way to get DLLs whitelisted? Our DisplayFusion hooks are being implicitly blacklisted. We use them to provide window management features in DisplayFusion. We disabled the hooks for Chrome in the latest version (thus breaking the features for Chrome) expecting the block to make the stable version in January. We've had a lot of customers complaining about our features not working with Chrome any more since disabling the hooks. We'll re-enable them for now, but I'm wondering if there's a way we can get whitelisted to keep them working?

[Chris Hamilton]

No, there's no whitelisting available. Most window management features are able to be reproduced using external window hooks that don't require injection. We are aware that some functionality is not able to be built this way, and we are investigating moving Chrome's root window to an external UI process where injection will be allowed. If this moves forward it likely won't happen before sometime in mid 2019, however.

Regards,

Chris

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/3347bfe9-008d-4e6f-aa84-db33b14bd6c4%40chromium.org.

[Ken Sheppard]

Is this still happening? I was told by a vendor today that they had confirmation it was not being enabled.

[pmon...@chromium.org]

Yes this is still happening. The last update Chris provided is still accurate but we hope to enable it back soon.

[Ken Sheppard]

Was this implemented? And if so, is there a way to track the commit tied to this issue?