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.
I'd love to have a bit more context behind your issue here. Have you followed the instructions outlined by that error and tried to update your Google Chrome? Can you let me know what specifically happens when trying to use Shopify on Chrome?
Imogen Social Care @ Shopify
- Was my reply helpful? Click Like to let me know!
- Was your question answered? Mark it as an Accepted Solution
- To learn more visit the Shopify Help Center or the Shopify Blog
Hi Imogen, I tried to update Chrome, but I have the latest one apparently. I'm not sure if anything is different when I use Chrome. I just press " continue with unsupported browser", which is the Chrome version I am having the issue with. No similar messages when using other browsers. Just when I am using Chrome on an ipad. The ipad is updated to latest operating system, and I have cleared all cookies.
Thanks for letting me know you tried a cache/cookies clear. I may request that you do this again, as its a step we always ask to be completed when troubleshooting. Researching is showing me that these types of issues are often localized to the devices being used, which also ties in to it being a browser specific error. These errors almost always arise from cache/cookies data being saved.
Switching to a newer Chrome version would allow for this new pseudo-class to be used. This would make many new things possible and many already possible things much, much easier to achieve, most importantly without any JS, which would alleviate the need for having many little JS snippets running on every keystroke.
Yes, updating the Electron version is overdue. It will probably happen with the next larger public release. I guess it was not done this time because the developers were so busy with the new Canvas feature. Updating to the new Electron/Chrome version will also fix a lot of other pending bugs and quirks e.g. regarding font rendering on the Mac.
Hello, everyone... I'm back. Been a hot minute I know.
Anyways, so, I know this may seem like a bit of a newbie question for someone with as much experience as I have but here's the situation.
We recently upgraded our machines to use TestComplete version 15.49. However, the version of Google Chrome on the machines is version 111. When I launch TestComplete and try to examine web applicatioin in Google Chrome, I'm unable to see the applications as "open". It seems that the version of the Chrome Extension that is installed with TC 15.49 is not compatible with Chrome 111 (although, I could be wrong).
Is there a patch or is there some configuration that I'm missing here to get Google Chrome applications to show as "open" in TC 15.49.
UPDATE: Actually, it's a little odder than that. I have two different machines with the same version of Chrome, Windows, and TC. One machine has the problem described above...the other machine doesn't. So... it's not a matter of a Chrome patch, but something else.
Any thoughts from anyone?
The "m" just means that you have multiple versions of Chrome installed in C:\Users\username\AppData\Local\Google\Chrome\Application. You might have multiple versions of Chrome if you didn't download the latest version, but updated to it. The new version won't replace the old one, in case of installation failures. So in essence, when Chrome detects that you have more than one version of Chrome, it displays "m" after the version number in the [About Google Chrome] window.
You can just check the About Google Chrome as you already have and look for "beta" and "dev" version keywords. I'm running the latest beta channel version (on Windows 7) and my "About Google Chrome" window says "beta-m". An image of something similar to what you should see can be seen at How-To Geek
If the driver is changing because the base images are changing, I wonder if a custom image would help here? One can create a Docker image containing the versions of things that are needed, and then stick with that until one decides that a new one is necessary.
I have been using the web interface with CHROME. As of today, I can no longer get past my login. When I try to log in in goes to blank screen. I am able to sign in with Firefox & Safari (on MAC). From Evernote.com, go to "sign in" from upper right, and goes to blank page. I am able to sign-in on this Forum page, but not Evernote. I restarted Mac, cleared cookies and same thing is happening. From the attached picture in Chrome - just goes to blank screen.The links & bookmarks that I have take me to same blank screen. -lastest MAC 0S: 10.12.3and latest CHROME: Version 56.0.2924.87 (64-bit)
Exactly the same thing for me. Using latest version of Chrome browser & MacOS Sierra. Tried to uninstall and install web clipper again, but no change. It works on my other Google account, but I guess only because I'm still logged in there.
d3342ee215