Hacker News Reader

Comment by AdmiralAsshat | Hacker News Reader

I suppose this is the only way to definitively stop any three-letter agencies from asking you to backdoor your kernel.

Also, all you need is one insider kernel developer to get all the source code anyways. I always find these kinds of initiatives silly -- A lot of companies think that an insider is a side-channel attack when really it's the main vector.

Also, given enough money available, why ask people to build vulnerabilities in ? Does anyone seriously think Apple's (or anyone's) kernel team doesn't have a single guy/girl that made at least one mistake ?

And Apple, as well as Microsoft, Intel, and other companies have already voluntarily agreed to give the NSA and other agencies "early notice" of a vulnerability which can be exploited by the time it's fixed anyway. CISA also pretty much mandated it into law as well.

Of course there are bugs, but they are hugely expensive to find.

Also, all you need is one insider kernel developer to get all the source code anyways.

You mean this source code? http://opensource.apple.com/source/xnu/

That is, unfortunately, by no means "all the source code" of the kernel-level code that is running on your Mac, iPhone, iPad, iPod, Apple TV, or Apple Watch.

Yah, I've had this discussion numerous times. Especially with regard to hiring people from a competitor. Often you wonder how much information is traveling via unintentional side channels (not just employees that are also on the payroll of a 3 letter agency).

OTOH, there does seem to be a fair amount of competence where it matters though. In the couple companies I worked for the private keys used for signing things were very quietly kept hidden from the vast majority of the engineering teams/etc. AKA, it was possible to create an development/test builds all day long, but creating valid license keys/firmware updates/etc for the builds given to customers was limited to a formal process which contained the keys. The private keys were only available to a couple people tasked with maintaining the automation from which the builds/keys/etc came from. Those people rarely had a need to move/etc them either, and such activities were done in the open.

Or perhaps the three-letter-agencies demanded they do such a backdoor (i.e. a deliberate but obscure security hole), so they are open-sourcing it so hackers can find it.

Nitpick: they are not open-sourcing it; they are just leaving the compiled binary unencrypted.

The OS X and iOS kernel are descendants of the nextStep kernel which is open source.

http://en.wikipedia.org/wiki/XNU

Right, but how much code does the last open-source xnu have in common with the latest?

Apple continues to open source their version of XNU, although there has been an increasing lag between the release of each OS version and the corresponding sources. The latest available sources are from 10.11.2, three minor versions behind.

Apple has also shifted to pushing a lot of sensitive/proprietary code into kernel extensions (the new Apple File System being one example), for which they don't release source code (generally speaking).

Filesystems, by and large, are supposed to be pushed into the kernel (via extension, or direct compilation). I'd hardly say that they've "shifted" into pushing code into their kernel, but that much of what differentiates Apple's XNU kernel vs FreeBSD's Kernel or Linux is what they choose the exclude.

I believe the grandparent post is referring to the fact that HFS+ is available in the open source release of xnu [1] while the question of whether Apple will open source APFS kext, especially given their recent trend of moving functionality from xnu into closed source kexts.

I think it would be smart for them to open source it, if not simply for the interoperability use cases.

[1]: http://opensource.apple.com//source/xnu/xnu-2050.18.24/bsd/h...

Yep. So far, they've committed to publishing "the APFS volume format" [1]. It'll be interesting if they fold it back (into the kernel proper) as part of making APFS bootable.

[1] https://developer.apple.com/library/prerelease/content/docum...

Sorry, I wasn't totally clear. I was talking about shifting functionality _from_the_kernel_ into kernel extensions, not functionality from user space.

And there are non-trivial bits of OS X which are open sourced http://opensource.apple.com/release/os-x-10112/

I know that. But who knows how much secret sauce they have in the iOS build?

Also, even on OS X, it takes a while after new versions of the OS are released for new kernel source bundles to drop. So sometimes poking around with IDA is your only recourse.

A non-trivial amount of the iOS platform has been rev-eng'd (incidentally, largely with IDA and those kernel sources to create binaries with intact symbols + binary comparison heuristics[1]). XNU is largely based on FreeBSD so I'd be surprised if that wasn't an additional vehicle people were using (In a similar vein, fail0verflow used the syscode table information from FreeBSD with WebKit and ROPgadgets to fully compromise the PS3.)

RE: this specific exploit, here's the POC making it around the security sphere (thanks @heisecode!) https://github.com/heisecode/Bug_POCs

[1] https://static.googleusercontent.com/media/www.zynamics.com/...

XNU != BSD.

XNU == MACH + BSD Personality.

I get down voted for sharing some knowledge. What is the point of even posting?

Early downvotes often get corrected and are probably worth ignoring. They might even be accidental votes from phone users, so don't sweat it.

It's definitely not -- or shouldn't be, at least -- fake Internet points.

That's an interesting point of view that I hadn't considered before. Apple (or any company) doesn't have infinite eyeballs and can't possibly inspect every nuance to their systems. So, you release it to the world and have them surface any issues. If there are no trade secrets and everyone is honest and reliable, then it is a great way to increase your security footprint. :)

Reply on news.ycombinator.com