Often, when new iOS jailbreaks become public, the event is bittersweet. The exploit allowing people to bypass restrictions Apple puts into the mobile operating system allows hobbyists and researchers to customize their devices and gain valuable insights that may be peeking under the covers. That benefit is countered by the threat that the same jailbreak will give hackers a new way to install malware or unlock iPhones that are lost, stolen, or confiscated by unscrupulous authorities.
Friday saw the release of Checkm8. Unlike just about every jailbreak exploit released in the past nine years, it targets the iOS bootrom, which contains the very first code that’s executed when an iDevice is turned on. Because the bootrom is contained in read-only memory inside a chip, jailbreak vulnerabilities that reside there can’t be patched.
Checkm8 was developed by a hacker who uses the handle axi0mX. He’s the developer of another jailbreak-enabling exploit called alloc8 that was released in 2017. Because it was the first known iOS bootrom exploit in seven years, it was of intense interest to researchers, but it worked only on the iPhone 3GS, which was seven years old by the time alloc8 went public. The limitation gave the exploit little practical application.
Checkm8 is different. It works on 11 generations of iPhones, from the 4S to the X. While it doesn’t work on newer devices, Checkm8 can jailbreak hundreds of millions of devices in use today. And because the bootrom can’t be updated after the device is manufactured, Checkm8 will be able to jailbreak in perpetuity.
I wanted to learn how Checkm8 will shape the iPhone experience—particularly as it relates to security—so I spoke at length with axi0mX on Friday. Thomas Reed, director of Mac offerings at security firm Malwarebytes, joined me. The takeaways from the long-ranging interview are:
Read on to find out, in axi0mX’s own words, why he believes this is the case:
Dan Goodin: Can we start with the broad details? Can you describe at a high level what Checkm8 is, or what it is not?
axi0mX: It is an exploit, and that means it can get around the protection that Apple built into the bootrom of most recent iPhones and iPads. It can compromise it so that you can execute any code at the bootrom level that you want. That is something that used to be common years ago, during the days of the first iPhone and iPhone 3G and iPhone 4. There were bootrom exploits [then] so that people could jailbreak their phone through the bootrom and that later would not be possible.
The last bootrom exploit that was released was for iPhone 4 back in 2010, I believe by Geohot. After that, it was not possible to exploit an iPhone at this level. All the jailbreaks [that] were done later on [happened] once the operating system boots. The reason that bootrom is special is it’s part of the chip that Apple made for the phone, so whatever code is put there in the factory is going to be there for the rest of its life. So if there is any vulnerability inside the bootrom it cannot be patched.
Persistence and Secure Enclave
DG: When we talk about things that aren’t patchable, we’re talking about the bug. What about the change to the device itself. Is that permanent, or once the phone is rebooted, does it go back to its original state?
A: This exploit works only in memory, so it doesn’t have anything that persists after reboot. Once you reboot the phone … then your phone is back to an unexploited state. That doesn’t mean that you can’t do other things because you have full control of the device that would modify things. But the exploit itself does not actually perform any changes. It’s all until you reboot the device.
DG: In a scenario where either police or a thief obtains a vulnerable phone but doesn’t have an unlock PIN, are they going to be helped in any way by this exploit? Does this exploit allow them to access parts of this phone or do things with this phone that they couldn’t otherwise do?
A: The answer is it depends. Before Apple introduced the Secure Enclave and Touch ID in 2013, you didn’t have advanced security protections. So, for example, the [San Bernardino gun man’s] phone that was famously unlocked [by the FBI]—the iPhone 5c— that didn’t have Secure Enclave. So in that case this vulnerability would allow you to very quickly get the PIN and get access to all the data. But for pretty much all current phones, from iPhone 6 to iPhone 8, there is a Secure Enclave that protects your data if you don’t have the PIN.
My exploit does not affect the Secure Enclave at all. It only allows you to get code execution on the device. It doesn’t help you boot towards the PIN because that is protected by a separate system. But for older devices, which have been deprecated for a while now, for those devices like the iPhone 5, there is not a separate system, so in that case you could be able to [access data] quickly [without an unlock PIN].
DG: So this exploit isn’t going to be of much benefit to a person who has that device [with Secure Enclave] but does not have the PIN, right?
A: If by benefit you mean accessing your data, then yes that is correct. But it’s still possible they might have other goals than accessing your data, and in that case, it’s possible they would get some benefit.
DG: Are you talking about creating some sort of backdoor that once the owner puts in a PIN it would get sent to the attacker, or a scenario like that?
A: If, say, for example, you leave your phone in a hotel room, it’s possible that someone did something to your phone that causes it to send all of the information to some bad actor’s computer.
DG: And that would happen after the legitimate owner returned and entered their PIN?
A: Yes, but that’s not really a scenario that I would worry much about, because attackers at that level … would be more likely to get you to go to a bad webpage or connect to a bad Wi-Fi hotspot in a remote exploit scenario. Attackers don’t like to be close. They want to be in the distance and hidden.
In this case [involving Checkm8], they would have to physically hold your device and their hand and would have to connect a cable to it. It requires access that most attackers would like to avoid.
This attack does not work remotely
DG: How likely or feasible is it for an attacker to chain Checkm8 to some other exploit to devise remote attacks?
A: It’s impossible. This attack does not work remotely. You have to have a cable connected to your device and put your device into DFU mode, and that requires you to hold buttons for a couple seconds in a correct way. It’s something that most people have never used. There is no feasible scenario where someone would be able to use this attack remotely.
If you want to talk [about] really hypothetical situations, if you’re a jailbreaker and you’re trying to use your exploit on your own computer and somehow your computer is compromised, it’s possible someone on your computer is going to deliver a different version of the exploit that does more stuff than what you want to do. But that is not a scenario that’s going to apply to most people. That is a scenario that is simply not practical.
Thomas Reed: Does the bootrom code that’s loaded into RAM get modified by the exploit, or is that not a requirement? Through this vulnerability would you need to make modifications to the bootrom code that’s loaded into RAM, or would that not be a factor, would that not be involved in the way the exploit works? I’m under the assumption that some of the code from the bootrom is loaded into RAM when it’s executed. Maybe I’m wrong about that.
A: The correct answer is that it’s complicated. The code that is used by the bootrom is all in read-only memory. It doesn’t need to get copied in order for it to be used. In order for my device to be able to do what I want, I want to also inject some custom code. In that case, I can’t write my code into the read-only memory, so my only option is to write it into RAM or in this case SRAM—which is the low-level memory that is used by the bootrom—and then have my injected code live in this small space. But the actual bootrom code itself does not get copied in there. It’s only the things that I added to my exploit.
TR: Can this be used to install any other code, any other programs that you wanted, with root-level permissions, so that you could install malware through this?
A: The correct answer is: it depends. When you decide to jailbreak your phone using this exploit, you can customize what Apple is doing. Apple has some advanced protections. A lot of their system is set up so that you don’t have malware running. If you decide to jailbreak, you’re going to get rid of some of the protections. Some people might make a jailbreak that keeps a lot of those protections, but it also allows you to remove protections. Other people might remove all protections altogether.
The jailbreak that you can make with this exploit always requires you to exploit the device fresh after reboot. So if you don’t use the exploit, your device will only boot to a clean install [version] of iOS. It’s not like you can install malware once and then have it stay forever if you’re not using the exploit because iOS has protections against that.