MacInTouch Amazon link...

Google (and Chrome) security issues

Channels
Security
It can be difficult to find other details, and Apple hides parts of its privacy policy until you enable certain features:
https://www.apple.com/legal/sla/docs/macOS1013.pdf ...
Great job finding that information, and highlighting important parts.

This week ZDNet tech journalist Matt Miller wrote how a SIM "hack" of his T-Mobile account lost his GMail account. And because he'd stored passwords, financial documents, and tax returns in Google Drive in plain text, pretty much everything else.

He was very lucky his bank's fraud unit intercepted a $25,000 purchase of Bitcoin that would have been charged to his associated credit card through overdraft protection.

If you want to learn specifics about Matt's story, I'd recommend starting on the Chromebook blog post published by his podcasting partner, Kevin Tofel. Kevin's coverage seems clearer than Matt's own; it includes a link to their podcast discussion:

Takeaways:
  1. Disable SMS, known to be vulnerable, from two-factor authentication.
  2. Perhaps go further, and disable use of voice calls to your cell phone.
  3. Pre-encrypt any password files uploaded to any cloud service. Same for any confidential documents.
  4. Disable overdraft protection on your bank accounts. Check back from time to time to be sure it stays disabled. Better an overdraft charge than a large theft from your account you have to pay back.
Matt's disaster sent me to look at my personal and G Suite accounts. I found that while my cell phone was low on the list of two factor options, it was on the list. Visiting the page to initiate a lost password reset request to Google, there was that option to get the code through a voice or SMS to my cell. I removed the option.

I'm still puzzling over risks from how my varied accounts inter-connect. My Google accounts refer to my iCloud email, and iCloud back to Google.

Not long ago, I set up some new iPads. When Apple asked for a confirmation phone to send, I used Google Voice, which worked. Since I'm not deeply embedded in iOS and Apple's authentication systems, I don't know if that's a particular risk after initial setup, if the related Google account is hacked?

Working through steps to "harden" my Google accounts, I visited privacy settings. They're quite different in G Suite and my personal GMail account, with free GMail being far more wide open.

I've tried to corral my exposure to tracking and data exfiltration by using Firefox for browsing and search through the EU version of Startpage. I use Chrome for G Suite email and services, Chromium for my personal "free" GMail and services.

Yet the following setting (which reminds of Ric's post about Apple settings) was On by default in my personal GMail. I don't know if it just happened before without Google telling us, or if the notice was always there, and though I'd set privacy terms up in the past, just hadn't noticed it, or if it's new:
Google Support Accounts said:
Manage Device Information setting
The Device Information setting saves a copy of some information from your phone or tablet, including:
Contacts​
Calendars​
Apps​
Music​
Information about the device, like battery level​
No idea how far out of Chromium's (or Chrome's) "sandbox" that enables Google to roam. Does the reference to "phone or tablet" exclude computers? Seems that's a lot of "stuff" many computer users think is local-only that Google is authorizing itself to harvest.
 


Brian Krebs has good coverage about SIM swapping on his website, including:

and

The comments section for the second story has a discussion about how to set up Google Voice to replace SIM-based SMS 2FA. I've done it successfully on several accounts where there is no alternative to SMS. As well, I still have a POTS line (which, of course, an attacker would find difficult to gain control of ,as with Google Voice) that can serve as either a primary or backup second factor in place of SMS.

I have been using this setup for almost a year now without any problems. The initial switchover takes some time, but now "it just works".
 


Ric Ford

MacInTouch
This looks pretty bad, but the cause is unclear at the moment:
BleepingComputer said:
Avid Users Are Suddenly Finding That Their Macs Won’t Boot
Avid video editors have started reported that when they shutdown their Macs, they will no longer boot up afterwards. It is not known exactly what is causing this issue, but it appears to be affecting older versions of Mac OS X who have the Avid Media Creator software installed.

... While there has not been any word from Apple or Avid about this issue, a post from the Avid Editors Facebook page states that Macs running OS X 10.13.x and earlier that have Avid Media Creator installed will suddenly find that their account has been changed to a Standard user and may receive an error regarding their iLock license, which will cause their Mac to no longer be able to boot.
 




Also, there is an app called Google Update Uninstaller (which appears to date from 2011!) available from
which I installed on my system years ago to resolve a long-forgotten issue.

Multiple caveats: the app is discontinued and no longer supported, and although it appears to run on my Mojave 10.14.6 system, I have no idea whether one would need to disable SIP to allow it to do its thing. Caveat emptor, and so on.
 


A post late yesterday from Google support claims "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."

It includes instructions on how to recover. It is not clear from the posts on the MrMacintosh site if the problem is limited to that group.
 


Here's extensive information about the nasty, invisible Google updater bug that disables Macs:
People with Hackintoshes and people who have installed the DosDude1 patches to run unsupported versions of macOS on older hardware should check their systems for the Google updater issue now, as disabling SIP is necessary for their systems to run.

Unfortunately, this probably isn't the last time we'll see this class of bug, as developers likely are now only testing their software on SIP-enabled machines.
 


FWIW, I also wrote an Applescript back in 2009 that removes the Google SoftwareUpdater and creates 3 locked folders in the places it tries to put files, so it can't reinstall itself, just because I didn't like Google messing with my software installs and not telling me about it.
 


Unfortunately, this probably isn't the last time we'll see this class of bug, as developers likely are now only testing their software on SIP-enabled machines.
I want to know what Google was smoking that would cause an application updater, even by accident, to unlink /var. That's like deleting the kernel. Things like that don't happen "by accident", and I would like to know what they thought they were trying to do.

As for testing, it also proves that Google doesn't check error logs as a part of their alleged test process. Looking at the screenshot on the MrMacintosh site, we can see that SIP logged a sandbox violation at the attempt. Clearly, Google either didn't look at the system log or they ignored the error.
 


Ric Ford

MacInTouch
Here's an illustrated remediation procedure for people hit by Google's silent Mac-killer Chrome updater:
DerFlounder said:
Google Keystone update breaks Macs’ ability to boot if System Integrity Protection is disabled
On Macs where SIP was disabled, this protection did not apply and the Keystone update was able to remove the /var symlink. This symlink is not a directory itself, but points to another directory (/private/var) which contains software necessary for the operating system to boot and function correctly, so removing the /var symlink rendered the affected Macs unbootable.

As mentioned previously, Google has pulled the problematic Keystone update and has published instructions on how to remediate affected Macs. For more details, please see below the jump.
 



I want to know what Google was smoking that would cause an application updater, even by accident, to unlink /var. That's like deleting the kernel. Things like that don't happen "by accident", and I would like to know what they thought they were trying to do.
As for testing, it also proves that Google doesn't check error logs as a part of their alleged test process. Looking at the screenshot on the MrMacintosh site, we can see that SIP logged a sandbox violation at the attempt. Clearly, Google either didn't look at the system log or they ignored the error.
Back in the day, an Apple iTunes updater script deleted all files on some drives due to missing quote marks:
Wired said:
Glitch in iTunes Deletes Drives
Some Macintosh users who rushed to download the latest version of iTunes – Apple's popular digital-music player –were singing a song of woe on Friday. A bug in the installation procedure caused the application to completely delete their computers' hard drives.
 


Well, I suppose this Google Update issue shows that SIP actually lives up to its name: it managed to protect the integrity of systems. It did what it was designed to do. This time it was (probably) just a moronic oversight from a legitimate developer, but it would have thwarted a malicious attempt to remove /var just as well. I feel safer for not having it disabled permanently.
 


Here's an illustrated remediation procedure for people hit by Google's silent Mac-killer Chrome updater:
I decided, given that I hardly ever use Chrome and its need to call home on a daily basis, to remove it. I used AppDelete this time. However, I discovered that AppDelete did not find and remove the Google directory and plist file in my User/Library folder, which I had to remove manually. Thought that was the entire point of using AppDelete in the first place, but whatever. It's gone.
 


Ric Ford

MacInTouch
This looks pretty bad, but the cause is unclear at the moment:
Here's a follow-up, with some quotes from Avid:
BleepingComputer said:
Buggy Google Chrome Update Behind Recent Unbootable Macs
A wave of reported Macs being no longer able to boot was caused by a recent Google Chrome update that was corrupting a necessary operating system folder. Once the update was installed, affected users found they were no longer able to boot into macOS.

Yesterday we reported that some users of the Avid Media Composer video editing program were not able to boot their Macs after shutting down or restarting. While some users were concerned it was a virus, the thought was that a system folder was being corrupted.

It turns out that this issue is not being caused by a virus or an Avid update, but rather by a faulty Google Chrome for Mac update that is causing the /var symlink to be removed.

According to a Google Chrome open bug post, this is being caused by a bug in a new version of Google's software updater, codenamed Google Keystone.
 


Thought that was the entire point of using AppDelete in the first place, but whatever. It's gone.
AppDelete (and most all other such utilities) isn’t that smart. It just knows the names of the app and developer, and looks for any files containing either or both names. You can do the same thing with a good find utility. But lots of apps have a habit of installing files that don’t refer to the app or developer, for a variety off reasons. That’s why it’s always preferrable to check with the developer for instructions. Not sure why it missed the .plist, but here are some other places to look for Chrome related data that were probably missed:
/Library/Application Support/Google/​
/Library/Google/​
~/Library/Application Support/Google/​
~/Library/Google/​
 


AppDelete (and most all other such utilities) isn’t that smart. It just knows the names of the app and developer, and looks for any files containing either or both names. You can do the same thing with a good find utility. But lots of apps have a habit of installing files that don’t refer to the app or developer, for a variety off reasons. That’s why it’s always preferrable to check with the developer for instructions. Not sure why it missed the .plist, but here are some other places to look for Chrome related data that were probably missed:
/Library/Application Support/Google/​
/Library/Google/​
~/Library/Application Support/Google/​
~/Library/Google/​
By the way, EasyFind couldn't locate the ~/Library/Google/ folder and contents either. If I hadn't read about them, I wouldn't have known either.
 


By the way, EasyFind couldn't locate the ~/Library/Google/ folder and contents either. If I hadn't read about them, I wouldn't have known either.
Robert, How in the world would the very reliable EasyFind app not find a folder named "Google" in your home/Library folder? I suggest you take a second look at the EasyFind settings prior to initiating a search with this app. (If we cannot rely on EasyFind to absolutely locate what we ask, what can we possibly trust?)
 


Robert, How in the world would the very reliable EasyFind app not find a folder named "Google" in your home/Library folder? I suggest you take a second look at the EasyFind settings prior to initiating a search with this app. (If we cannot rely on EasyFind to absolutely locate what we ask, what can we possibly trust?)
Dunno. I checked the box to find hidden folders/files, too. Tried different Word or Phrase settings, as well. I was a bit perplexed by its failure myself. However, a simple command line search in Terminal found it quite easily.
 


Robert, How in the world would the very reliable EasyFind app not find a folder named "Google" in your home/Library folder? I suggest you take a second look at the EasyFind settings prior to initiating a search with this app. (If we cannot rely on EasyFind to absolutely locate what we ask, what can we possibly trust?)
I just ran EasyFind 4.9.1 and it found a "Google" folder in my ~/Library/ folder. My search included "Invisible Files & Folders", so you may need to be sure you are checking for those.
 


I just ran EasyFind 4.9.1 and it found a "Google" folder in my ~/Library/ folder. My search included "Invisible Files & Folders", so you may need to be sure you are checking for those.
Just tried again and realized I had selected some subdirectory in my user folder to search rather than the Macintosh HD or Users/ directories. After that, it located the items (in the Trash). I see, however, that there's also an empty cache folder in Library/ as well. So, my error.
 



Dunno. I checked the box to find hidden folders/files, too. Tried different Word or Phrase settings, as well. I was a bit perplexed by its failure myself. However, a simple command line search in Terminal found it quite easily.
When using EasyFind, make sure the location you are searching is your complete disk, not limited to a specific folder. EasyFind will default to the last folder (or other designated area) for searching when you open it, and it is easy to forget to update the search area (mea culpa).

When I searched using EasyFind v4.9.3 (El Capitan), it found five instances of a "Google" folder, two under the general /Library, two under the user ~/Library, and one in the caches folder under the user.
 


When using EasyFind, make sure the location you are searching is your complete disk, not limited to a specific folder. EasyFind will default to the last folder (or other designated area) for searching when you open it, and it is easy to forget to update the search area (mea culpa). When I searched using EasyFind v4.9.3 (El Capitan), it found five instances of a "Google" folder, two under the general /Library, two under the user ~/Library, and one in the caches folder under the user.
Yup, that's exactly what happened. I forgot to change the default location. I also had the settings set to look for only specific file types. After changing those setting, it worked as anticipated. User error in this case.
 


Ric Ford

MacInTouch
Here's a pretty good write-up on the Google Chrome disaster:
Sophos said:
Chrome cripples movie studio Mac Pros
... When Mac users install Chrome, they’re not just getting the browser. Google also installs another module under the hood called Keystone. It’s an update manager that regularly checks to see if there are new versions of Google programs and updates them behind the scenes. Doesn’t that make you feel safe? Well, it does, until it goes wrong. The latest version of Keystone was broken.

... Macs are supposed to prevent programs from tinkering with the system by default, using a projective measure called System Integrity Protection (SIP). Also known as rootless, it’s a feature introduced in the El Capitan version of macOS that protects system-owned files from alteration. It even protects them from sudo, which is the Linux command that people use when they’re doing dangerous stuff on the system and need to escalate their privileges.

SIP is switched on by default, but programs wanting deep access to graphics cards, like, say, a movie editing program, often need it turned off. That’s why Avid users were so vulnerable to the issue, but it also affects pre-El Capitan versions of macOS that didn’t have SIP installed.
 


Ric Ford

MacInTouch
A stealth program, sneaking in under the covers of a major app and constantly running with all-powerful "root" priviliges... what could possibly go wrong?
Eclectic Light Co. said:
Hollywood’s lessons
... Google’s rogue Keystone update erroneously attempted to remove the /var symbolic link on the startup volume. As that’s normally protected by SIP, if your Mac was running with SIP enabled, it couldn’t do that, and no harm was done. However, many of the affected Macs were running with SIP disabled, apparently to enable support for third-party video cards. As the Keystone updater also cast aside the last protection on that symbolic link by running as root, it was able to delete that vital link. Without the /var symbolic link, the affected Mac is unable to boot normally.

... This is also a good illustration of how automatic updating can be dangerous. In a studio full of Macs, it’s a wise plan to update one test system first, and verify that isn’t adversely affected as a result. Had that been observed here, the bug should have become manifest on that test system alone, and others not updated until the bug was fixed.

That Google should have released an auto-update, which it knew would be rapidly deployed across millions of Macs, that contained a script or tool which attempted to delete a key symbolic link within macOS, should also be cause for grave concern. To perform this, the script or tool would have to be running as root, and this bug is prime evidence that Google’s update quality assurance was woefully inadequate.

Several wise people have laid part of the blame on SIP, which is a bit like blaming a sprinkler system for causing a fire.
 


And Google's entire business plan depends on sucking every bit of personal information about you and your e-mail correspondents, and selling it. Thanks, but no thanks. I have foresworn Google and all its minions.
I think you're confusing them with Facebook. Google has specific privacy policies in place that contradict your claim.

Of course, if you leave yourself logged into your Google account and then use Google services (like YouTube or Google Search, for example), Google does keep track of things you've searched for, video searches, the history of what you've watched (all of which you may delete if you wish or even turn off the tracking) but those details are yours and are not shared with advertisers (which I assume is what you are referring to).

Those details are only provided to third parties if there's a legal requirement to do so (as in some sort of criminal matter - a request by law enforcement) or a query by a G Suite admin whose domain you are a part of, but in this latter case, it's your company's privacy policy that trumps your personal privacy; take that up with your company's IT/HR personnel.

Do note that there are exceptions to this, but they involve things like "endorsements", which, of course, involve you promoting yourself as an authority; in this case, yes, you are spreading your own info across the web.

Have there been leaks or errors in the execution of their policies? Sure; but Apple manages to fubar things, as well.
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts