New ‘Unpatchable’ Exploit Found in Apple’s Secure Enclave Chip
9to5mac.com
9to5mac.com
> 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...
* https://9to5mac.com/2019/09/27/ios-unpatchable-ios-exploit-j...
* https://arstechnica.com/information-technology/2019/09/devel...
Found this. Confirms A11 is not vulnerable.
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)
Actually, the exploit requires a bootrom exploit like checkm8 to work. This is why it doesn't work on newer devices.
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.