Google’s Project Zero researchers have revealed a “high severity” macOS security flaw nicknamed ‘BuggyCow’ that Apple appears to be in no rush to patch.
The vulnerability is in the way macOS implements a memory optimisation and protection routine used by all OS file systems called copy-on-write (COW).
The principle behind COW is that it provides a way for different processes to efficiently and securely share the same data object in memory until they need to modify it in some way – at that point, they must make their own copy of the data rather than changing the data in memory.
Writes Google’s Jann Horn:
It is important that the copied memory is protected against later modifications by the source process; otherwise, the source process might be able to exploit double-reads in the destination process.
Using BuggyCow, malware already running on a Mac might be able to tamper with the copy of the data written to the disk in a way that is invisible to the file system:
This means that if an attacker can mutate an on-disk file without informing the virtual management subsystem, this is a security bug.
If that related to a privileged process, that might be a route to a privilege escalation capable of interfering with sensitive data.
The specific mechanism used in the researchers’ proof-of-exploit involves unmounting and remounting the file system, which apparently generates no warning via the memory management layer.
The obvious objection is that a Mac that has malware on it capable of launching this kind of attack is already in deep trouble even without this somewhat involved technique being in the public domain.
But perhaps that’s to miss the most intriguing aspect of this story – the way Apple has reacted (or not) to Google telling it about the problem.
Deadline missed
Project Zero told Apple about the vulnerability on 30 November 2018 which means that Project Zero’s 90-day deadline for the company to address the issue expired on 28 February.
Doubtless, Apple has something in the works but either has other things to fix first or doesn’t want to be rushed despite the Google team rating its severity as “high”. Writes Horn, rather hopefully:
We’ve been in contact with Apple regarding this issue, and at this point no fix is available. Apple is intending to resolve this issue in a future release, and we’re working together to assess the options for a patch. We’ll update this issue tracker entry once we have more details.
Apple has yet to comment on the flaw but if you’re a macOS user, there’s no need to panic. It’s on the to-do list.
It’s not the first time COW has been in the news. In 2016, a flaw in the Linux kernel dubbed DirtyCOW (CVE-2016-5195) emerged that could allow root access – another version of the same privilege escalation weakness.
Laurence Marks
Google seems to impose the same 90-day timeline for all bugs. The flaw in that reasoning is exposed by this bug. This is a very tricky area to work in and a hasty fix could introduce data corruption and loss or severe performance issues. I wonder if Google shouldn’t have a more flexible deadline algorithm.
Mark Stockley
You’re correct about the flaw in the reasoning, but I think Project Zero began by trying to solve a more basic problem, that required a blunt instrument.
The problems it was trying to solve were at the two extremes of bug disclosure. On the one hand you had vendors who were either not fixing security bugs at all, or taking far longer than was safe. On the other hand you had security researchers practising “full disclosure” and releasing details of bugs, including POCs, without giving vendors any time at all to fix them. I think it’s done remarkably well to create a compromise most people can live with, even if they don’t love it.
I think people tolerate the arbitrary nature of the 90 deadline because it’s applied without fear or favour. If it had been done any other way then I suspect it would have died quickly under the weight of complaints about uneven treatment.
Who knows though, perhaps the program, and the idea it enshrines, is mature enough now to tolerate some flexibility and nuance in the deadline.
Paul Ducklin
The argument about flexibility and nuance is not new. Google says no (though IIRC you can get a 14-day extension if you have a fix ready but want to wait for an upcoming update window, or if you need to do a staged rollout, or something like that). At the outset, some Googlers were demanding that 7 days was enough, so 90 was a big compromise for them.
I get the point of the algorithmic 90-day rule but sometimes find myself wondering why Google thinks that 90 days is more than enough when updates in the Android ecosystem are still in the messy state they have been for years.
pip4so
Who cares about Android, does it collect all user data correctly? It does!
Does it send all the data to Google HQ? It does!
Perfect! Fits the reason it was built. No fix needed!
John W Redman
Why hid security failures Seems self serving to me. Delete damaged algorithm until fixed.
Give end users a chance to protect their data until flaw is fixed.
J A
DirtyCOW2: Electric Moogaloo
Bryan
I love it, J A!
Cow does this not have moore upvotes? I’ve calf a mind to corral myself a sock puppet account.
Allow me to steer the discussion a bit, you truly have given this thread a bovine intervention–and that’s no bullocks.
And that being the second religious joke I’ve made today on this blog, holy… well, you know.
Just can’t stop yakkin; I’ve really got to cud it out.