Hi @gabe_verrault
We have detected the same problem. after the last scan 3 days ago, the number of vulnerabilities found has exploded. On many Windows 10 clients (LTSB and SAC) Google Chrome version 68.73.16498 was detected and accordingly 700+ vulnerabilities were reported per client. Interestingly, on both SCCM and Nexthink this result was confirmed. Meaning that version 68.73.16498 is installed on the clients. MDATP however says that version: 89.0.4389.114 or newer is installed. Also the direct check on the client showed that a new version is installed and not 68.73.16498. I will definitely create a support case today. We apparently have over a million Chrome vulnerabilities.
Regards
David
Are you guys using PatchMyPC to deploy Google Chrome? That is what we are using and from what I understand PacthMyPC used to modify the version number in the Chrome Enterprise Edition msi file. When I open the Chrome Enterprise Edition msi file for Chrome 91.0.4472.77 the version number reported in the MSI is 68.94.77.
Hello everyone
Support has confirmed to me that this Wednesday a fix will be implemented which will fix the problem with GoogleChrome Vulns. Wanted to note this here briefly.
Best regards
David
The issue I stated earlier last week in regards to a known defect for which we will ship a release this week, on Wednesday June, 16th which will resolve the issue where we are inadvertently fingerprinting Google Chrome plugins as installations of Google Chrome thus causing False Positives in your environments.
Previously, the scan-engine and agent-based assessments only relied on the version of Chrome that was seen in the Windows Registry to make determinations about vulnerabilities. This was unreliable, as updates to (or removals of) Chrome could potentially not be reflected in the Registry and many customers reported back False Positives as a result and so we worked to change this fingerprinting methodology.
On June 2, we released a change such that instead of relying on versions in the Registry, the product now looks at the file path referenced in the Registry, and confirms the Chrome executable exists there, and uses that version instead when comparing to known affected versions of vulnerabilities. If the file does not exist we included the fall back method to still fingerprint from registry.
When it comes to Enterprise chrome installs we have to rely on the registry as an authority as the registry key itself provides no information on where the executable is located; we would have to search the entire file system to attempt to find the executable to confirm the version (why is there no yikes emoji here? ) In other words, the most notable difference for us is the complete absence of an install location field, this means that we are not able to confirm the presence of the executable on disk as the registry key contains no information to point us towards its location. In a case like this we have to refer to the registry as an authority as if we do not we simply would have to assert that there is nothing present, entirely removing all fingerprinting for Enterprise Chrome.
Hello everyone
short update from my side. Last Tuesday we scanned our entire network for vulnerabilities. The total number of Google Chrome vulnerabilities has decreased from 1.3 million to 370000. Which is a good sign that the fix has brought an improvement. Interestingly, there are still some Windows 10 clients that have an unusually high number of Google Chrome vulnerabilities. Here are a few screenshots from Rapid 7 and Microsoft 365 Defender.
In this example you can see that 3 clients have only 36 Google Chrome vulnerabilities and one client has 728 Google Chrome vulnerabilities. In this case, the outdated Chrome version 68.83.32980 is being displayed.
However, Microsoft defender shows that this client also has version 90.0.4430.212 installed.
Hey all - hope everyone is doing well! I just wanted to let you know that for the workaround our team is developing for Enterprise Chrome we are currently estimated to have a fix out for the end of the month. This could absolutely shift (I hope earlier!! ) as they go through testing but I will try my best to keep this thread updated for you all if it slips further for any reason. Have a great night!
Hi @andy_taylor
Thanks for the compliment. Since Rapid7 Nexpose does not offer any possibilities to create dashboards and the available reports are rather generic and cannot be optimally customized, I created a vulnerability dashboard using PowerBI.
The whole development took me quite a lot of time last year, but now all the effort has paid off. We in the SOC inform the system and application owners about the latest scan results, which they can then view in detail on the dashboard. For various reasons, we do not want to use insightVM at the moment.
If you push the MSI from SCCM and are on a recent SCCM release you should have the option to perform checks for specific exe before deployment starts, you can then tell SCCM to auto close these programs during a required app install.
Also, you can always add the new version of Chrome enterprise into your software package and mark it as an update then have that pushed out as well. Keep in mind though - both of these methods require a reboot.
Does it leave old version of chrome as well as some guys have faced this issue with chrome updates? any suggestion. If that may be possible I can go with SCCM deploy MSI that will uninstall and install latest version instead ADMX
Rebooting user devices during their off time should be the best option in this case. Deploy Chrome updates and schedule reboots for those system automatically or manually as per demand. You can use our endpoint management tool, Desktop Central to do all these procedures.
Chrome updates automatically, but it waits until the browser is closed and opened again. Tell all the computers to reboot overnight and the update will be applied next time the user starts Chrome. You can do this with a script or using an MSP.
Google only provides an online setup file for Google Chrome which installs the latest version of Google Chrome. It happens frequently that a user upgrades to a new version of Google Chrome and gets upset by an unpleasant feature, a missing option or an annoying bug. Therefore, some users want to roll back to an older version of Google Chrome to preserve a useful feature, option or support some legacy technology. However, is it really wise to use an out-dated verison of Google Chrome? The answer is NO since out-dated browsers usually come with security issues. A better solution to the problem is to use Slimjet browser, which runs on the latest Blink engine while offering more flexibity, features and options compared with Google Chrome. With Slimjet, we give users more choices to tune their browser to their own personal preference instead of forcing a majority style on everyone. Slimjet also integrates more features internally in the most efficient way so that you don't have to spend time dealing with unstable and resource-consuming third-party plugins. Best of all, Slimjet syncs all your Chrome data and settings via your Google account and is compatible with your favorite Chrome extensions. There is absolutely no learning curve for you to switch from Chrome to Slimjet. Give Slimjet a try now and you will never look back!
For users who insist on using an old version of Google Chrome and becoming vulnerable to security issues, you can find the right version of Google Chrome to download for your platform in the following sections.
Unfortunately, we only started to archive old versions of Chrome since Chrome 48. Chrome dropped support for Java, silverlight and other NPAPI plugins in Chrome 45. If you are looking for an old version of Chrome with support of Java, silverlight or other NPAPI plugins, you would have to use Slimjet Web Browser, which is based on Chromium and retains support of Java, silverlight and other NPAPI plugins.
The old versions of Chrome before V58 are packed as 7zip self-extracting executable. Just run the executable and extract the files under any folder on your hard drive. Then launch Google chrome with chrome.exe under the extraction folder. After V59, the archived chrome old version files are official Chrome offline installers. Just uninstall any current version of Chrome first and then run the downloaded installer. It's a one-click installer without any interactive UI.
Please notice that Chrome dropped support of XP and Vista since Chrome 50. If you are using XP and Vista, please download Chrome 49 or earlier, or download Slimjet Web Browser, which is based on Chromium and continues to support XP and Vista.
Note: Google Chrome stopped release 32-bit builds for linux since Chrome 49. If you are still using 32-bit linux and would like to be protected with the latest security patches as well, you can use Slimjet Web Browser, which is based the Chromium open source project and continues to support 32-bit linux.
Sometimes it can be just because you don't like a new update or the new version of your preferred browser. Different people have different reasons, for example, developers don't like the placement of tools and in other cases the favorite extensions might not appear so useful. In such circumstances, all you need is the same previous version. In case of Chrome, though Google doesn't provide you with any Source) to download older versions of Google Chrome, but if you are really comfortable with those you don't need to disappoint. Slimjet offers you all older version under one roof.
Google do not support any rollback to the previous versions of Chrome. But that doesn't mean, you cannot get the one. Yes, there is a simple way out to get previous version. Just uninstall your present adaptation, erasing each user's saved profile information, and then re-install the needed version. Here it is important to note that user may lose their bookmarks, history, and so on. Hence, be careful while you proceed with the same.
d3342ee215