5 ms·

Apple leaves iOS 10 kernel unencrypted in developer preview

85 points by laktak 10y ago

josho 10y ago
This 9to5 article is a bad summary of the original. Follow this thread instead, https://news.ycombinator.com/item?id=11953204 https://news.ycombinator.com/item?id=11953204
- alblue 10y ago
  The linked thread has no comments, whereas this has three. In fact the only useful link is the one it points to, which to save people's time is https://www.technologyreview.com/s/601748/apple-opens-up-iphone-code-in-what-could-be-savvy-strategy-or-security-screwup/ https://www.technologyreview.com/s/601748/apple-opens-up-iph...
- kr7 10y ago
  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/ http://opensource.apple.com/source/xnu/).
- sctb 10y ago
  We merged that thread with this one, and updated the link from http://9to5mac.com/2016/06/22/ios-10-kernel-unencrypted/ http://9to5mac.com/2016/06/22/ios-10-kernel-unencrypted/, which pointed to this.
Dangeranger 10y ago
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?
- collias 10y ago
  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.
- ff10 10y ago
  The boundaries of the app sandbox remain unaffected afaik. This might be more interesting to Jailbreak developers.
Twisell 10y ago
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?
- yarrel 10y ago
  Free software operating systems don't tend to encrypt resources against their users. If the users want to encrypt them that's another matter. If the Linux kernel was encrypted, you'd expect the (root) user to be able to unencrypt it.
- jlarocco 10y ago
  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.
DigitalJack 10y ago
If it's a mistake, it's a fortuitous one, and I hope Apple rolls with it. In fact, with that pile of cash that Apple has, they could institute a bug bounty that governments would be hardpressed to compete with.
josho 10y ago
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?
- kr7 10y ago
  From what I understand the kernel is decrypted by the firmware at boot time.
- informatimago 10y ago
  It doesn't need to be encrypted, but SIGNED.
- Matt3o12_ 10y ago
  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).
jlarocco 10y ago
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?
- Titanous 10y ago
  Correct, the executable code is unencrypted, the source code has not been released.
  - xxr 10y ago
    Does this mean that all the NSWhatever symbols are visible to anyone with a debugger or readelf or whatnot?
    - umanwizard 10y ago
      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. [1]: http://iphonedevwiki.net/index.php/Dyld_shared_cache http://iphonedevwiki.net/index.php/Dyld_shared_cache
      - asksol 10y ago
        Edit: Ignorance is bliss
        umanwizard 10y ago
        You're thinking of debugging symbols -- the commenter I replied to mentioned symbols in general. Linkers rely on names and addresses; more precisely, name->address mappings.
forgottenpass 10y ago
The word "Kremlinology" comes to mind.
- deleted 10y ago
  [deleted]
- mikeash 10y ago
  Indeed, and that term has been applied to Apple for at least eight years, although I think it might be even older: http://daringfireball.net/2008/01/macworld_expo_prelude http://daringfireball.net/2008/01/macworld_expo_prelude
mkhalil 10y ago
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.
rmateu 10y ago
Probably the best informed reason: >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-unencrypted http://www.imore.com/heres-why-ios-10-kernel-cache-unencrypt...)
- mikeash 10y ago
  That would seem to imply that previous iOS versions put user data in the kernel cache. Why would that be?
  - oddevan 10y ago
    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.
stcredzero 10y ago
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.
- nathantotten 10y ago
  That's not how this works. That's not how any of this works.
  - danlindley 10y ago
    What are you referring to, exactly? Security by obscurity does have caveats, but I'm not sure precisely what the issue you're raising is?
valarauca1 10y ago
This is clickbait. 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.
- actsasbuffoon 10y ago
  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.
  - justaman 10y ago
    You would never even keep up with the updates.
    - derefr 10y ago
      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.
      - valarauca1 10y ago

85 points by laktak 10y ago

josho 10y ago

This 9to5 article is a bad summary of the original. Follow this thread instead, https://news.ycombinator.com/item?id=11953204 https://news.ycombinator.com/item?id=11953204

alblue 10y ago
The linked thread has no comments, whereas this has three. In fact the only useful link is the one it points to, which to save people's time is https://www.technologyreview.com/s/601748/apple-opens-up-iphone-code-in-what-could-be-savvy-strategy-or-security-screwup/ https://www.technologyreview.com/s/601748/apple-opens-up-iph...
kr7 10y ago
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/ http://opensource.apple.com/source/xnu/).
sctb 10y ago
We merged that thread with this one, and updated the link from http://9to5mac.com/2016/06/22/ios-10-kernel-unencrypted/ http://9to5mac.com/2016/06/22/ios-10-kernel-unencrypted/, which pointed to this.

Dangeranger 10y ago

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?

collias 10y ago
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.
ff10 10y ago
The boundaries of the app sandbox remain unaffected afaik. This might be more interesting to Jailbreak developers.

Twisell 10y ago

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?

yarrel 10y ago
Free software operating systems don't tend to encrypt resources against their users. If the users want to encrypt them that's another matter. If the Linux kernel was encrypted, you'd expect the (root) user to be able to unencrypt it.
jlarocco 10y ago
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.

DigitalJack 10y ago

If it's a mistake, it's a fortuitous one, and I hope Apple rolls with it. In fact, with that pile of cash that Apple has, they could institute a bug bounty that governments would be hardpressed to compete with.

josho 10y ago

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?

kr7 10y ago
From what I understand the kernel is decrypted by the firmware at boot time.
informatimago 10y ago
It doesn't need to be encrypted, but SIGNED.
Matt3o12_ 10y ago
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).

jlarocco 10y ago

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?

Titanous 10y ago
Correct, the executable code is unencrypted, the source code has not been released.
- xxr 10y ago
  Does this mean that all the NSWhatever symbols are visible to anyone with a debugger or readelf or whatnot?
  - umanwizard 10y ago
    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. [1]: http://iphonedevwiki.net/index.php/Dyld_shared_cache http://iphonedevwiki.net/index.php/Dyld_shared_cache
    - asksol 10y ago
      Edit: Ignorance is bliss
      - umanwizard 10y ago
        You're thinking of debugging symbols -- the commenter I replied to mentioned symbols in general. Linkers rely on names and addresses; more precisely, name->address mappings.

forgottenpass 10y ago

The word "Kremlinology" comes to mind.

deleted 10y ago
[deleted]
mikeash 10y ago
Indeed, and that term has been applied to Apple for at least eight years, although I think it might be even older: http://daringfireball.net/2008/01/macworld_expo_prelude http://daringfireball.net/2008/01/macworld_expo_prelude

mkhalil 10y ago

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.

rmateu 10y ago

Probably the best informed reason: >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-unencrypted http://www.imore.com/heres-why-ios-10-kernel-cache-unencrypt...)

mikeash 10y ago
That would seem to imply that previous iOS versions put user data in the kernel cache. Why would that be?
- oddevan 10y ago
  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.

stcredzero 10y ago

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.

nathantotten 10y ago
That's not how this works. That's not how any of this works.
- danlindley 10y ago
  What are you referring to, exactly? Security by obscurity does have caveats, but I'm not sure precisely what the issue you're raising is?

valarauca1 10y ago

This is clickbait. 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.

actsasbuffoon 10y ago
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.
- justaman 10y ago
  You would never even keep up with the updates.
  - derefr 10y ago
    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.
    - valarauca1 10y ago