Google's Project Zero Team Releases Details On High-Severity macOS Bug 'BuggyCow' (wired.com) 40
Google's bug-hunting researchers known as Project Zero have revealed a fresh zero-day vulnerability in macOS called "BuggyCow." "The attack takes advantage of an obscure oversight in Apple's protections on its machines' memory to enable so-called privilege escalation, allowing a piece of malware with limited privileges to, in some cases, pierce into deeper, far more trusted parts of a victim's Mac," reports Wired. "The trick's name is based on a loophole the hackers found in the so-called copy-on-write, or CoW, protection built into how MacOS manages a computer's memory." From the report: Some programs, when dealing with large quantities of data, use an efficiency trick that leaves data on a computer's hard drive rather than potentially clog up resources by pulling it into memory. That data, like any data in a computer's memory, can sometimes be used by multiple processes at once. The MacOS memory manager keeps a map of its physical location to help coordinate, but if one of those processes tries to change the data, the memory manager's copy-on-write safeguard requires it to make its own copy. Which is to say, a program can't simply change the data shared by all the other processes -- some of which could be more highly privileged, sensitive programs than the one requesting the change.
Google's BuggyCow trick, however, takes advantage of the fact that when a program mounts a new file system on a hard drive -- basically loading a whole collection of files rather than altering just one -- the memory manager isn't warned. So a hacker can unmount a file system, remount it with new data, and in doing so silently replace the information that some sensitive, highly privileged code is using. Technically, as a zero-day vulnerability with no patch in sight, BuggyCow applies to anyone with an Apple laptop or desktop. But given the technical skill and access needed to pull it off, you shouldn't lose much sleep over it. To even start carrying out this Rube Goldberg -- style attack, a hacker would need a victim to already have some form of malware running on their computer. And while BuggyCow would allow that malware to potentially mess with the inner workings of higher-privileged parts of the computer, it could do so only if it found a highly privileged program that kept its sensitive data on the hard drive rather than memory. Project Zero says it warned Apple about BuggyCow back in November, but Apple hadn't acted to patch it ahead of last week's public reveal.
Google's BuggyCow trick, however, takes advantage of the fact that when a program mounts a new file system on a hard drive -- basically loading a whole collection of files rather than altering just one -- the memory manager isn't warned. So a hacker can unmount a file system, remount it with new data, and in doing so silently replace the information that some sensitive, highly privileged code is using. Technically, as a zero-day vulnerability with no patch in sight, BuggyCow applies to anyone with an Apple laptop or desktop. But given the technical skill and access needed to pull it off, you shouldn't lose much sleep over it. To even start carrying out this Rube Goldberg -- style attack, a hacker would need a victim to already have some form of malware running on their computer. And while BuggyCow would allow that malware to potentially mess with the inner workings of higher-privileged parts of the computer, it could do so only if it found a highly privileged program that kept its sensitive data on the hard drive rather than memory. Project Zero says it warned Apple about BuggyCow back in November, but Apple hadn't acted to patch it ahead of last week's public reveal.
Backwards Wired? (Score:1)
"The attack takes advantage of an obscure oversight in Apple's protections on its machines' memory to enable so-called privilege escalation, allowing a piece of malware with limited privileges to, in some cases, pierce into deeper, far more trusted parts of a victim's Mac," reports Wired. "The trick's name is based on a loophole the hackers found in the so-called copy-on-write, or CoW, protection built into how MacOS manages a computer's memory."
What's with the dumbed-down language, Wired? "obscure oversight"? "so-called" this and that? Please do tell, this so-called high-severity so-called bug, is it so-called dangerous to the so-called victim?
At least, if one manages to waddle through to the last paragraph, there's this guarded piece of criticism:
"They've had a lot of very-high-profile security-related bugs and some have been really, really stupid," Reed says. "It makes you wonder what's going on with the QA process at Apple. Are they adequately testing? Lately, it seems like they're not."
Apple: copying Microsoft's Win XP security practices takes courage - and now has far better eye candy!
Single-user machines (Score:3, Informative)
Totally different on a server. If you have 100 users on a server, then escalation from one hacked user to the other 99 is a fatal problem.
Re:Single-user machines (Score:5, Informative)
Most single-user machines don't have a separate admin account. So breaching the user's account is breaching an admin account. That's why the GP said that for single-user machines, privilege escalation rarely matters.
Of course, it isn't *quite* true. There are processes like the keychain that provide some additional privilege separation between apps. If the keychain happens to store out-of-band mach message data in a vulnerable location, then this could lead to arbitrary code being able to modify keychain requests from other apps to steal passwords somehow. Maybe. But realistically, those sorts of communication mechanisms shouldn't be storing data to disk even temporarily.
Re: (Score:2)
That is only semi correct.
An singe user Mac has an account that has an "is admin flag", and that simply only means: he can use sudo.
So: you still need to escalate somehow to root to do anything meangful.
Re: (Score:2)
Depends on what you mean by meaningful. As a user in the admin group, without becoming root, you can:
And there are probably a lot more mischievous things that one can do with code running as a non-root admin user that I'm not thinking of. :-) Some of the things in the list above don't even re
Re:Single-user machines (Score:5, Insightful)
Most single-user machines don't have a separate admin account.
Mine does. And MacOS makes it trivially easy to run as a non admin, only invoking admin rights when necessary.
I try to encourage everyone in my circle to set their computers up that way. Occasionally I’ve even been successful.
Re: (Score:2)
That about sums it up. :-)
Re: (Score:2)
Most single-user machines don't have a separate admin account.
Mine does. And MacOS makes it trivially easy to run as a non admin, only invoking admin rights when necessary.
It's the default, isn't it?
But this doesn't really undermine the claim that privesc doesn't matter much on single-user machines with traditional ownership models. Most everything of value on the machine will be owned by the non-admin user account anyway.
This, BTW, is why the app isolation that mobile OSes do is so important. If you get arbitrary code execution in one app on my Android phone, you only get to see that app's data. You need some privesc vuln to get to anything else. But desktop OSes still
Re: (Score:2)
It's the default, isn't it?
But this doesn't really undermine the claim that privesc doesn't matter much on single-user machines with traditional ownership models. Most everything of value on the machine will be owned by the non-admin user account anyway.
No, it’s not the default - the first account created is an admin account, and for many single-user Macs that ends up being the only account. And for family computers, it means Mom’s account or Dad’s account is an admin by default - unless one decides to take the extra step.
I wasn’t really intending the point specifically with regard to privilege escalation. If you’re specifically targeted as an individual, you could reasonably argue it probably doesn’t help much. But at a
Re: (Score:2)
If you’re specifically targeted as an individual, you could reasonably argue it probably doesn’t help much.
Even if you're not targeted specifically, but just a target of opportunity.
But at a minimum you’re increasing the complexity of what is necessary for someone to own your machine - and it’s basically painless so why not take that extra step?
No argument there, though I still maintain that protecting the machine is close to irrelevant. What matters is the data on the machine.
Re: (Score:2)
Most single-user machines don't have a separate admin account.
This hasn't been true since 2006 when Windows Vista came out, 13 years ago.
With Vista the default user account became a non-admin one. Vista also introduced new system accounts that you can't log in to.
On top of that you have UAC, which means that even with an admin account certain actions require extra confirmation from the user.
So yeah, privilege escalation on a single user Windows machine is pretty severe. Does MacOS really not have this kind of security model?
Re: (Score:1)
Re: (Score:2)
On a single user machine, privilege escalations are not really that damaging. If you manage to hack into my user account on my Mac (or my Windows PC, or many Linux desktops), you have access to all the valuables. There is just nothing of value outside my account.
Totally different on a server. If you have 100 users on a server, then escalation from one hacked user to the other 99 is a fatal problem.
Now do domain joined systems + lateral movement in the environment. Priv esc is devastating, especially from an APT perspective when trying to establish persistence. Stop trying to minimize this like its no big deal someone just fucking owned your box completely.
Re: (Score:2)
they are no longer interested in your data, they want to have an army of remote controlled bots.
Unmount filesystem (Score:1)
You can unmount/mount a file system without privileges on OSX? I don't think so.
Re: (Score:1)
Ah - so in other words, "root owns the computer." Next up, linux systems vunerable to "insmod malware"
FROM THE ARTICLE:
"To even start carrying out this Rube Goldberg–style attack, a hacker would need a victim to already have some form of malware running on their computer" (emphasis mine).
Mounting a filesystem requires root. (Score:2)
Mounting a filesystem anywhere that should actually matter (e.g. /tmp, /var/tmp) typically requires root privileges even in macOS. And any software that might realistically store out-of-bound data in a location where an unprivileged attacker could mount something over top of it (e.g. in the user's home directory) is not likely to be any more privileged than the attacker app.
Is there any actual evidence that this is a real vulnerability, rather than a purely hypothetical one? I mean yes, it's a bug, but i
Re: (Score:2)
You haven't needed root to mount a filesystems in over a decade. Not sure what you mean here. All your user needs is permissions. Pop a thumb drive into your system, no root required.
Re: (Score:2)
Reread what I said.
Typically, you can only mount things over top of directories that you own. The Disk Arbitration framework also allows you to mount things in /Volumes as a special case, by sending requests to a daemon (diskarbit
Re: (Score:2)
But it is mounted under /Volumes and not at a random place belonging to root.
Re: (Score:1)
You haven't needed root to mount a filesystems in over a decade. Not sure what you mean here. All your user needs is permissions. Pop a thumb drive into your system, no root required.
Please turn in your geek card, geek (5680). Physical access trumps everything; you don't need root if you have physical access.
Need I? Can I? Should I? (Score:1)
And the cow goes... ... mooooo!
Bias? (Score:2)
From how I read this, you can basically silently substitute arbitrary code or data pages of programs running in memory. Even ones that might say use security hardware like the T2 chip to make itself less vulnerable even to root based attacks. And from the article, you just have to first execute code on the machine - a feat which with modern browser based and hardware flaw exploits, or even just plain phishing, isn't hard.
And of course, the memory manager/vfs allowing y
Its difficult for new bis to understand (Score:1)