Code Injection Chrome Web Browser

Google to fight code injection into Chrome web browser

Thursday, November 30, 2017 Google released their plans for blocking third-party software from injecting code into Chrome on Windows. Starting in July 2018, Chrome will begin blocking third-party software from injecting code into Chrome on Windows.

Promon pioneered this way of security thinking already a decade ago – it’s NOT ok that anyone can enter potentially malicious pieces of code into applications that execute their own code. But hold your horses! When reading the blog more carefully it’s not because Google is especially worried about their user’s security – or privacy for that matter. No, they simply dislike that code injection – the favourite interception and manipulation method used by both malware and anti-virus software – can cause the Chrome web browser to crash.

The changes will take place in three phases.

  • April 2018 — Google will begin informing users if code injection causes Chrome to crash, alerting them with the name of the responsible application and a guide to update or remove the problematic application.
  • July 2018 — Chrome will start blocking third-party software from injecting code into its processes. However, if this blocking prevents Chrome from starting, the browser will restart and allow the injection. It will then guide users to update or remove the software causing the problem.
  • January 2019 — With Chrome version 72, Google will completely block code injection by any third-party software.

While most software that injects code into Chrome will be affected by these changes, there are some exceptions. Microsoft-signed code, accessibility software, and IME software will not be affected. (IME stands for Input Method – ie keyboard). This means that a large palette of unknown software are still allowed into Crome’s runtime process, which is insane if the goal is to increase security. Ok – security was never Google’s reason for doing this, so it is likely that they get their expected stability improvements.

Security as a side effect

In this case, we can expect the security improvements as a side effect. A lightweight application protection is going have a positive effect on security but is unlikely to block advanced malware.

We fully understand why Google is reluctant to take any responsibility for the Chrome user’s security but we have to repeat that already in October 2014 the analysts in Gartner stated that “every app needs to be self-aware and self-protecting”. It is going to take 4 years before Google implements something in that direction. Let’s hope that this move is the beginning of a new way of thinking browser security.

In the meantime, the security conscious reader can read more about our security products for desktop applications and browsers.