
Google reveals “high severity” flaw in MacOS kernel - ben201
https://www.neowin.net/news/google-reveals-high-severity-flaw-in-macos-kernel/
======
Someone1234
Quick Summary: This is a local process escalation bug. Serious, but it seems
remote exploitation would require an additional bug.

Project Zero has stuck to their 90 policy with everyone. They aren't picking
on Apple, they've released unpatched bugs for most major vendors.

You may disagree with publication, but keep in mind this is a bug that may be
known to some already. There are literally thousands of "private exploits"
available for sale if you know where to look.

The 90 day policy forces companies to make their customers safer, and if not
90 days you'd still have to pick an arbitrary length of time but companies may
take a longer deadline even less seriously and miss that too (and people would
criticize that too).

~~~
wtmt
> Quick Summary: This is a local process escalation bug. Serious, but it seems
> remote exploitation would require an additional bug.

The "additional bug" could just be a compromised update of any popular
application available as a free download (see [1])? Then it is serious,
because people download and run all kinds of applications from any website
that seems useful to them.

[1]:
[https://en.wikipedia.org/wiki/Transmission_(BitTorrent_clien...](https://en.wikipedia.org/wiki/Transmission_\(BitTorrent_client\)#Website_breach)

~~~
IshKebab
Indeed. [https://xkcd.com/1200/](https://xkcd.com/1200/)

~~~
orblivion
Seems this comic gives the opposite evaluation from your parent post.

~~~
IshKebab
Yes it was a sardonic "indeed".

------
saagarjha
Actual bug report: [https://bugs.chromium.org/p/project-
zero/issues/detail?id=17...](https://bugs.chromium.org/p/project-
zero/issues/detail?id=1726)

------
KingMachiavelli
I'm trying to figure out what the expected behavior (and fix) should be.
Basically the bug is that a external process could posion a processes version
of a file by silently manipulating the file and causeing the file to be
reread.

Given the requirements that a secondary process should even be able to modify
a file that is already open, I guess the expected behavior is that the 1st
process's version should remain cached in memory while allowing the on-disk
(CoW) version to be updated? While also informing the 1st process of the
update and allowing the 1st process to reload/reopen the file if it chooses to
do so. If this is the intended/expected behavior, then it follows that
pwrite() and other syscalls should inform the kernel and cause prevent the
origional cache from being flushed.

~~~
mgoetzke
Still don't understand it though. If the bad code is already able to alter the
files on disk is it really make a difference whether the data was altered
before or after the using code had mapped it into its memory ? Either the file
is changed before the process starts, in which case it already gets bad data,
or it is altered after in which case it only sees it after experiencing memory
pressure.

Wouldn't the issue be the change on disk in the first place ?

~~~
Crespyl
Reading the bug report it sounds like it has more to do with the Copy-on-Write
behavior.

If I've understood correctly, I think it works something like this:

A privileged process needs to use some shared-object/library, and the OS loads
that file into memory for it.

An unprivileged process creates an exact duplicate of the library file and
asks the OS to load _that_ into memory. This triggers the copy-on-write system
to realize that these are identical, and creates a link between them so that
both processes are using the same chunk of memory.

The privileged process then doesn't actually use the library for a while, so
the OS pages it out of memory, while keeping that copy-on-write link around.

This is where the sneaky/buggy part lies, in that it's possible for the
unprivileged process to modify its version of the library file without the
copy-on-write system being informed of the write (and thus separating the two
diverging copies). This is apparently related to some details of how mounting
filesystem images works.

The next time the privileged process tries to use the library, the OS sees
that it has already been paged out, but hey here's this copy-on-write link
pointing at this "identical" version over here, and loads the poisoned version
into the privileged process.

~~~
mgoetzke
Thanks for this info. Yeah, this kind of scenario is unacceptable. I did not
see that the files are single instanced in memory. Is the overhead for this
even worth it ? Two files being loaded that are exactly identical sharing the
same ram space (writable too) sounds like overhead for no usable gain. I guess
when you are compressing ram anyways they might calculate checksums anyway and
thus have the info to coalesce chunks, but it sounds like a really bad choice.

------
freedomben
> _The researcher informed Apple about the flaw back in November 2018, but the
> company is yet to fix it even after exceeding the 90-day deadline, which is
> why the bug is now being made public with a "high severity" label._

Are they giving any reasons for the delay?

~~~
chii
The reason doesn't matter. I can't think of one reason for which the delay in
patching justifies not following the 90 day policy.

~~~
rincebrain
What if it's something nasty like Spectre, where you're coordinating at least
getting some mitigations across multiple ecosystems, and disclosing the
vulnerabilities (particularly, say, the Meltdown fun, or NetSpectre) without
available mitigation could be disastrous?

90d seems like sufficient time for many processes, particularly if you're used
to iterating in somewhat flexible or always-releasable environments, but as
soon as you start involving multiple systems with different timetables, the
time requirements to meet everyone's process needs can balloon, particularly
if it's something requiring substantial changes (and thus, substantial
testing).

(I'm in favor of the default 90d disclosure policy, just wanted to point out
that there are sometimes legitimate justifications for longer timelines.)

(Work for elgooG, not on anything remotely related to GPZ, opinions my own,
etc.)

~~~
jve
> What if it's something nasty like Spectre

Exceptional case. Deadline WAS extended. Reported 01. Jun 2017, Disclosed Jan
2018

[https://bugs.chromium.org/p/project-
zero/issues/detail?id=12...](https://bugs.chromium.org/p/project-
zero/issues/detail?id=1272)

~~~
kps
Here is the list of (fixed, public) cases where the deadline was extended
(sorted by vendor):

[https://bugs.chromium.org/p/project-
zero/issues/list?can=1&q...](https://bugs.chromium.org/p/project-
zero/issues/list?can=1&q=label:Deadline-
Grace&sort=vendor&colspec=ID%20Reported%20Vendor%20Product%20Summary)

and here is the list bugs where the deadline expired:

[https://bugs.chromium.org/p/project-
zero/issues/list?can=1&q...](https://bugs.chromium.org/p/project-
zero/issues/list?can=1&q=label:Deadline-
Exceeded&sort=vendor&colspec=ID%20Status%20Reported%20Vendor%20Product%20Summary)

------
detaro
Link should probably be updated to point to project zero itself:
[https://bugs.chromium.org/p/project-
zero/issues/detail?id=17...](https://bugs.chromium.org/p/project-
zero/issues/detail?id=1726&q=)

------
mroche
The comments on the page are fun if you have a few minutes.

Say what you want about Google, but groups like Project Zero and Talos from
Cisco are awesome. The things they find...

------
skizm
I wonder what would be cheaper for Google, et al.: paying lots of engineers to
bug hunt all day, or simply going out and buying a bunch or all of the high
profile bugs from shady websites and then just publishing them.

~~~
rocqua
I wouldn't be surprised if the value in project zero is mostly in training the
engineers to find these vulnerabilities.

------
masswerk
Does this apply to files on an HD or SDD as well or is this specific to
mounted images only?

(Meaning, is this about CoW in general or about memory management related to
mounted images?)

~~~
ryanpetrich
This applies to copy-on-write of files on mounted disk images only.

------
peter_d_sherman
A must-read for future OS designers...

------
campercoder
Also a high severity flaw with this freaking butterfly keyboard. Please let
the world know Google.

~~~
saagarjha
This is completely unrelated. Please don't use threads like these as a way to
voice your complaints about Macs in general when doing so isn't relevant.

------
samgranieri
oy

------
paulcarroty
90 days policy is fine. If you can fix the problem, this time will be enough
to hire an entire team.

~~~
chrisseaton
> 90 days policy is fine. If you can fix the problem, this time will be enough
> to hire an entire team.

Is 90 days enough to fully fix for example spectre and meltdown? I'm not sure
all bugs can be fixed in 90 days. Some will take decades to resolve.

~~~
ox_cable
Spectre is a special case and I think you know it's a special case. Cut it
out.

~~~
chrisseaton
Why's it not a valid counter-example? It's a special case because it doesn't
fit the 90 day estimate? Well yeah that's why it's a counter-example.

~~~
joshuamorton
Because at it's core, it's a hardware design flaw, not a software bug.

Also it affected multiple vendors, not one, so coordination across a minimum
of 10 major organizations (google, apple, MS, Amazon, Intel, amd, Linux, etc.)
breaks the normal assumptions behind project 0.

Given those issues, different rules make sense. It's not a normal case where a
single vendor has a flaw that can be fixed with a single patch.

------
Thermolabile
In past I thought that MacOS didn't have bugs, how I was wrong...

~~~
andrewnicolalde
I assume you're joking.

------
dontbenebby
Is there a compelling reason this is being released prior to a patch going
out?

~~~
hylianwarrior
Literally the second sentence: "Its members locate flaws in software,
privately report them to the manufacturers, and give them 90 days to resolve
the problem before publicly disclosing it."

Privately disclosed to Apple, 90 days later they published. Simple as that.

~~~
rixrax
I used to think that 90 days is quite unfair. And in many ways it can be. But
it’s a great equalizer. And that way no one company can claim that some other
company got preferential treatment. And everyone by now knows that that’s what
it’s going to be. Instead of p0 team having to have a fruitless back and forth
with vendors about the impact and what would be a reasonable timeline for
disclosure.

~~~
rat9988
90 days is equality but not equity. Not all bugs can be fixed in the same way.
Moreover, 90 days seems arbitrary to me, unless there was some prior study
behind this number.

~~~
saagarjha
It’s just a number that Google Project Zero has decided is what they’re going
to hold companies to.

~~~
zepto
‘Holding them to’ makes it sound like Google has some kind of moral authority
here.

I understand the positive incentives for publishing when companies do not
respond to flaws.

However Google has no particular right to police other companies.

If they disclose at 90 days, and harm ensues, there is no defense. Google is
responsible.

~~~
henryfjordan
Google has the responsibility to inform users that the software they are using
has known vulnerabilities as much as they have a responsibility to disclose
them quietly to the software vendors that can fix them.

The way you laid things out, Google should just collect zero-days and sit on
them? Do you see the absurdity of that? From a business perspective, having
these vulnerabilities around makes it easer for their competitors to collect
the same kinds of data about internet search and private emails from people
around the internet that Google collects from legit means. Getting
vulnerabilities fixes widens Google's data moat.

Disclosing issues is not "policing". They are not arresting people, or taking
any action other than stating the truth, that some software is vulnerable.

If they disclose at 90 days and harm ensues, the user bears responsibility for
continuing to use the software. If they trust the software vendor to issue
timely updates, then they can turn around and lay blame at the vendor for not
fixing the issue. Or they can blame the hacker.

