
Apple leaves iOS 10 kernel unencrypted in developer preview - laktak
https://www.technologyreview.com/s/601748/apple-opens-up-iphone-code-in-what-could-be-savvy-strategy-or-security-screwup/
======
valarauca1
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
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
You would never even keep up with the updates.

~~~
derefr
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
This is a false comparison.

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.

~~~
sjtgraham
Jailbreaking does involve kernel patching and AppStore apps run as the mobile
user, not root.

~~~
valarauca1
Ah very sorry. I shouldn't have commented on something out of my depth. TIL

------
rmateu
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-
unencrypt...](http://www.imore.com/heres-why-ios-10-kernel-cache-unencrypted))

~~~
mikeash
That would seem to imply that previous iOS versions put user data in the
kernel cache. Why would that be?

~~~
oddevan
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.

------
DigitalJack
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
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?

~~~
Matt3o12_
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
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
Correct, the executable code is unencrypted, the source code has not been
released.

~~~
xxr
Does this mean that all the NSWhatever symbols are visible to anyone with a
debugger or readelf or whatnot?

~~~
umanwizard
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
Edit: Ignorance is bliss

~~~
umanwizard
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.

------
mkhalil
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.

------
forgottenpass
The word "Kremlinology" comes to mind.

~~~
mikeash
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)

------
Dangeranger
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
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.

------
josho
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
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-
iph...](https://www.technologyreview.com/s/601748/apple-opens-up-iphone-code-
in-what-could-be-savvy-strategy-or-security-screwup/)

------
Twisell
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?

~~~
jlarocco
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.

------
stcredzero
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
That's not how this works. That's not how any of this works.

~~~
danlindley
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?

