Apple leaves iOS 10 kernel unencrypted in developer preview
technologyreview.com
technologyreview.com
The kernel binary is unecrypted. So potentially you can disassemble it. But this isn't huge news. The windows kernel binary is unencrypted, so are most closed source software binaries.
Furthermore Apple releases the Darwin/XNU kernel sources as OSS so you even have the source already if you wanted.
Shipping an unecrypted binary isn't really considered a security threat. The amount of time and effort involved in tracing those thousands of jump/call instructions can be automated, but looking for memory issues really can't as you have to have intimate knowledge of how all the assembly is interacting with each other, and a very good understand of the platform its executing on.
RE'ing a full user land program is considered a herculean task. RE'ing an OS binary would be herculean even for a large team of skilled reverse engineers.
Or so I've heard. Surely no one here has ever done anything of the sort.
Still, you're right about the scale of the problem. It's time consuming to find the relevant bit to start building on, even on relatively small binaries. I don't even want to think about how long it would take on an entire OS.
Jail-breaking is just a privilege escalation. You were a $USER, now you are $ROOT. This is just tricking the kernel. Fundamentally the kernel is just doing what it was programmed to do, you were just clever.
What the hack being suggested here would require is re-writing entire parts of the kernel from OUTSIDE of it. Injecting your new code INTO the kernel. Tricking your CPU into executing that code as Ring-0 (the kernel). Then having what ever you do INSIDE ring-0 not bring the whole house of cards crashing down in the process. As you fiddle with raw memory locations/address to grab what ever you were looking for.
Yes you can just find the right memory address, start grepping for those lines of ASM and have an RE tool find the related assembly functions. And you design a payload to by-pass these checks.
Now how do you use this?
Well if it's running you'd need a K-Space arbitrary execution vuln to inject your hostile code.
If you want to build your own kernel binary, now you need to forge a cryptographic signature.
Neither of these are non-trivial problems. They're actually EXTREMELY difficult problems.
>Surely no one here has ever done anything of the sort.
I'm not saying this isn't _ever_ done. It's within the realm of Nation-State adversaries. But if your threat-model includes the USA/Russian Federation/People Republic of China there's already a laundry list of reason you shouldn't be using iOS or really any smart phone period.
>Streamlining the operating system.
>Since it contains only the kernel, device drivers, and configuration files — and absolutely no user data — the iOS 10 kernel cache can be left unencrypted without any concerns over security or privacy.
[Here's why the iOS 10 kernel cache is unencrypted | iMore](http://www.imore.com/heres-why-ios-10-kernel-cache-unencrypt...)
In fact, with that pile of cash that Apple has, they could institute a bug bounty that governments would be hardpressed to compete with.
If apple did that with their kernel, then I'd say it is pretty bad security practice. A dedicated "hacker" can always understand what each function does with good confidence, it is just a pain in the neck and most volunteers don't wanna put up with that (while a state sponsored team may very well do that).
Security through obscurity is always bad and only scares away people who could help while leaving many true bad actors with just more, painful work. If apple did indeed just obscured their kernel, I think apple did that intentionally to have people besides the FBI/NSA look at their code (they have been more and more concerned with security in recent years).
If you mean the functions themselves, not the symbols -- those are in the dyld cache[1], not the kernel. It's unclear from this article how easy it will be to dump the dyld cache in iOS 10.
Linkers rely on names and addresses; more precisely, name->address mappings.
If this was purposeful, which I highly am confident was, this was a good move by Apple. Make it easier to find and report bugs. When everything is encrypted, only the most resourceful can find the exploits, and for the resources they put into it, they most likely not going to just give it away for free or a small bug bounty.
On the whole, the iOS ecosystem is pretty locked down. If you submit an app to the App Store, and there's some bit of code that Apple doesn't like, they can and will reject your submission. You can only have an app in the App Store if you play by the rules.
https://www.technologyreview.com/s/601748/apple-opens-up-iph...
They speculate that Apple is opening up the kernel so people can report bugs, but if that was the case they would release the source, which they have not (although the Mac kernel is FOSS and the two share large amounts of code: http://opensource.apple.com/source/xnu/).
(ND: I know macOS is far from FOSS, but it's just to have a comparison point. Shouldn't FOSS kernel be open by definition?
If the Linux kernel was encrypted, you'd expect the (root) user to be able to unencrypt it.
Encrypting the kernel image was an attempt to prevent jailbreaking and hide security vulnerabilities, and as far as I know, nobody else ships an encrypted kernel image because those reasons don't make sense on most other platforms.