
Google discloses three severe vulnerabilities in Apple OS X - bhauer
http://www.cnet.com/news/google-team-finds-three-severe-vulnerabilities-in-apple-os-x/
======
cheald
Tech journalists insisting on calling these "zero-days" (which, to its credit,
CNet changed, though Ars and ZDNet are guilty of it) is really kind of
irritating.

A zero-day is, by definition, an exploit that the vendor has had zero days to
react to. It's not just an unpatched vulnerability with a proof of concept
exploit available for it.

Apple has been aware of these issues since October.

~~~
gojomo
As a term, it's prone to confusion. Many use 'zero-day' to refer to
vulnerabilities that are publicly-known before a patch is available. That is,
the figurative 'zero day' counter starts from public disclosure, not
disclosure-to-vendor.

Because bugs can't be fixed in zero time, and most readers are interested in
the practical matter of whether there is a window of unpatched widespread
vulnerability, this public-disclosure-focused definition may in fact be more
useful.

~~~
cheald
> vulnerabilities that are publicly-known before a patch is available

We already have a term for that, though: "unpatched vulnerabilities". Using
the term "zero-day" erroneously communicates to the reader that Google
surprised Apple et al with this thing out of the blue, and just handed
crackers the tools to start exploiting it without giving Apple time to develop
countermeasures.

~~~
gojomo
Indeed, but it was also an 'unpatched vulnerability' for the last 90 days.
And, it was even plausibly an 'unpatched vulnerability' before it was
discovered!

What's special about today, with an exploit being widely-known but no patch
available? That's the new situation people are grasping for a term to
describe.

'Zero-day' somewhat fits, at least from the perspective of everyone outside
Apple: OSX users and those potentially attacking them. It's a brand-new green-
field risk/attack for them!

It's also somewhat problematic, for the reasons you list and others. There may
be a better term yet to be discovered, that maintains the special distinction
for vulnerabilities that the vendor only learns about simultaneous with
exploit-availability. But still a lot of people use and understand the term to
apply to the window-of-danger from unpatched "Project Zero" 90-day reveals.

------
geofft
How is it possible in 2015 that major kernels are vulnerable to arbitrary code
execution via null pointer dereference?

Leave aside memory safety, input validation, actually caring about the quality
of your work, whatever. mmap_min_addr stopped a ton of attacks back in like
2007-10 when Linux had a local privilege escalation-of-the-month (and RHEL,
which hadn't enabled it yet for backwards-compatibility concerns, got hit more
frequently). It's not a particularly aesthetically-pleasing solution, but it's
an effective one.

Are there legacy apps on OS X that require mapping the zero page? Executable?
That Apple cares about supporting?

I've run into two things on Linux that need to map the zero page: versions of
MIT Scheme from before 2009 (because the compiler was doing something super
weird), and Wine, when running certain DOS / Windows 3.1 apps. Anything of
that era probably stopped working on OS X when they killed _Classic_. Even
Carbon has been dead for three years.

[https://wiki.debian.org/mmap_min_addr](https://wiki.debian.org/mmap_min_addr)

[https://access.redhat.com/articles/20484](https://access.redhat.com/articles/20484)

~~~
Animats
_How is it possible in 2015 that major kernels are vulnerable to arbitrary
code execution via null pointer dereference?_

Because they're monolithic, bloated, and written in C.

(Rust guys, please don't screw up. We need a win there.)

~~~
danieldk
> (Rust guys, please don't screw up. We need a win there.)

While it's true that Rust would help here, it is very unlikely that a Rust
kernel project would get as far as e.g. Linux and let alone replace it.

Of course, rewriting and existing kernel stepwise would be interesting, if
possible.

~~~
runeks
> Of course, rewriting and existing kernel stepwise would be interesting, if
> possible.

Perhaps it's possible to write a new kernel in Rust, and have it be backwards
compatible with Linux, by "wrapping" the Linux kernel and drivers in
sandboxes?

So a Rust kernel with some kind of built-in environment isolation, in which it
can run the real Linux kernel. The running Linux kernel would then access
physical hardware through a wrapper in the Rust kernel, while the Rust kernel
would access hardware directly.

That's really the only way I see this project gaining widespread adoption: by
leveraging Linux. Linux simply has too much momentum to be replaced with
something non-compatible.

Of course, a Rust kernel could be useful for all kinds of things other than
replacing Linux. Like a Mirage OS-type kernel that uses Rust to write drivers
in Rust (instead of OCaml).

~~~
icebraining
Wouldn't that essentially be an hypervisor written in Rust?

~~~
Animats
That's what I'm thinking. Take a look at
[http://spin.atomicobject.com/2014/09/27/reimagining-
operatin...](http://spin.atomicobject.com/2014/09/27/reimagining-operating-
systems/)

for an overview of what's going on in this area. If you're running containers
on a hypervisor, with files on storage servers elsewhere, most of the Linux
kernel is dead weight. Most of the kernel can be replaced by a modest glue
library. Here's one, written in OCaml:
[http://anil.recoil.org/papers/2013-asplos-
mirage.pdf](http://anil.recoil.org/papers/2013-asplos-mirage.pdf)

As containers catch on, we'll see more systems specialized to run nothing but
containers. They will be much simpler than Linux or Windows. System
administration will be external, as it is for cloud systems like Amazon AWS
now.

------
FireBeyond
I will be curious, as a litmus test, to see how perception of this varies in
the community to the Microsoft release.

That was a mixed bag - with support on both sides of the aisles, some decrying
Patch Tuesday, some in support.

What will happen here? Will Google be lauded for consistency, or castigated
for not "working more closely" with Apple (for varying definitions of "working
closely", up to and including potentially delaying disclosure around arbitrary
timelines)?

~~~
cheald
I'm wholly in support of Google here. Apple has a history of letting known
vulnerabilities persist for _years_ (ie,
[http://krebsonsecurity.com/2011/11/apple-took-3-years-to-
fix...](http://krebsonsecurity.com/2011/11/apple-took-3-years-to-fix-
finfisher-trojan-hole/)) without fixes.

~~~
dzhiurgis
Google is exploiting MS and Apple update release processes.

Both were published days before update schedule.

~~~
FireBeyond
That's an interesting counterpoint, and one I hadn't considered. Definitely
worthy of note (especially when you combine it with the 'zero Android
vulnerabilities found' \- which isn't to imply it's an actively nefarious
project, but that everything should be taken with an objective eye).

------
IBM
It's fixed in the latest beta.

[http://www.imore.com/latest-os-x-10102-beta-kills-google-
dis...](http://www.imore.com/latest-os-x-10102-beta-kills-google-disclosed-
vulnerabilities-dead)

------
BigChiefSmokem
I have a serious question.

I understand the benefit of this program to the public, but what real benefit
does funding Project Zero Day provide Google?

~~~
notatoad
Google's ads are so pervasive that they make money for just about every minute
you use the internet. If your computer is infested with viruses you might turn
it off and go outside, therefore it's in Google's best interests to invest in
general computer security.

~~~
BigChiefSmokem
I understand the ad thing but that idea applies to all software companies
(because they want their own browsers and operating systems used by users),
not just Google.

To me it feels like they're throwing their competitors under the bus in this
way as opposed to running slander campaigns or witty commercials like Samsung,
Microsoft, and Apple do. I'm not saying this is their intention but that is
the way it comes off and it cannot be good for their reputation.

A non-profit organization funded by the entire tech industry would have more
credibility.

~~~
giovannibajo1
They would fix any doubt if they began releasing bugs and exploits for Android
as well.

~~~
notatoad
Better that they fix their own vulnerabilities than release them.

They do offer a bug bounty for their own products, to encourage third parties
to do to them exactly what they're doing to Apple and Microsoft.

~~~
timonovici
It's not like they sit around and say: "Oh, f*ck Android, let's find
vulnerabilities in other operating systems." I suppose it's long since they
have a team working on Android vulnerabilities, but it's not trivial fixing,
deploying - not to mention finding the flaws.

~~~
fidotron
When it comes to others they have total disregard as to how difficult to
deploy any fix is. The same standard should apply to themselves, but clearly
doesn't.

------
franciscop
Sidenote: please do not publish re-posts, reference the original source
whenever possible: [http://www.zdnet.com/article/googles-project-zero-reveals-
th...](http://www.zdnet.com/article/googles-project-zero-reveals-three-apple-
os-x-zero-day-vulnerabilities/)

------
glasshead969
Looks like the latest 10.10.2 beta has them fixed. Users with access to public
beta program should see the update.

[http://www.imore.com/latest-os-x-10102-beta-kills-google-
dis...](http://www.imore.com/latest-os-x-10102-beta-kills-google-disclosed-
vulnerabilities-dead)

------
uniformlyrandom
> Google's Project Zero security team revealed the existence this week of
> three vulnerabilities with high severity that have yet to be fixed in
> Apple's OS X operating system.

I feel like somebody is trying to execute some kind of buffer overflow attack
against my brain.

------
cyphunk
Is it 0day or is it not. "0day" is not an important word except that the media
has started using it. For those of us working in the field, it's just a fun
term, not a legal term. It is used to distinguish the risk of a bug, not the
ethical handling of it. It has always been in relation to risk. The risk is
greatest when it is a. unknown to anyone but a few b. unknown by a wide enough
audience to effect its application c. unfixable or as yet unpatched. Some in
the field call bugs fitting any one of these qualification 0days, other's not.
But nearly no one in the field uses this term to quantify the ethical handling
of a bug (as in: age starting from moment vendor knows about bug).

Consider what a 1day is. A "1day" bug is one that looses value because it is
likely that some systems have now been patched such that you as an attacker
are not guaranteed that _every_ system you touch with your exploit will fall.
A 365day is likely useless, depending on the target platform. Hence, the
entirety of its meaning has to do with risk, not procedure or ethics.

It is fine if you read Wikipedia's definition and decide the meaning is
otherwise. After all, language changes. But if anyone in the future wants to
understand the etymology of the meaning behind "0day" they should consider
that the meaning appears to have changed (in the minds of many that actually
don't even work in the field of reverse engineering).

------
olssy
From what I can tell one of the exploits allows for code execution with root
privileges, another for accessing kernel-space memory and the third will crash
the machine. Are any of these things not already doable when someone has
physical access to the machine?

~~~
cheald
They aren't remote code execution exploits as best as I can tell. But, it's a
short leap from an exploitable root escalation to total compromise of a
machine. Until these are patched, any executable you download and run could
potentially be a dropper for much nastier stuff. You could combine one of
these with the recently-disclosed Flash exploits, for example, and you have a
drive-by root exploit ready for deployment via ad networks to millions of
people.

------
mc32
Does anyone know if they only research os and os environment bugs or also
cisco juniper os bugs as well for example?

~~~
xaqfox
I also wonder if they publish proof of concepts for security bugs they refuse
to fix (e.g. in Android 4.3).

~~~
giovannibajo1
They said they also investigate on Android, but they haven't yet published a
single vulnerability for it, as far as I can tell.

~~~
ikonst
Right on their blog, though it's a guest post but they don't seem to have
anything against it:
[http://googleprojectzero.blogspot.com/2015/01/exploiting-
nvm...](http://googleprojectzero.blogspot.com/2015/01/exploiting-nvmap-to-
escape-chrome.html)

~~~
giovannibajo1
Yes, it's a guest post. What I said is that, while in theory they said they
will research all major OSs (including Android, which is by far the most
common mobile OS), they have yet to publish a single vulnerability as a result
of their research.

~~~
patrickaljord
Maybe they do publish them but they are all fixed before the 90 windows passes
so they don't have to be disclosed their. You still go to git.chromium.org and
aosp's git see the daily security/improvement patches that go there.

~~~
giovannibajo1
The disclosure window is typically for fixes released to end-users, not just
fixed by vendors. This is also what was enforced with MS last round, where
they had a fix ready but couldn't get it to pass QA and being released before
the 90-days window expired.

------
bluthru
I don't get why Apple wouldn't be motivated to fix this ASAP for their own
safety.

~~~
alwillis
It’s coming soon and is already available to testers:
[http://www.imore.com/latest-os-x-10102-beta-kills-google-
dis...](http://www.imore.com/latest-os-x-10102-beta-kills-google-disclosed-
vulnerabilities-dead)

------
pronoiac
Does anyone know how far back the bugs go? Mavericks, Snow Leopard?

------
Pinn2
I have a huge ego and like more money. Is HackerOne the best way to feed both?

------
pbreit
I'm assuming they communicate these privately to the vulnerable party prior to
publicizing?

~~~
iancarroll
They gave them 90 days to publish a fix.

~~~
sigzero
And that fix in the latest beta. So it is coming.

