Slashdot Mirror
Apple Says iOS Kernel Cache Left Unencrypted Intentionally, Nothing To Worry About (loopinsight.com)
The iOS 10 kernel, which Apple released to enthusiasts last week, is not encrypted, according to a report. Security experts expressed their surprise and puzzlement over this in a report by MIT News. The iPhone maker, after remaining tight-lipped over the matter for a week, has now offered an explanation. In a statement to The Loop, Apple said: The kernel cache doesn't contain any user info, and by unencrypting it we're able to optimize the operating system's performance without compromising security.It is worth mentioning that Apple is talking about kernel's cache, whereas MIT News' original report talks about kernel code.
How is it possible that manishs doesn't know the difference between code and cache?
BSD-based is still more secure than the Windows kernel. In fairness though some folks probably enjoy ransomware.
Like smacking your hand with a hammer then stopping, it feels so good after making that bitcoin payment and getting your precious Office docs back.
So there seems to be some difference over assertions here.
Apple is only talking about the iOS 10 kernel CACHE and that private data is never stored there (fair enough), whereas TFA is talking about the kernel code which is left open to exploitation.
I personally consider that opening the kernel is a wise move. It will, most likely, assist in closing holes in the code and, eventually, would make a stronger kernel. However, as the article suggests, it was probably a mistake...
This comment was written with the intention to opt out of advertising.
It's a feature. Now look at the shiny phone!
Since you used ALL CAPS and "swear" words you clearly must be authoritative on the subject.
Our pervasive snooping through our customers' habits and information taught us that they do notice when the phone is slow, but they don't have a clue about security or consider their privacy in any way important.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Canary Warrant. The Government got to them in spite of the public display of resisting.You can be anyone who was relying on Apple phones to keep secrets will use other means now. Doh.As for the claim that kernel cache doesn't contain user data (and bear in mind this took a week of "consideration", and I'm not a security expert), wouldn't it be possible to extrude data from the kernal cache that could lead to the ability to access other encrypted data? seems odd to encrypt it and then remove that encryption, especially given the timing. I could be wrong but I think Apple is giving a half truth. why take a week for a response to a question they had to know others would ask?
"Imagination is more important than knowledge" - Einstein
You are wrong. To prove otherwise please upload your custom Intel microcode update.
They are right up there with people who don't know the difference between 'to' and 'too'. They're the worst.
There is no story here.
I thought the encryption key was securely stored in the iPhone hardware and can only be accessed by firmware running on that hardware which then decrypts the kernel.
That's actually not how it works. The decryption key is burned into the processor, that is why there is a different firmware image for different versions of the phone. Only some of the phone versions (older ones) have had their keys extracted and released. Also, with new technologies like SGX (shipped in some current desktop CPUs and soon phones) software publishers will be able to write code that can only be decrypted in the hardware's trusted enclave, so the key can never be observed. So stop yelling please when you don't know what you're talking about.
The Linux Kernel: NOT ENCRYPTED. Go panic now, the world is ending.
In fact, do you know that Linus Torvalds has personally made it possible for the MUTHAFUCKIN NSA to read every single line of source code in the Linux Kernel??
Just think about that the next time "they" tell you that it's OK for your computer to SEND IT'S DAMN IP ADDRESS OUT TO THE INTERNET!
The black helicopters are coming for me man!!
AntiFA: An abbreviation for Anti First Amendment.
Not saying the guy is right, but how does a custom intel microcode update prove anything about a custom iphone kernel?
this was an oversight. Probably heads will roll...
Is the new iOS running on Apple's new filesystem? Supposedly part of the features of the new filesystem is that it has greater control over file encryption. Given this explanation, it may be that they previously encrypted the kernel because it was the best way to encrypt user data, whereas with a new filesystem they may be able to encrypt the files they want to encrypt without needing to encrypt anything else.
Just a shot in the dark, though.
NSA: Ease it out folks or else we will eat into your Irish shortcuts.
Apple:It is already easy and open.
Case closed.
Excessive, pointless use of all-caps: a clear sign of autism.
Yes, you have the decryption key, but not the encryption key. Before you read on, try and guess what I'm getting at; then read on to see if you were right.
--
It is possible to modify an unencrypted binary, pad it so the checksums match, and get it onto the device, either by slipping that binary back into the original update blob or by desoldering the NVRAM from the phone, flashing it, and soldering it back in. The various TLAs you types are always worried about can do either of those.
Just thought you might like to know. Would you like some tinfoil, now?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
It's bitztream, the annoying, screaming, autism-hating Slashdot troll!
From what I understand the kernel was obfuscated before and not encrypted. When you obfuscate machine code you usually have to execute more instructions per actual instruction. So this is probably just a move to free resources, as security trough obscurity isn't really that good anyways.
The decryption key is burned into the processor
How do they pull that off for the emulator?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
You may have had a point, but I stopped reading at the first very unnecessary F-bomb.
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
heh, thats cute. Not done much embedded work have you?
I have. With those processors specifically. Extracting the encryption key is non-trivial but documented if you know where to look (not the processor documentation mind you (OH FACE)
I assure you that anyone who actually knew what they were doing can easily 'decrypt' the code and nothing you've said changes what I've said, other than you think that because they've embedded it in prom on the CPU that its secure. Just because its a custom chip apple laided out doesn't mean its magically doing things that no one else figured out how to break years ago.
You may not be able to change the key, but you most certainly can extract it.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Umm, no you couldn't read it at any time at least on 64-bit devices. The decryption keys are generated on the device by hardware which is disabled before user land starts. So without being able to hijack the boot process or have some super fancy hardware reversing capability you can't get to the keys.
There is a known exploit for the boot loader on 32 bit devices and people have used that to retrieve keys for those. Such a thing may exist for 64 bit, but it is kept very hush hush if so, and nobody is publicly posting 64bit keys.
The only other way to get a decrypted kernel is to have a kernel exploit that enables arbitrary kernel memory read, at which point you can just dump out the kernel. Even then there are chunks that aren't needed at run time that are jettisoned, so you don't get the entire thing (like symbols).
So no it's not that easy to do.
*Their the wurst.
FTFY, since your an idiot.
Because it's a Simulator not an emulator. It's a special version of the OS compiled for x86.
The key is burned into the processor, but you can employ the key in the processor to decrypt it. Just as the boot code decrypts the kernel cache, you can use the hardware to decrypt it for your own nefarious ends.
It just means you have to do the decryption on the device.
So the original writer was correct in that this encryption didn't stop all observers, just casual ones. Anyone who could get a significant jailbreak on a device could decrypt the kernel caches.
http://lkml.org/lkml/2005/8/20/95
OMG WHY DO YOU SCREAM ALL THE TIME YOU FUCKING JACKASS FUCKTARD DICKHEAD
OMG why do you fucking scream all the time you fucking jackass fucktard dickhead!
OMG! WHY DO YOU SCREAM ALL THE TIME YOU FUCKING JACKASS FUCKTARD DICKHEAD
Since your A idiot
FTFY.
It's here, it's bitztream, the autism-hating Slashdot troll!
No, you're wrong. And you have serious mommy issues, see a shrink.
They are right up there with people who don't know the difference between 'to' and 'too'. They're the worst.
Damn right, I hate those people to.
Then please explain to me why there are tons of models of the phone that don't have their keys extracted yet. They are specifically designed to not have the key leave the enclave. Why don't you go ahead and do it then since you're some kind of expert and it's so easy? The jailbreak community would appreciate it. Or just keep talking out of your ass on Slashdot.
So you're saying that version isn't encrypted? Or that it's encrypted but the key is readily accessible by disassembling the simulator code? Or... what, exactly, are you saying? Is the kernel in the x86 version encrypted or not?
You're focusing your argument on the wrong point.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
AES is symmetrical. The kernelcache is encrypted using AES. You're describing a hash collision on a signature. You're ignorant of the topic being discussed, please stop posting with such a confident posture.
Usually the firmwares are checked with a cryptographic hash though, so it is not as simple as just fiddling with it a bit to make the checksum match. It should be (nearly) impossible to make changes to the binary without them being detected.
Eh? Jailbreak, disable the code that disabled the hardware keygen, done. Yes, this has been done; it's a bit beyond me how to actually pull it off, mostly because I haven't looked into it because I don't care (don't have an iPhone), but it's been done.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Apple is not a gay corp. It's a corp with a gay CEO. Get it right.
Do you have documentation you can point me to stating that AES is being used? Given that the user is literally handed the key, that would be an idiotic choice. I don't think Apple necessarily has the best and brightest engineers, but they also don't employ idiots.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Yes, the firmware is checked during an upgrade; it is not verified during the boot process as this would take too long (the flash used doesn't read that fast). Te is definitely open to a physical attack (desolder/flash/resolder) during which the install-time hash check can also be disabled, allowing the attacker to push their own updates remotely. As for the "nearly" impossible, yes, for you or I it likely is; for someone with a government budget for computing power, perhaps not so much.
I'm gonna go ahead and call an end to this conversation before the tinfoil hatters come out of the woodwork.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
That is interesting, I didn't know that it wasn't checked during boot. That seems like a bad idea. As to whether or not some people can break cryptographic hashes, I would lean toward not. It is not a matter of computing power, but some theoretic break on the algorithm itself. And a lot of really smart people in academia have been looking at, for instance, SHA-2 for over 15 years now with no substantial attacks.
This security document from Apple implies that every stage of the boot process does a complete verification on the next stage before booting continues, first the Low Level Bootloader, then iBoot and finally the iOS kernel. So you could mess with the userland stuff but not the kernel. If you think about it, the whole boot chain including the kernel is probably only 10 MB or less. That is not so burdensome to verify every boot.
Whoops forgot to put the URL https://www.apple.com/business...
It's not a matter of breaking the hash, simply finding a collision. Whenever what you're hashing is larger than your hash, there will always be collisions.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Which security document? You seem to have not linked to anything. But yes, it's verified by attempting to decrypt; if decryption fails, it's been tampered with. The encryption was removed from the kernel, ergo the kernel can no longer be verified.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Yes there will always be collisions, in fact infinitely many, but it is computationally infeasible to find them. To date there have never been found two inputs that create the same hash in SHA-2. Since the output is 256 bits, you would have to try about 2^128 inputs in expectation before you find one, which is quite a few. You would need something like 10^20 times more storage than exists on the whole planet.
Each step of the startup process contains components that are cryptographically signed by Apple to ensure integrity and that proceed only after verifying the chain of trust. This includes the bootloaders, kernel, kernel extensions, and baseband firmware. When an iOS device is turned on, its application processor immediately executes code from read-only memory known as the Boot ROM. This immutable code, known as the hardware root of trust, is laid down during chip fabrication, and is implicitly trusted.
The Boot ROM code contains the Apple Root CA public key, which is used to verify that the Low-Level Bootloader (LLB) is signed by Apple before allowing it to load. This is the first step in the chain of trust where each step ensures that the next is signed by Apple. When the LLB finishes its tasks, it verifies and runs the next-stage bootloader, iBoot, which in turn verifies and runs the iOS kernel.
I stand corrected, the binary decrypting properly was merely a secondary protection. The primary protection is the signature, which is made much weaker by the removal of the encryption, as the binary no longer has to both be signed properly and be able to be decrypted with the public key. If you think there's not a datacenter in Utah with the compute power to "solve" this in a matter of hours (maybe days), you're mistaken.
Also, thank you for providing that document, hopefully DamnOregonian sees and reads it. AES. Laughable.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
I'm pretty positive there isn't, or else if there is we have much bigger problems than our iPhones. Literally all of internet security relies on hash functions. If they are broken then we might as well just give up.
Also, testing if something is "able to be decrypted" implicitly relies on a hash because how else do you know if what you decrypted is valid? If you use something simple like a checksum or padding to check, it actually leads to an attack that can be used to decrypt the file called a padding oracle attack https://en.wikipedia.org/wiki/...
"That is the good thing about standards,
there are so many to choose from."
Wait, you mean it's not gay to kiss the ass of a gay man?
I don't think the simulator is a full x86 version of iOS. It provides a user land that you can test apps in but I don't think it has a real kernel. IIRC it actually calls down into the Mac OS X kernel when it needs system services. it's basically a sandbox that pretends to be iOS.
Since the output is 256 bits, you would have to try about 2^128 inputs in expectation before you find one
Or one lucky guess. Or double that and you still haven't found one. Don't oversimplify for my sake, I do understand these things, you can speak to me as a peer.
You would need something like 10^20 times more storage than exists on the whole planet.
Perhaps, if you were storing all of your test inputs. However, you can just as easily programmatically generate them and only store the ones that match.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
You can't do that with a modern jailbreak. To disable that code you have to have your jailbreak hijack control in the BootRom or the boot loader. The last public jailbreak that had that capability died with the iPhone 4s.
There is a researcher named iH8sn0w who has a jailbreak for the 4s through 5c, but he only shares with a small handful of people. He does upload keys from time to time though.
There are no known jailbreaks for 64bit devices that offer that capability. It's likely that they exist but no one has admitted to it, and it's certainly not available for anyone to download.
All jailbreaks in recent years get you kernel privileges, but that's not enough to disable the boot chain of trust.
Nice argumentum per viam modum. Here's a reference (thanks to cryptizard for providing that) in case you need it. No, AES is not used; AES does not have a public and private key (as you stated, it's symmetric) and Apple specifically states the existence of a public key, which implies a separate private key.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
There are substantial differences in utility between arbitrary collisions and useful ones. See preimage attacks and collision attacks. HTH. -PCP
As much as I dislike Apple, they are not wrong here. What's the point of encrypting *code*?! Sign it, check sum it - yes, by all means, so that it's not replaced by something malicious. But why would you need to hide the actual content of the code?! Haven't we learned that security by obscurity doesn't work?
Probably no less gay than kissing the ass of a straight guy
Interesting that they'd do that; seems it'd introduce a fair bit of inconsistency in how things work between the simulator and the real device. An ideal solution would execute the same code in the same way at the same speed; an acceptable tradeoff would be one that executed the same code in the same way, with speed constraints based on the actual hardware being used. Anything that causes the same code to execute differently in the simulator vs the real device is, IMO, a bug.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
I never said anything about disabling the chain of trust, I referenced disabling the code that disables the hardware keygen, the piece of hardware that allows system binaries to be decrypted, actually quite the opposite. Since that is done by a command issued by the kernel during boot, before userland components are loaded, it certainly can be skipped.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
(6, GUARANTEED)
It's not the kernel that turns it off. It's the boot loader, iBoot. By the time the kernel gets control its off. So you have to hijack iBoot or earlier.
But even if it was the kernel you couldn't stop it. The kernel is encrypted and signed, so You would have to be able to decrypt the kernel, modify its code, then reencrypt and sign with Apples private key. Otherwise iBoot will tell you to fuck off.
Emulation of an arm CPU is slow and cannot be done as fast as the iPhone CPU is.
So xcode makes a x86 binary of your application so that it actually fast (probably faster than your iPhone).
Since iOS and macOS are basically the same operating system underneath, with basically just another GUI library. The simulation of an iPhone on a Mac is pretty accurate.
You may also be interesting to know that your application is now released on the App Store as LLVM's Intermediate Code. The App Store will build optimised binaries for every different iPhone/iPad CPU (different ARMs for now, but they could even change to Intel). So you already are not developing for a consistant platform.
Understood; however, there is no reason it cannot run as a VM with its own kernel and resources. My point wasn't at all related to the underlying architecture, just the software that runs on it.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
The kernel loads several kernel-mode drivers, which are encrypted and signed, requiring this hardware to still be available for a short while after the kernel takes control. Doing otherwise would open the device to kernel-level vulnerabilities injected by modified drivers, which would be a gold-mine for jailbreakers.
Also of note: the very article we're discussing happens to be about the kernel no longer being encrypted so, no, you don't need to re-encrypt it, you're left with the (still difficult, but much easier) task of making your modified binary match the checksum and hash of the original.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
I love how you assume I'm speaking from a position of ignorance. Look at my posting history and you'll learn that I tend not to do that; and when someone does manage to teach me something I thank them for doing so.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
So, the last slashdot headline specifically said that "Nobody knows why".
Clearly, Apple fucking knew why all along.
What the fuck, Slashdot? Quit it with misleading clickbait.
The kernel does not load the drivers: they are already pre linked together, which is why it's called a kernel cache. IBoot decrypts the entire kernelcache, drivers and all, and loads it into memory. OS X has the same capability but the kernelcache can be updated there unlike iOS.
The kernel does do some initialization of the drivers, like calling constructors and updating symbol tables to account for ASLR, but it doesn't have to decrypt and load them. As for whether iBoot would load a modified kernel that isn't encrypted... That's a good question. Since iBoot still is encrypted we don't know if it's doing any new validation. It was possible to find iBoot still hanging around in physical memory on iOS 8, but that doesn't appear to be the case in iOS 9 and above.... It's erased before user land is started. but if they used a strong hash and require the size of the hashed image to be the same it would be almost impossible to find a collision of the same size that was also a fully working kernel.
The dynamic linker does this as well in user land. All of the shared libraries that come with the system are linked together into a giant half gig blob that gets mapped into memory in one go, then the kernel just adds a mapping for this blob to each process. That way all libraries only have to be loaded one time.
Huh, interesting. Learn something every day...
Also, and I'm not sure why I didn't think of this earlier, it's not necessary to load a modified kernel with the same hash; it would be much easier to move the kernel and replace it with a binary that loads the kernel, patches it in RAM, then hands off execution. The binary itself would be small, leaving plenty of "slack" which can be modified as needed to match the hashes, while allowing the file size to remain constant.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
AES is (well, was prior to most recent beta referenced in TFA) in fact used.
I need not read the reference, as I'm intimately familiar with the boot process.
My guess is that you read "signature" in there and something about a cert, and assumed that actually applied to the encryption used on the kernel binary itself rather than the signature for it.
A signature must necessarily be asymmetric so that someone can decrypt it without being able to encrypt a new signature.
This concept exists in regular SSL as well. One need not encrypt an entire certificate with trusted information in it, only the signature.
The kernel is *still* protected by the asymmetrically encrypted signature in the new versions of iOS, it simply isn't encrypted anymore.
That is to say, the KBAG field (containing the AES GID encrypted AES KEY/IV for the kernel) of the kernel header is now blank.
The OP was referring to the fact that the symmetric encryption did nothing to help things, it was always the asymmetric encrypted signature that did the real protection.
My guess is that you read "signature" in there and something about a cert, and assumed that actually applied to the encryption used on the kernel binary itself rather than the signature for it.
No, I read the following, on page 5, under the heading "Secure boot chain":
The Boot ROM code contains the Apple Root CA public key, which is used to verify that the Low-Level Bootloader (LLB) is signed by Apple before allowing it to load. This is the first step in the chain of trust where each step ensures that the next is signed by Apple. When the LLB finishes its tasks, it verifies and runs the next-stage bootloader, iBoot, which in turn verifies and runs the iOS kernel.
Yes, that does specifically mention the signature; no, it does not mention the encryption used, if any, on the various components of the boot chain. The remainder of the document does make many mentions of the use of AES, on the data partition, for secure communications, in the secure enclave for storing fingerprint hashes, for ApplePay, but no mention of its use anywhere in the boot process.
Perhaps you do need to read the reference? You don't seem to be as familiar with the boot process as you think.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Perhaps you do need to read the reference? You don't seem to be as familiar with the boot process as you think.
No, I really don't. Because I helped author literature that describes the process, as I was writing software to decrypt, and dump the symbol tables in the kernel. For your reference, here's the iOS IMG3 boot-chain container structure: // ASCII_LE("Img3") // full size of fw image // size of fw image without header
// size of the start of the data section (the code) up to
// the start of the RSA signature (SHSH section) // identifier of image, used when bootrom is parsing images
// list to find LLB (illb), LLB parsing it to find iBoot (ibot),
// etc. // continues until end of file
// see below // length of tag including "magic" and these two length values // length of tag data // Typically padded to 4 byte multiple
typedef struct img3File {
uint32_t magic;
uint32_t fullSize;
uint32_t sizeNoPack;
uint32_t sigCheckArea;// although that is just my name for it, this is the
uint32_t ident;
img3Tag tags[];
};
typedef struct img3Tag {
uint32_t magic;
uint32_t totalLength;
uint32_t dataLength;
uint8_t data[dataLength];
uint8_t pad[totalLength - dataLength - 12];
};
VERS: iBoot version of the image
SEPO: Security Epoch
SDOM: Security Domain
PROD: Production Mode
CHIP: Chip to be used with. example: 0x8900 for S5L8900.
BORD: Board to be used with
KBAG: Contains the IV and key required to decrypt; encrypted with the GID Key
SHSH: RSA encrypted SHA1 hash of the file
CERT: Certificate
ECID: Exclusive Chip ID unique to every device
TYPE: Type of image, should contain the same string as the header's ident
DATA: Real content of the file
KBAG is the symmetric key (protected by hardware AES engine- but that's useless if someone already has arbitrary code execution on the device [the main reason they stopped using I suspect.])
SHSH is the asymmetric signature to ensure that it won't boot something that *has* been modified.
It has been this way since forever. it is still this way now.
Whether or not the reference completely outlines the boot process as (we) security researchers know it is not relevant to our understanding of it.
Every single stage of the boot process is protected under this scheme. A symmetric key/IV encrypted by the hardware GID key to obfuscate it, which in turn obfuscates the kernel, and an SHA signature encrypted asymmetrically with RSA to make it tamper-proof.
TFA is about them no longer bothering with the symmetric encryption on the kernel portion. (The boot stages before that are still encrypted).
See? This is why credentials are important. We could have avoided this whole back-and-forth if you'd just described your experience at the start (and not even in this much detail).
I've watched enough of Louis Rossmann's videos that I should have expected Apple's own documentation to be incorrect or, at the very least, incomplete.
I stand corrected and kindly thank you for the information.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.