No details in the article of what the exploit accomplishes or what is required in order to achieve the exploit, except that it is a hardware issue in the A11 Bionic chip, which exists in iPhone 8, 8S, and X. Not present in the A12 and A13 Secure Enclave.
> The only thing we know so far is that this vulnerability in Secure Enclave affects all Apple chips between the A7 and A11 Bionic, similar to the checkm8 exploit that allows jailbreak for almost all iOS devices up to iPhone X.
Actually, the exploit requires a bootrom exploit like checkm8 to work. This is why it doesn't work on newer devices.
Is this the same or different than the "New ‘unpatchable’ iOS exploit could lead to permanent jailbreak for iPhone 4s to iPhone X" from September 2019:
Is it actually confirmed that A11 is vulnerable? The only information I read is that checkm8 is available up until A11 and checkm8 is a prerequisite to trigger this new exploit. However, every demo/tease/screenshot I’ve seen is with an A10. If A11 is vulnerable, wouldn’t the hackers show off the attack running on it?
I don’t think so. I’ve heard rumors that whatever they’re doing does not work, but whether it’s because the bug is actually fixed or because they just didn’t bother adapting it is unclear. And there’s also some other thing going around that supposedly iOS 14 has some sort of additional stuff to make checkm8 less effective, which would involve a SEP exploit…
The vulnerability was explained in more detail in an article [0] submitted earlier this week [1]
> Team Pangu demonstrated that they could exploit a bug in the memory controller that manipulates the TZ0 register memory. TZ0 refers to a register that controls the range of SEP memory usage.
> @Windknown first introduces the architecture of Apple’s SEP hardware and system. The main processor and the co-processor are isolated and need to communicate through a shared memory mechanism. Subsequently, it explained in detail the process of SEPROM initialization, including the realization of the memory isolation mechanism. The memory isolation mechanism is implemented by the TZO mechanism.
> The TZ0 register describes the range of SEP memory usage, and AMCC is used to prohibit the main processor from accessing the memory space of TZO. The epic vulnerability announced this time is in SEPROM. By combining the BOOTROM exploit of checkm8, the IO mapping register can be modified to bypass the memory isolation protection. Then cooperate with the race of the main processor to achieve the purpose of modifying any SEPOS and SEP APP. For example, through the restriction of password input in patch sks, to try to lock the screen password without restriction.
> According to Axi0mX, the SEP chip bug can only be triggered if the hacker has physical access to the device and with a BOOTROM exploit like checkm8 or checkra1n.
> He also added that this vulnerability cannot be used to jailbreak via a web browser (JailbreakMe) or with an application (unc0ver) because the value in the TZ0 registry cannot be changed after boot. So, unless someone gets his/her hands on your iPhone and puts it in DFU mode, you are safe.
This demonstrates yet again how encryption technology should be in software, not hardware, in open-source, not closed-source, and in the decentralised full control of every user, not centralised self-serving entities.
If someone disagrees, it is reasonable to expect them to explain why instead of merely dismissing it.
Also, I think my generalised statements - and generalised statements have value and meaning - are quite self-evident and already well understood concepts among HN readers.
However, here they are explained one minor level further:
- Software can be patched. Hardware can only be thrown out.
- Open-source can be far more easily audited. Closed-source software has to be reverse-engineered by the user at best.
- Full control of encryption means the user has the ability and responsibility to control all aspects of access to the keys.
I now invite you or others to explain your disagreement.
Secure enclaves and their ilk should really not be soldered on devices, or on silicon.
What happens if/when someone manages to create a persistent enclave exploit?
It might be entirely impossible to know if you're affected, and the only plausible (but not very reasonable) end user mitigation might be to replace an entire logic board.
Likely for a quite hefty sum of money.
I'm not saying it's all together a bad idea with a more secure processing unit, but there are quite literally no good (user centric) reason to make it hard to replace, certainly not in anything bigger than a phone form factor.
Specifically about Apple:
With its persistent claims of user centricity should not need to be told this, that it should be removable/movable, unless of course this has nothing to do with the user at all. Exactly what is up for debate, but there's a certain asymmetry in the message, the effort required, the end user benefits, and the trajectory of this work that I have a hard time reconciling with anything primarily benefitting the user. Especially considering the otherwise quite lackluster attention to quality and security seen in the last few years. Lots of security features that are ostensibly for the benefit of the user, but where one can tell a parallel story that is about complete platform control, in the light of which the design decisions seems to make more sense.
But apple really wants you to buy a new device as often as your paycheck allows you, so this kind of things (removable secure enclave) isn't going to happen, most likely.
Apple actually goes out of it’s way to maintain compatibility with older devices much longer than most manufacturers. Even the ones that no longer get the most recent OS get security patches for some time after. Yes, it would be nice to have replaceable RAM and SSD in phones, but that would not benefit most users who would never replace anything. Making those things replaceable means they are bulkier and more complex to manufacture reliably. Apple seems to have made a trade-off there.
The SIM card is really the original secure enclave, and even has protected storage of contacts and messages, and early mobile payment solutions in Asia and Europe used the SIM card to securely store payment secrets.
Unfortunately, mobile operators have been pretty terrible at keeping up with security (neglecting to block old and broken voice crypto etc)
22 comments
[ 3.3 ms ] story [ 52.5 ms ] threadActually, the exploit requires a bootrom exploit like checkm8 to work. This is why it doesn't work on newer devices.
* https://9to5mac.com/2019/09/27/ios-unpatchable-ios-exploit-j...
* https://arstechnica.com/information-technology/2019/09/devel...
* https://github.com/axi0mX/ipwndfu
* https://news.ycombinator.com/item?id=21091219
Found this. Confirms A11 is not vulnerable.
> Team Pangu demonstrated that they could exploit a bug in the memory controller that manipulates the TZ0 register memory. TZ0 refers to a register that controls the range of SEP memory usage.
> @Windknown first introduces the architecture of Apple’s SEP hardware and system. The main processor and the co-processor are isolated and need to communicate through a shared memory mechanism. Subsequently, it explained in detail the process of SEPROM initialization, including the realization of the memory isolation mechanism. The memory isolation mechanism is implemented by the TZO mechanism.
> The TZ0 register describes the range of SEP memory usage, and AMCC is used to prohibit the main processor from accessing the memory space of TZO. The epic vulnerability announced this time is in SEPROM. By combining the BOOTROM exploit of checkm8, the IO mapping register can be modified to bypass the memory isolation protection. Then cooperate with the race of the main processor to achieve the purpose of modifying any SEPOS and SEP APP. For example, through the restriction of password input in patch sks, to try to lock the screen password without restriction.
> According to Axi0mX, the SEP chip bug can only be triggered if the hacker has physical access to the device and with a BOOTROM exploit like checkm8 or checkra1n.
> He also added that this vulnerability cannot be used to jailbreak via a web browser (JailbreakMe) or with an application (unc0ver) because the value in the TZ0 registry cannot be changed after boot. So, unless someone gets his/her hands on your iPhone and puts it in DFU mode, you are safe.
[0] https://androidrookies.com/team-pangu-demonstrates-unpatchab...
[1] https://news.ycombinator.com/item?id=23976506
Also, I think my generalised statements - and generalised statements have value and meaning - are quite self-evident and already well understood concepts among HN readers.
However, here they are explained one minor level further:
- Software can be patched. Hardware can only be thrown out.
- Open-source can be far more easily audited. Closed-source software has to be reverse-engineered by the user at best.
- Full control of encryption means the user has the ability and responsibility to control all aspects of access to the keys.
I now invite you or others to explain your disagreement.
How will your software solution guarantee that the code running is what you think it is?
It should be obvious to you that this is crazy talk.
What happens if/when someone manages to create a persistent enclave exploit?
It might be entirely impossible to know if you're affected, and the only plausible (but not very reasonable) end user mitigation might be to replace an entire logic board. Likely for a quite hefty sum of money.
I'm not saying it's all together a bad idea with a more secure processing unit, but there are quite literally no good (user centric) reason to make it hard to replace, certainly not in anything bigger than a phone form factor.
Specifically about Apple: With its persistent claims of user centricity should not need to be told this, that it should be removable/movable, unless of course this has nothing to do with the user at all. Exactly what is up for debate, but there's a certain asymmetry in the message, the effort required, the end user benefits, and the trajectory of this work that I have a hard time reconciling with anything primarily benefitting the user. Especially considering the otherwise quite lackluster attention to quality and security seen in the last few years. Lots of security features that are ostensibly for the benefit of the user, but where one can tell a parallel story that is about complete platform control, in the light of which the design decisions seems to make more sense.
But apple really wants you to buy a new device as often as your paycheck allows you, so this kind of things (removable secure enclave) isn't going to happen, most likely.
Unfortunately, mobile operators have been pretty terrible at keeping up with security (neglecting to block old and broken voice crypto etc)