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.
> 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.
> 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).
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.
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.
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.
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.
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).
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.
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?
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 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.
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.
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?)
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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 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.
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
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.
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).
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.
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..
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.
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 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.
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)
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.
> 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 have reported two Chrome OS bugs that allow bypassing Chrome's Own enterprise security policies. Both bypasses involved using Chrome extensions... written by Google.
Red flag #1 should have been when Chrome could install itself on Windows while bypassing administrator restrictions by not being installed in Program Files.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
202 comments
[ 2.9 ms ] story [ 299 ms ] threadWe 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-...
https://www.cvedetails.com/product/15556/Apple-Iphone-Os.htm...
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?
https://www.qubes-os.org/doc/architecture/
https://news.ycombinator.com/item?id=21064663
https://news.ycombinator.com/item?id=21073819
I'll leave this here to capture other submissions of this source.
Cheers.
EDIT: Also, interesting to read the discussions there.
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
Is rapidly updated.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
>> ...
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
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.
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.
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.
> SIP, as system integrity protection is usually abbreviated, was introduced in 2015
https://en.wikipedia.org/wiki/System_Integrity_Protection
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.
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...
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.
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.
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".
https://mrmacintosh.com/google-chrome-keystone-is-modifying-...
It was interesting to see things like fonts disappearing randomly from web pages etc as my computer progressively went mad.
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?
> system integrity prevention
would be a pretty funny OS "feature".
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.
We don't put anything that's not absolutely necessary on our build machines, for example.