[jjarmoc]

While this is a significant vulnerability, I don't think the article is correct when it calls it a 'backdoor.' The term backdoor typically implies something that was intentionally left to allow illicit access, and while this is a significant bug, I don't see anything to indicate that's the case here.

[jdmichal]

This is a hole that exists because an Apple-written application needed a method to gain elevated access. This was done through unpublished APIs which, when used by another application in a similar way, also resulted in elevated access.

So, this was clearly intentional, because it's used by Apple directly. And it allows illicit access, because any program can use it to gain access.

[3JPLW]

I'm not so sure. Unless I'm missing something, he doesn't demonstrate that this 'backdoor' is in use. It looks like they were using an escalation backdoor in `systemsetup`, but quickly patched a fix after 10.8.5. He just found a way around it.

Now, the fact that 'it takes too much effort' to backport would suggest that it was still in use. I don't see any other evidence, though. I'd be interested if someone found it!

[jdmichal]

This seems to be the path followed:

systemsetup pointed to the Admin framework.

Admin framework analysis revealed use of "createFileWithContents". The function in which this use occurs is not named in the analysis.

An error message in the initial proof attempt led to "authenticateUsingAuthorization". Back to systemsetup to determine how to use "authenticateUsingAuthorization". (This is where I ended up mentally relinking the issue back to systemsetup.)

So, I concede that is is not stated where within the Admin framework this "createFileWithContents" method is invoked. However, I also agree that if that function was not used, it would be simple to remove it and the issue would be fixed.

[f3llowtraveler]

There's no way to tell for sure if something like this is intentional or not. Also, waiting to fix it until a researcher makes it public may have been intentional.

[jjarmoc]

> There's no way to tell for sure if something like this is intentional or not.

Right, so the simplest explanation is that it's an unintentional bug. The absence of evidence that it was unintentional isn't evidence that it was intentional. If there were some magic string or default password or something, that'd be an obvious backdoor, but to me this looks like a pretty typical privesc bug, albeit in an undocumented api.

It was found through a chain of events that started with looking at the patch related to another privilege escalation vulnerability, one which no one seems to be claiming was a backdoor.

> Also, waiting to fix it until a researcher makes it public may have been intentional.

I'm guessing it's more likely the the researcher waiting to go public until it was fixed.

This is evidenced both by the fact that it was patched alongside other vulns (ie. not a rushed out one-off patch) and from the article's disclosure timeline, which shows 'Full disclosure' occurring 04/09, while the 'Release of OS X 10.10.3' occurred 04/08. This is a pretty typical disclosure timeline; they couldn't begin to fix it until it was tracked as a bug, after all.

[Animats]

There's no way to tell for sure if something like this is intentional or not.

Yes, there is. Sue Apple for willful negligence and subpoena the development logs.

[__david__]

Sigh. No practical way…

[arielby]

A function named "createFileWithContents" is clearly intentional - through its creator probably just hadn't realised the security implication, making this a negligent, rather than malicious, backdoor, not unlike default router passwords.