Secure Endpoint breaking Chrome after June Windows cumulative updates?

[ac513]

We deploy Secure Endpoint 8.1.7 to our few thousand devices, and we started getting a mountain of reports this morning that Google Chrome would not appear on the screen after attempting to open it. It's not 100% across the board, but it is a significant uptick in complaints that is getting attention from our unit.

With a little trial & error, I found that killing the Secure Endpoint service or uninstalling Secure Endpoint will allow Chrome to open again. However, nothing shows up as being blocked in the device trajectory in the Secure Endpoint console. Also, if we reinstall an older version 7 Secure Endpoint client, the issue not reproducible. Once we install 8.1.7 again, the issue returns and Chrome does not open.

Behind the scenes the Chrome executable is actually opening & gets listed in Task manager.. But the app window itself never appears.

I did see at least one other thread on this in Malwarebytes' forum -- https://forums.malwarebytes.com/topic/299100-june-2023-update-kb5027231-prevents-google-chrome-from-displaying

Anyone else seeing similar behavior today with Chrome not opening?

[ac513]

Our test policy where we could reproduce this had the Exploit Prevention engine set to Audit.  Once we set that to Disabled instead, the issue was no longer reproducible.

Once Exploit Prevention was set back to at least Audit, Chrome stopped working again.

So that engine seems to be at fault. Still working a TAC case at the moment.

I also noticed the following from the update's KB article. I wouldn't think any parts of Secure Endpoint are still 32-bit, so not sure if this is related or just coincidence.

This update addresses a known issue that affects 32-bit apps that are large address aware and use the CopyFile API. You might have issues when you save, copy, or attach files. If you use some commercial or enterprise security software that uses extended file attributes, this issue will likely affect you. 

---

https://support.microsoft.com/en-us/topic/june-13-2023-kb5027231-os-build-22621-1848-8f903600-1293-4431-9c6b-736a4049666c

[EdieDudley14020]

In the Malwarebytes forum, it mentioned making Chrome the default browser which worked.  Isn't ideal but it will get us by until a fix is ready and better than uninstalling the KB or disabling Secure Endpoint Exploit Prevention.  The problem only happened on Windows 11 devices.  

[ac513]

Oddly enough, that is working for us too.  Agreed that this is a far nicer workaround.

TAC gave a soft confirmation of the issue, stating that they're starting to correlate reports of this.  They also had me test a fun theory -- If you rename the Chrome executable, it will actually work. Once it's renamed back to chrome.exe, the issue reproduces again.

[EdieDudley14020]

Interesting!

[mski7861]

I also verified that setting Chrome as the default browser is a valid workaround. 

[mski7861]

One of our clients rolled out KB5027231 to a bunch of machines and is reporting the same issue with Chrome not opening.  

I agree that the recommendation to set chrome as the default browser is the simplest workaround and will test this theory.   

[ac513]

At this point the issue is pretty clear and we're all waiting on Cisco, but I did want to share the following just for historical purposes.

Bug ID for this is now customer-visible: https://bst.cisco.com/bugsearch/bug/CSCwf66658

Also just got an email alert from our console:

Cisco Secure Endpoint Announcement - Chrome Launch Failure
Some users may encounter difficulties launching Google Chrome when the Exploit Prevention engine is enabled on Secure Endpoint Windows connectors because of two Microsoft updates (KB5027231 or KB5027223) for Windows 11.

There are currently three workarounds available for affected endpoints:
1. Make Google Chrome the default web browser.
2. Roll back the two Windows updates.
3. Disable the Exploit Prevention engine. Please note that doing this will affect your security posture.

We are currently investigating the issue further and will provide updates when available. If you require further assistance, please contact our support team.

---

[Ken Stieers]

Or MS... since malwarebytes has same issue.

[Roman Valenta]

Just another observation when it comes to rolling back the KB update.

One of the affected customer reported that rolling back the Windows patch on their end has caused a large amount of systems to go into recovery mode causing things such as bitlocker to need re-synced again. So I would not recommended to roll back on large deployment until further tested to avoid any issues like this.

What basically happened is a change introduced by Windows broke the functionality of Chrome w.r.t to ExPrev, issue was reported by already mentioned Malwarebytes also WatchGuard EDR have the same issue.

Our DEV team is already on that issue and as of right now the fix should be available in the upcoming 8.1.9 release. There is currently no set date but based on the trend and connector release history  we should be expecting new connector release at the end of July.

[seal325]

Is there any ETA on the resolution for this issue?

[Ken Stieers]

Per the post just above yours in the community:

Our DEV team is already on that issue and as of right now the fix should be available in the upcoming 8.1.9 release. There is currently no set date but based on the trend and connector release history we should be expecting new connector release at the end of July.

[emmonsk]

Is a fix only going to be available for version 8 or will there also be a fix for users of version 7?

[mski7861]

From what I've seen, they only create fixes for the latest revision, they normally don't go backwards

[Ken Stieers]

I would say maybe. 7.x is still available to support older windows releases (eg Server 2012R2.) As those lose MS support, 7.x will go...