No, it wasn’t a virus; it was Chrome that stopped Macs from booting
arstechnica.com
arstechnica.com
I'll leave this here to capture other submissions of this source.
Cheers.
EDIT: Also, interesting to read the discussions there.
> SIP, as system integrity protection is usually abbreviated, was introduced in 2015
Honestly Fedora (and arch, ubuntu, debian and so on) simply spoils me, everything I need to do my job is a `dnf install` away and it just works.
I'm reminded of that every time I have to interact with a windows desktop how poorly the other (majority) side have it.
There is something to be said about letting application developers control the update rhythm of their application's releases.
(To clarify, I’m just pointing out a humorous observation, not making a statement on Sparkle)
The button I want is “update in the background when you close the app”, and it shouldn’t ask; it should just quietly do that. For all that chrome’s updater is like a tropical disease, it sure has way better UX than sparkle.
http://neugierig.org/software/chromium/notes/2011/08/zygote....
Depends whose requirements. The user's requirements are incredibly straightforward:
1. Never update; there's no benefit.
Updating is pushed on users anyway on the theory that they're connected to the internet, but it's not meant to help them. It's meant to help other people. Updates that help the user are generally provided on a pull model, and often charged for.
2. Never be vulnerable to known attacks.
It's bizarre. Few vendors do this.
> It's bizarre. Few vendors do this.
Please correct me if I am wrong but Adobe Reader has something like this on Windows, right? And so does iTunes?
In contrast, it appears that Google installs whatever updates it wants on your system and does turn the related services back on again if you turn them off. It really shouldn't be possible for software to leave that sort of access open without the user's/administrator's explicit consent, but unfortunately the worst offender on this issue is now Microsoft with Windows 10, so I don't hold out much hope that anything will be done about it on Windows platforms any time soon.
Sadly, this just seems to be the price of admission to the modern software world. You have what is effectively a permanent rootkit installed if you want to use the software at all, and even though that is self-evidently incompatible with a robust security and privacy model, when big enough players do it, people just accept it because they don't see that they have any choice.
You can explicitly disable their auto-update mechanisms in the UI, I'm not sure if that's the case for Chrome, but force-closing the GoogleCrashHandler process isn't really comparable to an explicit UI toggle.
I've used Sparkle before (as a dev) and it's great, but I'm not sure it does that.
Plus, thinking about it, how does Google deal with Carbon Freeze?
They also want the ability to do rolling updates incase an update is bad. For example, roll this update to up to 1% of users, wait 10 minutes, then roll it out to all users if those 1% don't have worse crash statistics.
It also does diff-based updates, so security patches can be delivered in just a few kilobytes, which is important for all the users on GPRS connections.
Other updaters also don't have the ability to downgrade, either based on the new version failing to start, or based on a message from Google, which might be necessary if an update is bad.
Other update platforms don't let them have fine-grained control and a fast feedback system like that.
Installing browsers by hand in your homedir specifically so they can update themselves and you don't rely on the system package manager seems like a fairly widespread recommendation, but maybe I'm talking to a biased set of people.
Not from me to others using Fedora, the chrome you get via
dnf install fedora-workstation-repositories
dnf config-manager --set-enabled google-chrome
As a general rule I use what is in the repo's unless I absolutely can't or the version in the repo is so old that I can't.
http://neugierig.org/software/chromium/notes/2011/08/zygote....
(Sorry to spam this thread multiple times with this, but it is very relevant.)
They could use feature flags for the majority of slow roll updates. This would also mitigate the absence of a downgrade mechanism because you can just disable the feature flags. To be fair, I would love to see the App Store feature these types of mechanisms, but Google should request from and/or work with Apple here, not hack around them.
Or Apple should implement all of those features and reach out to and work with Google so they don't have to hack around anything.
Google is not entitled to anything here, and for a competitor to expect as such is absurd.
What exactly is preventing Chrome from checking for updates / security patches itself (even taking notifications to update) without the use of a launchd agent? Why should any part of a browser be running when I an not using it?
A background agent can do this invisibly; no prompts, no interaction. It's much more seamless, but it does require a bit of arrogance on the developers part - it seems quite silly that every application would have such an agent, so they're self-selected by self-importance.
1. Updating when the app isn't running avoids the case where someone opens a link, etc. before it updates. This is probably moot now that most people have it open constantly and are probably using Gmail rather than a standalone mail client.
2. On a multiuser system, the system updater can work when nobody is logged in or the active user doesn't have permissions to install the update.
It's like an attack surface thing, but the attacker is Murphy and his law.
To be fair, not even Microsoft does that.
Where are the industry veterans at Goole?
Asking for admin rights on install - ostensibly for installation purposes only - and then by concealment retaining those rights for other undisclosed purposes without further gaining the consent of the user seems like fraud to me.
But it's also correct to say that this is how the median software vendor typically does business.
I think it is fraud to coerce a password out of a user under the pretense of installation and then retain and use admin privileges for other purposes without further user acknowledgement.
>> The specific conditions required for the Chrome update to make this change are:
>> SIP must be disabled (or not present, as is the case pre-OS X 10.11)
>> The root directory, /, must be writable by the logged-in user
>> ...
Keystone is malware written by Google and it needs to die.
It's a tradeoff that favours Google and imposed by the unilaterally.
I could think of a few ways this could be addressed without forcing it. Such as detection from the browser app when it's not available.
I am sure Apple will be perfectly fine with putting a competing browser on their store, especially one whose entire corporate model is founded on tracking users to better serve them ads. I foresee absolutely no conflicts coming from either side of this relationship.
E.g. I'd put a dollar on this being a variable naming bug, where they called unlink(temp_dir) instead of unlink(temp_dir_where_we_put_stuff), with the former being "/var".
Chrome is spyware that can be used to browse the web (while advancing the agenda of the ad company that built it).
Since spyware is loosely classified as a virus, I would beg to differ with the headline.
By the way, aside from all the "regular tracking" it does, did you know that the Chrome updater spawns programs with random names that write other programs with random names. Sounds like a virus?
And just check out what it is doing to get you past a captcha... you can't. It is on a OS level, not a browser level, and everything about what it is doing is VERY obfuscated. Very virusy IMO?
How the hell does that get past QC?
Also heartily agree with other comments about Google's update processes in general.
Trust is still a house of cards in computing :(
This only affected users who went out of their way to disable this security feature. Presumably Google QA had this enabled on all their machines.
I mean, he can't be all that murdery, right?
We're talking about nuking a filesystem, not glitching out randomnly. That it hasn't nuked the filesystem before is not extenuating circumstances. It doesn't speak to character either.
People here sometimes.
But I am rather pissed at Apple because SIP is a global switch and with it enabled, there are several significant, legitimate things you cannot do with your own computer. SIP should work like sudo, not like a meta version of root. If it did so, nobody would have been affected by this week's Google nonsense.
For those wondering about such a use case: the only way to get eGPU's working on <=2015 MBPs is to disable SIP (and use purge-wrangler). It's not officially supported because 2015s don't have TB3
sudo rm -Rf /var
SIP is intended to protect against malicious software and against users accidentally hosing their system; there are legitimate reasons for disabling it. This was not anyone's fault but Google's.
It’s not just a QA issue - it’s a design flaw.
rm /var1) included code that performed dangerous system-level operations, despite the fact that
2) the included code was guaranteed to fail under the expected / default OS configuration?
The only logic I could see for such a state would be "let's teach them a lesson" for those users who chose to operate in the "dangerous" configuration. It doesn't make sense why they'd even attempt the symlink removal.
Which is the cause of like 90% of accidental "rm -rf /"s in history.
If this were an individual working alone (or even a small company), I'd have some sympathy. But Google has enough to pay QA engineers and build a sufficiently sophisticated test lab. They should get no pass for this.
I'm always finding people doing string arithmetic instead of using the APIs. Sometimes I catch myself doing it.
Rails got close to a solution by half-assedly tracking the provenance of all strings passed into certain functions. We could probably use a bit more of that.
All it would have taken is testing the installer on a non-SIP Mac.
But even when I have a QA team, which is less and less often, I like the devs to be involved in setting up stuff like this. QA is often not so good at engineering robust tests. But if they could write better code than we can they’d make more money as devs. So I’m still not letting the devs off the hook.
This class of error comes down to our chronic insistence on using stringly typed APIs for path/URI manipulation. It’s tantamount to a SQL injection attack, but with less data in the “query” instead of more. You should not be assembling file paths for destructive writes or deletes by string concatenation. But this is on almost nobody’s radar.
Is anyone else in this thread advocating for a change in software design? Mostly we are all blaming Google for fucking up. This is the headspace everyone but PHP was in for SQL fifteen years ago.
Like most failures, the analysis needs to identify a chain of events involving various failures; perhaps it would go something like this:
1. Industry and libraries commonly use strings for path/URI manipulation.
2. A software engineer did so in the installer and made a typo.
3. Code review did not identify the problem.
4. QA (and the CI process) didn't test on a Mac that was either old enough not to have SIP or had SIP disabled.
5. Many Mac users, especially in specialized environments running custom or specialized kernel extensions and drivers, use macOS with SIP disabled.
6. Chrome is widespread enough that some users in (5) downloaded the update. That subset had their Mac systems hosed.
I would identify (2), (3), and (4) as problems in the chain where Google carries blame.
Doing something stupid and relying on the safety equipment to save you is a stunt. Doing it with someone else's stuff is being an asshole. This is not the behavior of sober grown-ups.
That doesn't protect you fully. You still have to check that $myfile is not undefined or "", but it helps with related problems and it tends to arrange the code in such a way that the lack of further sanity checks sticks out a bit more.
Did you see the list of prerequisites? The test matrix gets to be massive when you have all those specific conditions to test.
Also seems like you could test against an image. And then do a diff on the entire image to catch unexpected deviations like that.
https://mrmacintosh.com/google-chrome-keystone-is-modifying-...
That's awesome! Well, the name is awesome, not the digital "surgical" procedure, of course. ;-)
I suppose if instead you just deleted random files from /var, that would be a varotomy?
I can't think of anything, offhand, that would be a varostomy.
For those unclear on the difference between -ectomy, -otomy, and -ostomy, see [1].
https://www.straightdope.com/columns/read/607/in-medicine-wh...
We don't put anything that's not absolutely necessary on our build machines, for example.
It was interesting to see things like fonts disappearing randomly from web pages etc as my computer progressively went mad.
> system integrity prevention
would be a pretty funny OS "feature".
Google in 2019 is a bloated and incompetent company consumed by internal politics that has no vision. Chrome has been nothing but a ploy for google to ruin the web from the get go.
Missing the boat on cloud computing while they were flailing away at social is pretty strong evidence of that
> ruin the web
The web was pretty bad pre-Chrome. Browsers were much slower and much less compatible. Things started to get worse once Chrome market share got to a third, or so, and Google started driving the direction of the web.
Changing this same browser to make your sites load faster while not announcing these changes so your competitors scramble while meanwhile you go "what, me worry?"
Just pathetic really. It's not like they were trying to push us past some inefficiencies, just taking us to ones they owned.
If not, what is Chrome doing differently than Chromium?
The issue was not Chrome in and of itself, but Google Keystone, which is the update daemon for Chrome. I don't think Keystone is open source so you can't grep for 'unlink("/var")' to figure out what was going on.
The expected scenario is that the browser is installed by an administrator (a sudoer), and the keystone agent is installed the same. The background agent runs as an elevated process specifically to remove the dependency on the logged-in user .. but with the side-effect that you're now trusting Google not to remove /var. Because, yaknow, we generally assume Google aren't that clueless.
Then we have a layer below that, "System Integrity Protection" (further enhanced by read-only-root in 10.15) which stops processes removing such vital parts of the OS, even if they are root. Which is where the Avid red herring came from. If you need to install unsigned kernel extensions, you need to disable SIP. And it turns out third-party video drivers are popular with the video editing crowd - so they had a much higher prevalence of users running without SIP.
We will continue to see these issues until there is a brand new OS which isolates subsystems by design. That is, each application/process gets not only own address space, but own file system, own settings store, with the OS carefully managing cross-boundary accesses.
> When SIP was enabled—as it is by default—SIP worked as designed and prevented the change. When the protection was disabled, however, the file system was modified in a way that prevented Macs from rebooting.
not only there should be no way to disable this protection, it should be a deliberate design goal to prevent any process or application from accessing protected areas.
Loading unsigned drivers for eGPUs.
> not only there should be no way to disable this protection, it should be a deliberate design goal to prevent any process or application from accessing protected areas.
I think you're looking for iOS.
https://www.cvedetails.com/product/15556/Apple-Iphone-Os.htm...
loading dev drivers should be done differently, and limited to dev, not production. the fact that one needs to disable security feature in production indicates a bad design.
i.e. the user may explicitly allow loading of particular objects (using hashes).
Chrome had a bug and even if it wouldn't have broken the system had SIP been enabled, it's still a serious bug on chrome's side.
https://eclecticlight.co/2019/06/01/how-to-bypass-mojave-10-...
I'm not sure what else you'd expect from one of the most widely used software platforms ever made.
Total number of vulnerabilities : 26
One way to achieve security is to enforce what an application/process can do is via specialized interfaces. For example, java.io.File will only see a virtual application filesystem, and one would need to grant special permissions (via a different interface) for file access outside of the app sandbox.
These permissions should be controlled (and audited) by the user. Possibly at more levels than currently (blocked/allowed always/while running).
It's just that implementing your sandbox at the same level as untrusted code is a really poor choice.
The devil is in details, in other words, it matters how the sandbox/isolation is implemented.
I would expect this: some malicious code requests a service object from the OS. An implementation is returned, but if no permission is granted by the user, the said implementation does nothing. There should be no data in the service object that can be used to glean any information about the internal state.
The only thing that can be detected in this design is that the service object does nothing (and even then, perhaps, it is possible to emulate the service behavior such that the code thinks everything is fine).
What do you think of that?