New: Check If Google Chrome Is up to Date
Over the weekend, Google issued numerous warnings to Chrome users, telling them to update their browser version immediately to protect against CVE-2022-1096, a severe vulnerability with active exploits already in the wild.
In response, Kolide has developed and deployed a new comprehensive device Check that customers can enable to prompt users to update Google Chrome when a new version is available. This Check works across Linux, Mac, and Windows platforms.
It’s important to note that this Check doesn’t just look for this specific vulnerability. It is a full-service Check built to ensure end-users keep their Chrome browser up-to-date within three days of a recent update. Let’s take a look at how the Check works under the hood.
How This Check Works
Kolide’s Google Chrome Check starts by regularly pulling in the advertised latest versions of the Chrome browser into a series of facts we store in our cloud and then ship to devices for on-device comparisons. This allows us to build Checks based on dynamic data (in this case, the latest stable, beta, and canary versions of Chrome).
Like most web browsers and other evergreen apps, Google Chrome takes charge of its update process. A typical update cycle looks like this:
A user opens Chrome which regularly checks for new updates to install.
Google’s update server advertises an update, and Chrome downloads it.
The update is verified and installed, which replaces all of the files on disk.
The version of Chrome running in memory is still the old version, so Google badges the UI prompting the user to restart the browser to complete the update.
If the user never restarts Chrome, the badging will become more and more prominent (turning from green to amber to crimson red).
This process generally works very well but presents real challenges when enumerating the risks associated with a high-profile vulnerability. These create opportunities for both false positives and false negatives when detecting out-of-date versions of Chrome.
How This Check Avoids False Negatives
Simply checking the version of Chrome on disk is not enough. With the increased reliability of modern devices and operating systems, it’s not uncommon for people to leave Google Chrome for weeks or even longer. This is a real problem because security and IT practitioners may have the false impression a risk has been mitigated when the app is still vulnerable.
To solve this problem, our Check can differentiate between a version of Chrome updated on disk and a vulnerable version that may still be running in memory.
How This Check Avoids False Positives
On the other side of the coin, making a big fuss about an old version of Chrome that is never used in practice is a waste of resources. There are three common scenarios we see that, if not thought through, can produce false positives:
A user installed Chrome and doesn’t use it, yet it remains installed and out of date.
A technical/creative employee has Chrome to test their work for compatibility, but it’s not their primary browser and is not launched regularly.
A user uses Chrome, but they have some abandoned copy in their
~/Downloadsfolder or their~/Desktopthat isn’t ever launched.
Creating a check that produces issues for these cases muddies the waters and creates a false impression of risk where the actual risk is essentially nil.
Our check avoids these cases by only generating an issue if we see an out-of-date Chrome running on the device.
Why We Make These Tradeoffs
Our goal at Kolide is to encourage our customers to ask end-users to help solve meaningful security problems on their devices. We need to be sure the data we bring them is accurate and represents an actual risk. Getting an urgent message from Kolide about an inert version of Google Chrome, or the same instant the update is available, doesn’t help anyone. Or worse still, us withholding a message because we think just checking the app on disk is “good enough.”
We hope you find this Check helpful, and we look forward to your feedback as you use it throughout your organization.
