Google Chrome Keystone Update Is Causing Boot Issues on Macs With System Integrity Protection Switched Off ⇥ mrmacintosh.com

I know yesterday was particularly newsy, but there’s one story I was watching for updates on because it was so bizarre.

Film and TV editors across Los Angeles were sweating Monday evening as their workstations were refusing to reboot, resulting in speculations about a possible computer virus attack. Social media reports suggested that the issue was widespread among users of Mac Pro computers running older versions of Apple’s operating system as well as Avid’s Media Composer software.

Weird, right? Today, though, a possible answer. It appears as though this issue was not isolated to just Mac Pros, or just computers belonging to video editors — any Mac that had Google Chrome installed, Chrome’s auto-updates enabled, and System Integrity Protection switched off could see the same problems.

Craig Tumblison of Google:

We recently discovered that a Chrome update may have shipped with a bug that damages the file system on macOS machines with System Integrity Protection (SIP) disabled, including machines that do not support SIP. We’ve paused the release while we finalize a new update that addresses the problem.

If you have not taken steps to disable System Integrity Protection and your computer is on OS X 10.9 or later, this issue cannot affect you.

This post also contains recovery instructions. It’s odd that this problem seemed to most greatly affect media professionals, but a search of the web turns up instructions to disable SIP as a workaround for misbehaving media apps. “Mr. Macintosh” wrote a deeper, more technical explanation of what’s going on.

Update: A reader email prompted me to think about this a little more.

Most software needs admin privileges to be updated if it’s writing to /Applications/. Google developed a workaround for this by placing Chrome’s updater in /Library/ instead of ~/Library/, which allows Chrome to update itself regardless of which user is currently logged in. I don’t find anything particularly nefarious about that — if it’s a family computer or a shared computer in a college library, for example, it may be preferable for Chrome to be able to update at any time.

However, it does create an elevated level of risk. Disabling SIP or modifying permissions can compound that risk. I don’t understand why the updater would ever need to touch /var/, but I do think that shipping software updates that will be installed automatically carries with it an extraordinary level of trust that can be shattered in an instant with careless bugs like this one.