
New ‘Unpatchable’ Exploit Found in Apple’s Secure Enclave Chip - jdmark
https://9to5mac.com/2020/08/01/new-unpatchable-exploit-allegedly-found-on-apples-secure-enclave-chip-heres-what-it-could-mean/
======
smartbit
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.

[0] [https://androidrookies.com/team-pangu-demonstrates-
unpatchab...](https://androidrookies.com/team-pangu-demonstrates-unpatchable-
secure-enclave-processor-sep-chip-vulnerability-in-ios/)

[1]
[https://news.ycombinator.com/item?id=23976506](https://news.ycombinator.com/item?id=23976506)

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

------
throw0101a
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:

* [https://9to5mac.com/2019/09/27/ios-unpatchable-ios-exploit-j...](https://9to5mac.com/2019/09/27/ios-unpatchable-ios-exploit-jailbreak-iphone-x/)

* [https://arstechnica.com/information-technology/2019/09/devel...](https://arstechnica.com/information-technology/2019/09/developer-of-checkm8-explains-why-idevice-jailbreak-exploit-is-a-game-changer/)

* [https://github.com/axi0mX/ipwndfu](https://github.com/axi0mX/ipwndfu)

* [https://news.ycombinator.com/item?id=21091219](https://news.ycombinator.com/item?id=21091219)

~~~
Wowfunhappy
Different, the Secure Enclave was basically the one thing unaffected by
checkm8.

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

~~~
saagarjha
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…

------
twoodfin
...up to the A11, so the most recent devices are not affected.

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

~~~
znpy
The same could be said for storage and ram chips.

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.

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

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

------
95014_refugee
... the SEP is not a "chip", it's just another processor core / set of
peripherals inside the SoC.

------
numpad0
Does this mean trust issues with mobile payments

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

~~~
95014_refugee
No, it really doesn't.

~~~
mindfulhack
How so?

~~~
wutwutwutwut
I think the burden is on you to show how all of these things are demonstrated.
You're the one making a claim here.

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

~~~
wutwutwutwut
> the user has the ability and responsibility to control all aspects of access
> to the keys.

It should be obvious to you that this is crazy talk.

