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.
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.
> 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.
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.
I wish both OSX/MacOS and Windows had a generic solution for 3rd party applications to check for updates, that wasn't tied to their respective stores. It's such a common pattern and requirement, the OS should/could provide the infrastructure to have a background service that periodically checks external links for availability of new software.
Right; except sparkle is terrible. At exactly the moment I want to use the app I get bothered by a difficult decision: Do I want to interrupt the flow of my work and wait a couple minutes so it can download and update, moving something that should happen in the background into something that directly interrupts my flow. Or skip the update and hope there were no important security / compatibility issues fixed. (Or kick the cart down the road and have it remind me later.)
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.
You forgot that, after you've told it to download the update, it pops up another interrupting dialog asking whether you want to install the update. If you just tell it to update and go get a coffee, when you come back, it won't be done.
I like how Sparkle mentions being “modern” and uses “supports [...] Xcode 5.0 through 7.0” as evidence. Xcode 7 was released in 2015; the current version of Xcode is 11. Looks like the website needs a little updating...
(To clarify, I’m just pointing out a humorous observation, not making a statement on Sparkle)
A good point and one of those strange troughs we get stuck in, every application having it's own different incompatible update system is clearly a bad idea but solving it requires the co-operation of disparate teams each of whom consider the amount of pain it causes end users as minor.
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.
I have reported two Chrome OS bugs that allow bypassing Chrome's Own enterprise security policies. Both bypasses involved using Chrome extensions... written by Google.
Well, it sounds like a lot of defaults would have to have been changed to insecure settings for Chrome to have the permissions, so... you're right and Apple agrees. I mean if `/` is writable by your login user, then something has gone terribly wrong in your process somewhere.
Red flag #1 should have been when Chrome could install itself on Windows while bypassing administrator restrictions by not being installed in Program Files.
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?
I think they are very keen to have the ability to give updates very fast in case of a major exploit used in the wild. They want to be able to do all updates worldwide in a few hours, rather than the days or weeks that OS updaters take.
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.
The irony here is that by taking more intrusive permissions, they can accidentally do more damage and open up more exploit vectors, for which they'd want to ship an emergency patch, as we see here.
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.
Everything you listed there looks very reasonable to me, but aren't these all details that should be supported through a standardised OS-level update mechanism? The reality that the big desktop OSes do not offer those facilities in 2019 says more about the regrettable state of application management on desktop OSes than it does about Google or Chrome.
I think they are very keen to have the ability to give updates very fast in case of a major exploit used in the wild.
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?
It's so if you screw up and ship a version that crashes, you can still probably be updated. The updater is a tiny piece that only updates, and is itself not updated very often.
It's like an attack surface thing, but the attacker is Murphy and his law.
I don't know their reasoning but here would be mine:
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.
I think it's a user-experience thing. If a user-level application (eg, browser) discovers an available update, it has to launch a privileged process to update itself - which means an authorisation prompt. And just popping up and asking people for their password without an obvious reason why is bad form, so you usually end up offering to update. It makes the whole process more invasive, less seamless, and more chance people will click no/cancel.
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.
I would say it goes the other way. Any program better ask me as the owner of the box to elevate to Admin. That is how it works on OS X. Any program that tries to get around this as a "user-experience thing" is a bigger danger than the threat it is protecting against.
Having to wait for a security update to make it through the various update pipelines of all the different linux distros isn't a great situation for users either.
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.
I feel your post is answering a different question than what I asked? You're answering "why is our process spawning model so obscure on Linux" rather than "why does Chrome not shove its updates down Linux users' throats out-of-band like it does on every other platform". (Unless you're suggesting the answer is the bit where you say they just didn't want to appear lame?)
There's no reason you can't do all of that with basic user level permissions. A browser shouldn't be screwing with OS files in any significant way (i.e. other than user level settings) to begin with.
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.
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...
Also, it's the same arrogance that makes them push AMP so much. What AMP does is awesome just not how they do it. The wrapper, the URL hijacking, the janky scrolling, no reader view ...etc. It completely breaks my normal flow on my phone that I end up making DDG the primary search provider and Apple News (which is not good at all) as the news aggregator.
it's not just arrogant, it's fraud:
https://legal-dictionary.thefreedictionary.com/fraud
"A false representation of a matter of fact—whether by words or by conduct, by false or misleading allegations, or by concealment of what should have been disclosed—that deceives and is intended to deceive another so that the individual will act upon it to her or his legal injury."
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'm a long way from the valley and regard googles behaviour as arrogant in the extreme, they are 1990's era microsoft with better PR, I don't trust them at all and that they seem to have taken control of the web via soft means is worrying as hell.
This is what happens when they systematically hire fresh grads that more keen on solving interview quiz puzzles than actually building good software.
This kind of a mess shows a clear lack of seniority leadership.
Google runs a system-level update service on Windows too. The crash handler for it is also running all the time, at least on my machine (and is running with root-equivalent permissions). If you disable it, the next time you launch Chrome they just turn it back on.
> Google runs a system-level update service on Windows too. The crash handler for it is also running all the time, at least on my machine (and is running with root-equivalent permissions). If you disable it, the next time you launch Chrome they just turn it back on.
> 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?
Even Apple and Adobe don't actively turn their update services back on when you run their applications if you have explicitly disabled them, though, at least not in any version of any of their software that I've come across.
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.
> Even Apple and Adobe don't actively turn their update services back on when you run their applications if you have explicitly disabled them, though, at least not in any version of any of their software that I've come across.
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.
Once you've got a culture where it's not your machine, it's just another sensor in Google's panopticon, the idea that Google should do this makes perfect sense.
But can you put an application in /Applications (requires administrator privileges), then have a non-administrator user run the app and complete an update?
Right. But Chrome allows you to do that if the administrator has enabled it. To handle that securely, though, would likely require a specifically restricted daemon or setuid process that is well beyond most normal update use cases. And that might explain why they couldn't just use Sparkle.
The point is this shouldn't need to be done. If an administrator has installed an app, then it's the administrator's responsibility to update it. If I want to update an app myself, I'd install it in ~/Applications instead.
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.
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.
Keystone should be killed in favor of the App Store, along with all the other single-corporation licensing/downloading/updating apps.
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.
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.
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.
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.
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.
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".
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?
The general thing in software dev is that it's usually easy to catch a specific bug, it's just that there are so many possible bugs you can't think of them all. I'm sure there is now a test that checks for strange deletions on macos, or will be in a few days. Until the next stupid thing nobody expected..
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.
How many Chrome updates have you gotten that did not break your computer? Was your computer broken by this? My understanding is the rollout was stopped fairly quickly.
How many times did Ann Rule interact with Ted Bundy and he didn't murder her once?
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.
I'm as comfortable using Google apps today as I was a week ago, because I figured out long ago how to disable Keystone permanently. (It wasn't easy.)
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.
> with it enabled, there are several significant, legitimate things you cannot do with your own computer.
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
Why do they have code that's trying to remove /var?
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.
could be something as simple as "rm /var/$myfile" with myfile being null or unset. As long as /var isn't owned by the current user and/or SIP is installed, testing won't let them know they have a problem.
This is why you should always construct paths in particular and URIs in general using your languages' path APIs instead of string interpolation.
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.
1) 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.
or 3) They intended to remove a more specific symlink, with the address generated from variables, but due to bugs some/all of the variables were empty and the concatenation of the variables just produced /var instead.
Which is the cause of like 90% of accidental "rm -rf /"s in history.
Right, but if you're a large software distributer, the onus is entirely on you to QA software releases on every possible OS configuration.
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.
Well, hold on. Let's not scapegoat another team for the fact that we can't seem to handle relative paths well after 30 years of spectacular case studies in how fucking stupid we are with path calculations.
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.
The fact that this got through Google's QA is inexcusable. Yeah I understand a dev messed up. It happens. But it should have been caught before being released.
All it would have taken is testing the installer on a non-SIP Mac.
In this case a smoke test on such a Mac could have sufficed, yes.
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.
Another possibility is that it had a list of all the files and directories it has installed, and removed each one before installing a new version. If the list included also all the parent directories (which is common if you want to avoid leaving empty directories behind), and the list did not specify whether each entry is a file or a directory (that is, it looked at the disk for each entry: if it was a directory, it did a rmdir, otherwise it did an unlink), and it installed anything below /var, all that combined plus the fact that /var was a symlink instead of a directory could lead to it calling unlink on /var, while the developers would be expecting it to do a harmless rmdir (which does nothing unless it's an empty directory).
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.
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.
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.
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?
I used to a big fan of Google. I bought chrome book but now I am unhappy because I can’t run Firefox on it. Next I will buy windows pc because you have the ability to install Firefox on it.
It's not that Chrome itself is a problem but rather the way that Google releases updates for Chrome which damages the ecosystem. Build a good browser that helps users load elements faster and enjoy the web more? Always good!
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.
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.
As far as I know, Chromium itself doesn't support automated updating. There are third party updating tools for most platforms, but the automatic updater from Google is not used for Chromium.
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.
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.
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.
The problem with that — for users — is that it is likely to lead to the phone-style data roach motel, where applications control users' content and hold it hostage from them.
> 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.
Some gpus need SIP on off because the drivers won't run else. I generally also have to disable it because I run some apps and modify some underlying behaviours in macOS that I find undesirable. I don't think it should be any worse than running stuff as sudo on Unix, where you can easily break the whole OS if you, as the user, don't know what you're doing.
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.
> 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 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).
Sometimes you want to do things that the OS maker does not want you to do, like run dtrace on system binaries. If you had no recourse to bypass the OS maker, the world would be a much worse place.
Perhaps if Apple would let us self-sign drivers on our computers, we wouldn't need to disable SIP. Security that does not allow the actual use of the computer gets disabled.
Yes, 100% this. SIP is badly designed because it's a global hammer like root. As such, it prevents power users from doing quite legitimate things with their computers and so we have to turn it off. SIP should work like sudo, not like meta-root.
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).
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.
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).
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.
https://news.ycombinator.com/item?id=21064663
https://news.ycombinator.com/item?id=21073819