That article does not seem much better. They say the "code" has been exposed. I assume they mean machine code, not source code, but they don't specify. "Code" generally means source which is confusing.
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/).
For iOS developers -- Does this present any feature opportunities for you, or has Apple locked down access to the kernel in such a way as this is purely a security/research opportunity?
For developers who want to put their apps in the official App Store, this doesn't really help anything. It's definitely interesting, but only on an academic level.
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.
I might be very stupid but can someone tell me if it's something common in FOSS operating systems to have unencrypted kernel, or is this really something unique and potentially very risky?
(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?
The article is phrased in such a way as to make Apple look good. They're not releasing source code, they're just not encrypting the binary image any more, which basically makes them the same as everybody else in that respect.
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.
What is unclear to me is where the kernel is encrypted? I assume the kernel is encrypted in the download bundle, and during the iOS update the device decrypts the binaries. So, this is simply an unencrypted kernel lib in the download bundle allowing for analysis?
From what I understand, it is rather obscured then "encrypted". I'm not sure about Assembly but most higher level languages leave function and variable names in the binary. There are many programs that rename the variables and function to something random so you will have a hard time what each function does. Mojang did that for their Minecraft game but developers soon found out what each method does and strated renaming them back to something useful – this is how Mod or Plugins are available.
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).
Perhaps I'm misunderstanding, but the article claims the "code" is unencrypted, and that seems a little misleading. Apple hasn't encrypted the binary, but they're not really shipping the source, right?
Well you already have the symbols; what else would your app be linking against?
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.
I'm sure this will please the jailbreak community much.
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.
>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.
Alternatively, they just decided to encrypt everything, maybe in case there was some sort of user data in the kernel cache. Now that they have a better idea of things, they can be selective.
Wait a minute! If your security only relies on your code not being known, that is the screwup, not the other way around! Technology Review should know better than to potentially disseminate such a harmful notion.
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.
You don't necessarily need to reverse engineer the whole thing. If you're just looking to bypass a particular check then sometimes it's enough to dig around until you find something relevant, then find references to the memory location. There are tools that can make this easier.
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.
A particular type of "bypassing a check" is the goal of jailbreaking—and it's just redone for every update. People with the right motivation can do crazy things.
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.
>You don't necessarily need to reverse engineer the whole thing. If you're just looking to bypass a particular check
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.
39 comments
[ 3.0 ms ] story [ 84.9 ms ] threadhttps://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/).
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.
(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.
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.
[1]: http://iphonedevwiki.net/index.php/Dyld_shared_cache
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.
>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...)
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.