
Apple's Failure to Check Kill Syscall Privilege “Not a Security Issue” - KirinDave
https://lists.apple.com/archives/darwin-dev/2017/Oct/msg00006.html
======
neom
[http://www.openwall.com/lists/oss-
security/2017/10/12/2](http://www.openwall.com/lists/oss-
security/2017/10/12/2)

"-> We have not reserved a CVE for this issue as Apple is a CNA and does not >
see it as a security issue. >

And here's my main teachable moment.

If a CVE Numbering Authority (CNA) does not grant a CVE to an issue (whether
it be due to "not a bug" or non responsiveness or whatever) there is a simple
process to deal with this. You go to the CNA's parent, a list of CNA's is
currently at:

[https://cve.mitre.org/cve/cna.html](https://cve.mitre.org/cve/cna.html)

in general most current CNA's have MITRE as their parent (we're working on a
federated hierarchy but we're in the early stages), so using the form:

[https://cveform.mitre.org/](https://cveform.mitre.org/)

to request a CVE would be your next step. For the Open Source Distributed
Weakness Filing (DWF) hierarchy each CNA and sub CNA is registered at:

[https://github.com/distributedweaknessfiling/DWF-CNA-
Registr...](https://github.com/distributedweaknessfiling/DWF-CNA-
Registry/tree/master/CNA-Registry)

so essentially you go to the parent and keep working your way up until either
you are satisfied, or you hit MITRE and they tell you to take a hike, or give
you a CVE.

Speaking of which if you are an Open Source project and want to be a CNA,
polease contact me and chances are I can set you up in a pretty quick
timeframe (faster than I assign CVEs because creating a CNA is a much better
ROI of my time than issuing a CVE). ."

\- via>" Kurt Seifried -- Red Hat -- Product Security -- Cloud"

~~~
cryptonector
This is against the rules. You're supposed to file CVEs with the most-specific
CNA only.

~~~
dgellow
Why? Genuine question, I'm not familiar with the CVE process.

~~~
cryptonector
Because they want the most specific authority to evaluate the report -- you
know, the ones who would know how to.

Yes, this allows CNAs to say "not our problem" and now you have a problem, but
going to Mitre is not the answer. Pushing back is the answer.

------
fjarlq
The quoted statement, "not a security issue", doesn't appear in the linked
page, but via the Thread Prev link[1] I found Daniel Peebles explaining:

> _Yes, we did try with them first and they told us they didn’t consider it a
> security issue, so we posted to oss-security after making sure Apple
> understood we’d do that unless they asked us not to._

[1]: [https://lists.apple.com/archives/darwin-
dev/2017/Oct/msg0000...](https://lists.apple.com/archives/darwin-
dev/2017/Oct/msg00005.html)

------
saurik
Maybe-interesting contextual note: Daniel Peebles was one of the people
involved at the beginning of iPhone jailbreaking.

~~~
Terretta
He was just trying to get it to run Nix.

~~~
saurik
I remember him beginning his work on Nix after his involvement in iPhone
jailbreaking, but I might have not paid enough attention to the beginning of
the Nix project.

~~~
Terretta
Ha, I was kidding but it wouldn’t have been implausible.

Another if you know him: “He was just trying to make iOS more functional.”

------
eridius
Is Apple wrong here? I mean, this is obviously a bad thing that should be
fixed, but ultimately it amounts to a DoS against the machine and does not
grant any privileges or expose any data to the attacker. I can see why Apple
might say it's not a "security" issue.

~~~
williamscales
It seems to me that it's in the same category as a fork bomb - a neat trick
requiring local access that will crash a machine. Deeming it a non-security
bug seems entirely reasonable. As you say it

 _does not grant any privileges or expose any data to the attacker._

So the bug cannot really be exploited to compromise security except in a case
where someone has gone to extraordinary lengths to keep even a local user from
crashing the machine.

~~~
kbenson
> So the bug cannot really be exploited to compromise security

Do we really need to get into the discussion of how many times someone thought
a bug wasn't a security problem or was unfeasible to use in an exploit in
practice o ly to be proven wrong later as new techniques came about and were
applied to the original problem?

The unknown unknowns are the problem here, and they are as their name
suggests, hard to nail down.

Race conditions are a thing. My bet is a determined and smart hacker could
find a way to weaponize this within a week _at most_.

~~~
eridius
Just because a lot of bugs were thought hard/impossible to exploit and were
later proven wrong does not mean every single bug is possible to exploit. Most
software bugs are not exploitable. You just generally read about the ones that
are.

~~~
kbenson
I'm not just making a general statement about all bugs, but also a specific
statement about how I think this bug could play out. Not only does it kill all
processes under the user, but it also crashes the entire system. Both of those
are interesting bugs, and have possible implications if you can cause them in
interesting situations.

Can you cause some system process that happens to share the user with another,
more interesting process to run a kill syscall?

Can you cause the system to crash while some more trusted process is in the
middle of updating a configuration, password, or other data structure that
will cause interesting effects after the system is restarted?

Both being able to cause other user processes to die, and to cause the system
crash on demand as a user, are things I would consider _individually_ as
security problems just because they have a high probability of having
unforeseen consequences. Having them together doubles the attack space (even
if it does possibly create some problems with following through with a second
action).

~~~
eridius
Killing all processes under the user is the _expected behavior_ of kill(-1).
That's perfectly fine. Crashing the system is the bug part.

From the manpage:

    
    
         If pid is -1:
                 If the user has super-user privileges, the signal is sent to all
                 processes excluding system processes and the process sending the
                 signal.  If the user is not the super user, the signal is sent to
                 all processes with the same uid as the user, excluding the
                 process sending the signal.  No error is returned if any process
                 could be signaled.

~~~
kbenson
Fair enough, I really should have caught that. I guess it's been longer than I
thought since I had to deal with that stuff. :/

It doesn't change the point I was trying to make much though.

------
rnhmjoj
Previus discussion here:
[https://news.ycombinator.com/item?id=15846713](https://news.ycombinator.com/item?id=15846713)

Looks like it has been fixed in macOS 10.13.2 anyway.

------
sabujp
TIL that apple uses a mac CI infrastructure where they clean up processes and
don't do a full teardown / rebooot or VM revert to snapshot, hah

~~~
mitchty
Nix is not apples tool. It is a package manager.

[https://nixos.org/nix/](https://nixos.org/nix/)

------
bgduke10
classic example of leaders in tech failing to check their privilege

