“iPhone jailbreaking is dead” reads the headline. Four words signaling the end of a 10-year long battle between Apple and those who wanted open control of their iOS devices. Here is an …
» iPhone jailbreaking is dead » reads the headline. Four words signaling the end of a 10-year long battle between Apple and those who wanted open control of their iOS devices. Here is an admission in black and white that prominent members of the jailbreaking community are giving up on attacking iOS devices. Apple created a system where their engineers, like soldiers in a castle under siege, were able to outlast the besieging army; throwing back assault after assault, until the attackers, deciding the siege was no longer worthwhile, packed up and headed home.
Ten years ago, finding a jailbreak was fairly doable, though it required skill. As iOS jailbreaks became harder to find, however, they became more valuable. Zerodium publicly announced it would pay $1 million, now increased to $1.5 million, for a remote jailbreak flaw (e.g. remote code execution) on iOS. This effectively priced the jailbreak community out of the market for iOS vulnerabilities. Markets only assign commodities such value when they are rare and difficult to obtain. If somehow you remain unconvinced, consider that the last publicly available untethered (e.g. persistent across reboots) jailbreak was discovered over a year ago, and was part of the government-quality attack tool Pegasus. The current generation of jailbreaks require the user to run a jailbreak app every time they reboot.
All of this flies in the face of conventional computer security orthodoxy which contends that the advantage will always belong to the attacker. It’s easy to see why this thinking holds true. The attacker only needs to find one or two exploits anywhere in the system, while the defender must fix all the flaws in the system. Therefore, the attacker has a massive advantage because they are only focused on one thing while the defenders are focused on multiple things like adding new features and solving customer use cases. As Linus Torvalds noted: « Security by itself is useless… the upside is always somewhere else. » This belief in the attacker’s advantage is so pervasive that intelligence agencies around the world appear to build their cybersecurity strategies to significantly prioritize attack over defense.
If everyone believes attackers will always win, how did Apple create a system that favors the defenders? To understand the answer, it’s important to understand that creating a persistent iOS jailbreak generally requires finding at least four separate vulnerabilities in iOS:
App vulnerabilities
The first challenge is to get arbitrary code running on iOS at all. Since Apple tightly controls which apps can run on iOS, just running an arbitrary app requires finding a vulnerable application. In practice, this has usually meant finding flaws in Safari.
Having exploited that flaw, a user likely wishes to sideload apps (e.g. install and run apps that haven’t been approved by the AppStore). Originally, this was necessary in order to run third-party apps, since there was no App Store. Later, users enabled features such as Bluetooth tethering that carriers disabled or charged extra money to use. For non-iOS developers, running sideloaded apps requires disabling the signature checking iOS does on all apps before executing them. This check, which is done inside the kernel, ensures apps have come from the AppStore or an approved enterprise equivalent.
Kernel vulnerabilities
Now, our attacker must find a flaw in the kernel that allows arbitrary code execution in order to disable the signature checking routine. The kernel of an operating system is like a traffic cop. It is in charge of controlling access to hardware resources, managing processes, and controlling user permissions among other duties.
Assuming the first two flaws have been found and successfully exploited, the jailbreak is only effective until the device reboots because at that point signature checking will be re-enabled and the user-loaded apps won’t be allowed to execute. To persist the jailbreak across reboots, the attacker needs to find an exploit in the boot sequence of the iOS device that will run the attacker’s code.
Boot vulnerabilities
When iOS boots, the hardware first verifies the signature on the firmware, which then verifies the signature on the boot loader (actually, iOS has two), which then verifies the signature on the kernel, which then checks the signatures on all subsequently launched programs. Therefore, all attackers are forced to find a flaw somewhere in that boot sequence that will allow them to run their initial program that will disable the kernel’s signature checking.
And thus, the beauty of Apple’s strategy is revealed. First, they force their opponent to find four vulnerabilities; fixing any one of which breaks the jailbreak and forces the attacker to find a new flaw that serves the same purpose. Second, and perhaps more critically, Apple ensures that at least one of those flaws must be in the boot sequence.
This is a huge advantage because, unlike most programs, boot loaders are typically relatively small (hundreds or thousands of lines of code, not millions) and they don’t need a lot of new features added over time. Thus, attackers can’t count on the bootloaders introducing new flaws. This creates a « narrow pass, » and, as Sun Tzu advised (« With regard to narrow passes, if you can occupy them first, let them be strongly garrisoned and await the advent of the enemy. »), Apple has fortified it.
Kernel vulnerabilities (redux)
Finally, the attacker needs an exploit to get back into the kernel to disable the signature checking again. It is likely that this exploit will require a different flaw than the original kernel vulnerability used. However, if an attacker has managed to get this far, the jailbreak will persist across reboots. At least until the next version of iOS patches these flaws and this race starts over again.
Within the security community there has long been a debate of whether fixing any single bug makes the system significantly more secure. By creating a « narrow point » that can contain only a limited number of bugs, Apple has ensured that the answer is « yes » for iOS.
