Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
It seems odd, how can this contribute to performance and security, opening up the flood gates?

Does encryption / performance and security have to be mutually exclusive ?

No flood gates were open.
Yes. Encryption and security are mutually exclusive to performance. When you have more of the former, it costs the latter. In fact, Apple explicitly states this in their iOS security overview.
 
  • Like
Reactions: ckoerner
A smooth move by our grateful leader Apple?

The "hoarding" of vulnerabilities - as the article describes - is due to Apple not paying bug bounties.
Absolutely no reason to praise Apple for this move now.

Apple's is a cheapskate - and it's definetly not improving under the lead of Tim Cook.
They're your leader, eh? ..And I suppose by your deduction that kidnappers should always get their ransom too?

Color me confused, but it sounded to me like they just set millions of their own developers the task of helping strengthen the stability and security of the system, which would be a benefit to anyone who owns one of their devices.

You say cheapskate, I say neighborhood watch. I suppose you have never volunteered for your local community either.
 
Damage control.

oh for gods sake...

the kernel cache unencrypted improves performance... apple watch runs same kernel.... watch now holding live apps. But sure... an automated process apple has had for a bazillion years forgot to enable signing the kernel cache. Lets go with that.
 
But sure... an automated process apple has had for a bazillion years forgot to enable signing the kernel cache. Lets go with that.

Anyone who's ever done automated builds knows full well that (especially if a newbie comes in and edits the script) mistakes can and will happen.

I'm not suggesting that's what happened here. Just saying it cannot be dismissed as improbable.

Cheers!
 
  • Like
Reactions: decafjava
It's rare that the NSA or FBI pay 1 Million dollars for a single exploit. It would need to be incredible. Most of the time they pay less than $100,000 but more than $25,000 for what is known as zero day exploits.

If however you developed the holy grail. An exploit that starts simply by someone visiting a web page and escalates to total system ownership without a user being able to notice anything and it beats antivirus heuristic detection you could be looking at a million dollars.

Apple could offer $100,000 to a Million dollars for these kinds of exploits they're practically printing money. But I would suggest instead they start small. Offer $5,000-$15,000 for the first 6 months then double it. This way they get the most amount of exploits reported for the lowest sums of cash. The harder to find stuff will appear once the money offered equals the work spent finding them. So I'm not suggesting they jump right into offering 100K or 1 Million, that wouldn't make good business sense.
[doublepost=1466684468][/doublepost]

Usually there are bugs in the kernel which you cannot see because the encryption makes it difficult to do so. You cannot dump the kernel while the system is running due to ASLR and other in-memory protection techniques built into the operating system.

By having it decrypted you can copy the kernel from the phone and decompile it so you can examine it and search for potential buffer overflows and other exploitable bugs. There is still quite a lot to be learned from the kernel as they keep changing it and changes introduce bugs.

The whole reason they've decrypted it is so researchers can potentially find these bugs more easily. Encryption is security by obfuscation which means the kernel isn't really secure, its flaws are simply masked/hidden from attackers. The only attacks possible when it was encrypted were fuzzing attacks (supplying the many kernel functions with data trying to randomly find a bug as opposed to reading the kernels decompiled assembly to search for one)

Also keep in mind this isn't like decrypting a password, the data set is so large and the encryption cipher potentially 4096+ bit that it would take a billion years to unencrypt it even with the fastest supercomputer on the planet. Hackers who are "just that good" still can't do the impossible and I say that as someone that develops secure server software that deals in encrypted communications everyday.

Thank you for this explanation. I thought decryption would make it easier to research and find potential security vulnerabilities and such -- but didn't know enough to be certain. Your post explains the why and HOW this is useful to researchers.
 
It's rare that the NSA or FBI pay 1 Million dollars for a single exploit. It would need to be incredible. Most of the time they pay less than $100,000 but more than $25,000 for what is known as zero day exploits.

If however you developed the holy grail. An exploit that starts simply by someone visiting a web page and escalates to total system ownership without a user being able to notice anything and it beats antivirus heuristic detection you could be looking at a million dollars.

Apple could offer $100,000 to a Million dollars for these kinds of exploits they're practically printing money. But I would suggest instead they start small. Offer $5,000-$15,000 for the first 6 months then double it. This way they get the most amount of exploits reported for the lowest sums of cash. The harder to find stuff will appear once the money offered equals the work spent finding them. So I'm not suggesting they jump right into offering 100K or 1 Million, that wouldn't make good business sense.
[doublepost=1466684468][/doublepost]

Usually there are bugs in the kernel which you cannot see because the encryption makes it difficult to do so. You cannot dump the kernel while the system is running due to ASLR and other in-memory protection techniques built into the operating system.

By having it decrypted you can copy the kernel from the phone and decompile it so you can examine it and search for potential buffer overflows and other exploitable bugs. There is still quite a lot to be learned from the kernel as they keep changing it and changes introduce bugs.

The whole reason they've decrypted it is so researchers can potentially find these bugs more easily. Encryption is security by obfuscation which means the kernel isn't really secure, its flaws are simply masked/hidden from attackers. The only attacks possible when it was encrypted were fuzzing attacks (supplying the many kernel functions with data trying to randomly find a bug as opposed to reading the kernels decompiled assembly to search for one)

Also keep in mind this isn't like decrypting a password, the data set is so large and the encryption cipher potentially 4096+ bit that it would take a billion years to unencrypt it even with the fastest supercomputer on the planet. Hackers who are "just that good" still can't do the impossible and I say that as someone that develops secure server software that deals in encrypted communications everyday.

Ok, I'm learning here. I would have thought that there is zero code out there that is running on a computer that cannot be read in some form or fashion. If it needs to executed at some point it would need to be unencrypted. So the concept of any code being secure that is running on a personal system is kind of a joke. That being said, the issue is whether you can replace or amend that code and repackage it and then install it on another system.

I dont think you can. Am I wrong?

I'm coming from the position that Apple really wouldnt be stupid enough to allow a situation where fake version of iOS or macOS with compromised kernel's can be installed on iphones and mac's. Is that possible now?
 
Ok, I'm learning here. I would have thought that there is zero code out there that is running on a computer that cannot be read in some form or fashion. If it needs to executed at some point it would need to be unencrypted. So the concept of any code being secure that is running on a personal system is kind of a joke. That being said, the issue is whether you can replace or amend that code and repackage it and then install it on another system.

I dont think you can. Am I wrong?

I'm coming from the position that Apple really wouldnt be stupid enough to allow a situation where fake version of iOS or macOS with compromised kernel's can be installed on iphones and mac's. Is that possible now?

ASLR makes it difficult to view the kernel while running in memory. It randomises all the memory addresses every time the kernel does anything and it is stored randomly in memory itself. Getting a dump of the kernel unencrypted before now wasn't yet possible, no known exploits so far.

What Apple has done gives researchers a big leg up.

So to be clear, before it was loaded into memory it was encrypted. So simply reading the kernel from the phones flash memory was not yielding anything useful. Taking the kernel from memory where it was protected by ASLR (Address Space Layout Randomisation) also made it not possible.

But now that it's decrypted you can dump it from the phone (once getting root access) and examine it in a decompiler. That doesn't mean you could take the kernel and make your own macOS or iOS distro. The kernel still relies on signed code to execute its many functions. It simply wouldn't work with your frameworks and apps as they don't carry Apple's digital signature.
 
Last edited:
I highly doubt un encrypting those ~12 MB files will noticeably increase performance. The way I see it is Apple unintentionally forget to encrypt it.

"Fast Life, live dangerously, no time for encryption. This is our most exciting release ever."
 
ASLR makes it difficult to view the kernel while running in memory. It randomises all the memory addresses every time the kernel does anything and it is stored randomly in memory itself. Getting a dump of the kernel unencrypted before now wasn't yet possible, no known exploits so far.

What Apple has done gives researchers a big leg up.

So to be clear, before it was loaded into memory it was encrypted. So simply reading the kernel from the phones flash memory was not yielding anything useful. Taking the kernel from memory where it was protected by ASLR (Address Space Layout Randomisation) also made it not possible.

But now that it's decrypted you can dump it from the phone (once getting root access) and examine it in a decompiler. That doesn't mean you could take the kernel and make your own macOS or iOS distro. The kernel still relies on signed code to execute its many functions. It simply wouldn't work with your frameworks and apps as they don't carry Apple's digital signature.

ok. Thanks for that.
 



Yesterday it was discovered that iOS 10 does not feature an encrypted kernel, allowing users and researchers access to the core of the operating system and its inner workings. It was unclear at the time whether the lack of encryption was an accident or intentional, but today Apple confirmed to TechCrunch that the company did not encrypt the kernel for a reason.

ios10.jpg

The kernel, which dictates how software can use hardware and keeps the device secure, is unencrypted so that developers and researchers can "poke around" and find potential security flaws. Because the kernel is easier to access and flaws may be easier to find, Apple can more easily and more quickly patch potential issues.

The move is a shift for Apple, who had encrypted the kernel in past versions of iOS, leaving developers and researchers out of the loop on the inner workings of the operating system. As noted by security expert Jonathan Zdziarski, it's likely that Apple has made this shift to prevent groups from "hoarding" vulnerabilities in Apple's software, like the vulnerability used by the FBI to break into the iPhone 5c of the San Bernardino shooter.

Article Link: Apple Confirms Unencrypted Kernel in iOS 10 Beta is Intentional

Slightly off-topic (or is it?): Apple claims that iOS 10 will use up less space than iOS 9.x, but after installing it on my 16GB iPhone 6, I went from 5.4 to a little over 4GB of free space...

Bottomline: either Apple is lying, or if not, well, is very optimistic about the space required by iOS 10, or it forgot to clean up after itself upon install.

Have you guys also noted that loss in free space?
 
Yep, total garbage. Some background deal w/ the feds or something if this makes it to release version. There's no reason to un-encrypt something when, apparently, there was a reason to do so before. The performance gains are most likely minimal. If Apple is touting encryption/privacy everywhere, this is a very strange, shady move.

Well you gotta love bean counter TC for cost savings;

- Kernel is unencrypted so now anybody can "poke around" and find security flaws.

-> APPL stock to the moon!
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.