Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security Google OS X Operating Systems Privacy Software Technology

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.
This discussion has been archived. No new comments can be posted.

Google's Project Zero Team Releases Details On High-Severity macOS Bug 'BuggyCow'

Comments Filter:
  • by Anonymous Coward

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

    by gnasher719 ( 869701 ) on Thursday March 07, 2019 @06:35PM (#58234486)
    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.
    • by geek ( 5680 )

      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.

    • by sad_ ( 7868 )

      they are no longer interested in your data, they want to have an army of remote controlled bots.

  • You can unmount/mount a file system without privileges on OSX? I don't think so.

    • by Anonymous Coward

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

    • by geek ( 5680 )

      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.

      • by dgatwood ( 11270 )

        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.

        Reread what I said.

        Mounting a filesystem anywhere that should actually matter requires root privileges even in macOS.

        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

      • But it is mounted under /Volumes and not at a random place belonging to root.

      • by Anonymous Coward

        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.

  • by Anonymous Coward

    And the cow goes... ... mooooo!

  • This article is really oddly phrased.
    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 quite difficult to understand the bug in start Bordena [slashdot.org]

It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption.

Working...