
No, it wasn’t a virus; it was Chrome that stopped Macs from booting - ColinWright
https://arstechnica.com/information-technology/2019/09/no-it-wasnt-a-virus-it-was-chrome-that-stopped-macs-from-booting/
======
ga-vu
Previous discussion:

[https://news.ycombinator.com/item?id=21064663](https://news.ycombinator.com/item?id=21064663)

[https://news.ycombinator.com/item?id=21073819](https://news.ycombinator.com/item?id=21073819)

~~~
ColinWright
Thanks, I went looking for a previous submission, but couldn't find one. I
figured if I posted it myself someone would provide the pointer.

I'll leave this here to capture other submissions of this source.

Cheers.

 _EDIT: Also, interesting to read the discussions there._

~~~
ga-vu
Better if you'd stop submitting ArsTechnica stuff. All that site does is take
other outlets' articles and run them as their own. I'm surprised nobody has
sued already, especially since they have a subscription service asking for
money for stuff that other people research and publish first.

------
jacquesm
Application level software should 'stay in its lane'. Chrome and the Chrome
updater shouldn't even have this level of capability.

~~~
dehrmann
Hubris is a big fault of Google and its engineers. They have a culture of
thinking "there's one way to do it, we're smart, and we know best."

~~~
ben0x539
Shrug, seems like every application that's not designed to live in debian
package repositories from the ground up eventually evolves an updater, or even
a package manager for plugins. This hubris isn't unique to google, it's
everywhere because we fundamentally haven't figured out how to manage updates
in a way that meets requirements.

~~~
thaumasiotes
> we fundamentally haven't figured out how to manage updates in a way that
> meets requirements.

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.

~~~
lazyasciiart
Thats the first user requirement. You forgot this one

2\. Never be vulnerable to known attacks.

~~~
thaumasiotes
I didn't forget. That is not a requirement for most users. The whole idea of
forcing people to update is that _we_ don't want _them_ to be vulnerable, so
that _their_ machines aren't used against _us_. The users commonly don't
suffer negative effects from being exploited.

~~~
lazyasciiart
Ransomware is big enough news that I don't think that's true even for very
non-technical users.

------
protomyth
I still don't understand why Google needs to have something more than the
basic update functionality that other Mac Apps have via libraries like
Sparkle?

~~~
crushingcrash
To be honest, because they're arrogant. It's the same reason they don't adhere
to each OS's UX/UI guidelines (including on Windows!) It's an absolute
arrogance that they are "above" these platforms.

~~~
jamesgeck0
> It's the same reason they don't adhere to each OS's UX/UI guidelines
> (including on Windows!)

To be fair, not even Microsoft does that.

~~~
saagarjha
Microsoft does a much better job than Google does.

~~~
londons_explore
Well microsofts UI style changes every ~3 years, and they don't restyle old
stuff, so at any point in time there are 10 or so possible correct stylings...

------
dreamcompiler
It wasn't Chrome either. It was Keystone, a separate program that updates
Chrome and other Google programs. Most users have never heard of Keystone (and
Google likes it that way), but Keystone is running on your computer if you've
ever used Chrome or Earth or another Google program. A bug in Keystone caused
this problem. Keystone is very hard to kill and if you succeed in killing it
it has a nasty tendency to come back.

Keystone is malware written by Google and it needs to die.

~~~
monocasa
To be fair, updater software for security conscious apps have good reasons to
be hard to kill. Even outside of an attack scenario, you want to give as much
chance as possible for your apps to still update even if you shipped a
crashing bug or something.

~~~
dreamcompiler
Unkillable software also has a very high bar for quality. That means among
other things that it needs to be a good citizen on my computer and have
_pristine_ quality control. Keystone is neither and never has been. With great
power comes great responsibility, and Google blew it.

~~~
monocasa
I mean, I'm going to judge them when I stop writing bugs. Until then, a
zealous updater seems preferable to leaving browsers around with CVEs, even
with this massive fuck up on their plate.

~~~
dreamcompiler
And yet Firefox found a way to solve that problem without creating malware in
the process.

~~~
monocasa
Firefox's updater breaks significantly more than Google's.

~~~
dralley
How often does it break _your computer_?

~~~
monocasa
I'm saying that for a lot of people, hard breaking their computer might be the
better option compared to stop updating CVEs and stealing everything the
person owns.

------
holy_city
My guess with what happened is that they were downloading to /var somewhere
and messed up a variable name when they called unlink() to remove their
temporary data, which when running as root would delete the symlink of /var to
/private/var. It wouldn't be caught if they weren't testing without SIP
enabled, on older macOS versions, _and_ rebooting as a part of the test suite.

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".

------
sam_goody
> No, it wasn't a virus.

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?

------
TazeTSchnitzel
This shows why System Integrity Protection is a great feature for most users.
Even an application running as root can't easily hose the system.

------
EricE
removed /var?

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 :(

~~~
TheCoreh
My understanding is that /var was only removed on systems _without_ SIP
enabled, the recommended (and default) setting.

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.

~~~
TimTheTinker
SIP is a relatively new feature. This would have been _devastating_ only a few
years ago. What Google did was effectively:

    
    
        sudo rm -Rf /var
    

Would you trust a program that even _attempted_ such a command on your
machine? "But they had SIP disabled" is no defense for software that tries to
take destructive action.

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.

~~~
magicalist
It's a symlink and / has to be writable by the logged in user, so it's
actually just effectively

    
    
      rm /var

~~~
KingMachiavelli
Since when is / writable by any logged in user? Is a MacOS thing?

~~~
acdha
It requires the user to have disabled SIP and then used root access to modify
it. On a standard install, it's owned by root:wheel with mode 755.

------
kjhughes
The Mr Macintosh blog (which the Arstechnica piece cites) has more technical
details:

[https://mrmacintosh.com/google-chrome-keystone-is-
modifying-...](https://mrmacintosh.com/google-chrome-keystone-is-modifying-
var-symlink-on-non-sip-macs-causing-boot-issues/)

------
detail-oriented
I don't use chrome any longer, firefox for the win.

------
mxuribe
> varsectomy...

That's awesome! Well, the name is awesome, not the digital "surgical"
procedure, of course. ;-)

~~~
tzs
OK, so unlinking /var is a varectomy. That fits.

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...](https://www.straightdope.com/columns/read/607/in-medicine-whats-the-
difference-between-an-ectomy-an-ostomy-and-an-otomy/)

------
midnitewarrior
The fact this was accidental is far worse than a virus.

------
fortran77
It's a Good Idea not to install any additional software, whether it's a
browser that's not the one bundled with the OS, Spotify, Slack, etc, on a
machine that's being used for production builds, editing.

We don't put anything that's not absolutely necessary on our build machines,
for example.

------
jomoio
This reminded me of the time I mistakenly deleted /var/tmp/ instead of just
deleting the contents of /var/tmp/. The router was not pleased.

~~~
scandox
I once deleted /usr ... Instead of /some/sub/dir/usr

It was interesting to see things like fonts disappearing randomly from web
pages etc as my computer progressively went mad.

------
KenanSulayman
An interesting side effect of the Keystone daemon is that Google is receiving
pings from all users running the software. I'm very sure that this enables
Google to proactively track users without only relying on persistent cookies.
Add Google DNS on top and you get a seamless, massive scale RUM solution.

------
shawkinaw
Off topic, but

> system integrity prevention

would be a pretty funny OS "feature".

------
vgetr
Remember when browsers were for, you know, browsing?

------
hnghost
I'll step up and say it.

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.

~~~
dehrmann
> no vision

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.

~~~
SN76477
Remember when Chrome was flaunted as the fastest browser? Now it's just
bloated.

~~~
tsm
I do, but I also switched back to Firefox recently (after using Chrome for ten
years) and it's slower. What _is_ the fastest feature-complete browser in
2019?

~~~
sixothree
Edge Dev is pretty darn fast.

~~~
monocasa
Isn't Edge switching to being a skinned Chromium?

~~~
sixothree
Yes. Edge Dev is a Chromium flavor.

------
iamdumb
Did Chromium users on MacOS have this issue as well?

If not, what is Chrome doing differently than Chromium?

~~~
holy_city
Disclaimer: this affected me tangentially which is why I've been trying to
figure out what exactly happened and where it came from.

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.

------
wokkel
Everybody seems to be reading over the fact that the logged in user must be
able to write to /. Is this common for macOS users? If so there is a
significant pebkac factor as well.

~~~
soneil
It's not dependant on the logged-in user, keystone is a background agent
(daemon) that handles Google's updates.

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.

------
java-man
This basically tells about the state of computer security in general. There is
no isolation of OS from applications, or between the applications. This is by
design, dated back to early unix times.

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.

~~~
coryrc
Programmers developed containers and kubernetes to cover this space, but we
haven't created a consumer OS with programs each in their own container.

~~~
wozer
Android ist a bit like this, isn't it?

~~~
techntoke
Not really. Containers run natively and use the built in kernel features to
sandbox. Android uses the Java VM.

~~~
java-man
Android aside, the use of JVM might offer a better alternative (because of
bytecode validation).

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).

~~~
monocasa
That was tried by the sun JVM, and worked until they tacked on reflection.
Then there was just too many ways to break the sandbox when the sandbox is
implemented just like your code is and you've got a mechanism for doing brain
surgery on the process. Every time they'd fix a applet sandbox escape two more
exploits would pop up.

~~~
java-man
Security must be the primary design goal, at least right now. I don't think
the way Sun implemented permissions in java offers enough protection.

~~~
monocasa
I mean, security was absolutely a primary design of java applets.

It's just that implementing your sandbox at the same level as untrusted code
is a really poor choice.

~~~
java-man
Did you just proved my thesis? ;-)

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?

------
fortran77
This is why I run Firefox. Because it's written in Rust, these things simply
can't happen.

~~~
jasonmp85
You’re trolling, right?

~~~
beatgammit
I sure hope so because everything about that statement is wrong.

~~~
dreamcompiler
Including the implicit assumption that this was somehow a Chrome problem. It
wasn't. It was a Keystone problem, and Keystone is a separate program that
updates Chrome and Earth and other Google products. Still very much Google's
fault, but Chrome didn't cause the issue.

~~~
fortran77
Doesn't Mozilla write their installers and related programs in Rust, too?

