You are here

Checkm8 iPhone jailbreak: “Sky not falling,” vs. “Pivotal shift”—FIGHT!

public://webform/writeforus/profile-pictures/richi-2016-480.jpg
Richi Jennings, Industry analyst and editor, RJAssociates

Last week’s news that axi0mX discovered an unpatchable iPhone exploit has gotten people excited, to put it mildly. The bug is in the “SecureROM” bootrom in all iOS devices released 2011–2018.

It raises the prospect of an iThing jailbreak that Apple can’t fix. However, some commentators are giving it a big “meh,” while others say it changes everything.

Well? Which is it? In this week’s Security Blogwatch, we try to figure it out.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: OMD mind blown.

[ Explore the challenges and opportunities facing SOCs in TechBeacon's new guide, based on the 2019 State of Security Operations report. ]

It depends what “it” means

What’s the craic? Lily Hay Newman calls it the Latest Apple Security Upheaval:

[Recent] jailbreaks of iPhones—cracking iOS to let any software run on the device—have been exceedingly rare. [But] a security researcher published an exploit that lays the foundation to jailbreak almost every single iOS device released [up to] 2017, including … every iPhone model from 4S to X [plus] most models of iPad, Apple Watch, iPod Touch, and Apple TV. The implications are staggering.

The jailbreak hinges on flaws in Apple's "bootrom," [which] contains the fundamental code that runs first when a device powers on. … Such exploits can be used to create extremely powerful jailbreaks that don't depend on vulnerabilities specific to a particular iOS version.

Researchers say [it] represents a pivotal shift in the iOS security landscape. For the jailbreaking community, which works to tear free of Apple's restrictive ecosystem [it] will make it much easier to unshackle a slew of devices.

[It has] major implications for iOS device security, if bad actors abuse [it]. Fortunately, the exploit doesn't break Apple's Secure Enclave, which holds the keys to decrypt data already on the device. [But it] has concerning implications for stalkerware used by abusive partners, among other precarious situations.

Apple did not return a request … for comment.

Sky falling? Rene Ritchie has more—bootrom exploit, explained:

Checkm8 is absolutely serious but very specific and in some ways very limited. It's certainly helpful for jailbreakers and researchers that it exists, probably neutral good for bad actors, and bad for Apple and a black eye for iOS security that'll no doubt drive them even harder to lock things down.

Because they're in ROM, … bootrom exploits [are] nigh-impossible to patch. [It] could and probably will turn into a jailbreak … but also has some very limited … potential to be turned into an attack.

Someone has to take physical possession of your … iOS device first, put it in DFU … mode, and then plug it into a PC. [Now] it can be used to run unsigned code on your device, but that code only lasts until the device is rebooted. [So] I'm not sure checkm8 changes the economics of iOS attacks.

If you think, based on who you are or what you do, that you have a much higher potential threat level, then … consider upgrading ASAP. … You can protect yourself by making sure you're on an A12 or A13 device … an iPhone XR, XS, or 11, or a current … generation iPad Pro.

Jailbreakers are probably the most excited about Checkm8. … This is like the second coming of the holy grail for them [because] unlike operating system exploits [it won’t] get blown away the very next time Apple releases a software update.

Who discovered it? All hail @axi0mX:

This is possibly the biggest news in iOS jailbreak community in years. I am releasing my exploit for free for the benefit of iOS jailbreak and security research community.

Researchers and developers can use it to dump SecureROM, decrypt keybags with AES engine, and demote the device to enable JTAG. You still need additional hardware and software to use JTAG.

[It] can only be triggered over USB and requires physical access. … It uses a race condition [so] is not trivial to exploit. … It is a tethered bootrom exploit, but it should be possible to make a cable or a dongle that jailbreaks your device without a computer.

A bootrom exploit … makes iOS better for everyone. Jailbreakers and tweak developers will be able to jailbreak their phones on latest version, and they will not need to stay on older iOS versions. … It will also be better for security researchers interested in Apple's Bug Bounty. … More vulnerabilities might get reported to Apple right away.

Apple's devices can be trusted because SecureROM cannot be modified. … Can you imagine all the court orders Apple would get? … I definitely would feel less safe using an iPhone. … Read-only code for SecureROM is more secure overall.

But what we really want is an untethered JB. twocows has hope:

Most jailbreaks are currently semi-untethered, meaning if you reboot your device, you need a signed app to launch back into the jailbroken environment. This is annoying because this app needs to be re-signed, either every 7 days if you self-sign or [longer] if you can somehow get it signed by an enterprise.

I've been wanting an untethered jailbreak … so I can play RetroArch easily. I'm looking forward to this getting developed further; it looks like very early beta right now, but in the next few months it'll probably be turned into a workable jailbreak, probably with Cydia access. That'll be nice to have.

And bithakr suggests another avenue:

Could someone build a battery case that auto retethers the phone over the lightning port when it reboots?

Also ZombieCatInABox can haz yet another:

It could be used … to downgrade an iDevice back to a jailbreakable version of iOS, even unsigned.

Or perhaps not? Dino A. Dai Zovi—@dinodaizovi—tweets a rantthread:

It is super cool technically and I’m looking forward to playing with it. [But] there is a world of difference … between the last public BootROM exploit (limera1n) and now due to the introduction of the Secure Enclave.

The kernel has to ask it to unlock the device. The kernel also has to give it its signed firmware at boot (and cannot rollback to previous versions). … They can, however, modify the kernel in memory, give you back your device, and hope you don’t reboot.

This is one link in an attack chain and one that requires physical access. … The attacker still needs the other links to do Bad Things™ – I don’t think sky is falling.

Amusingly, Cellebrite VP Shahar Tal—@jifa—pretends he didn’t already know about it:

For those still grasping to understand today’s significance: with his release of a forever-day, @axi0mX overturned the iOS research landscape for years to come. This goes down in public exploitation history.

Yes, it’s not the first iPhone BootROM bug, but this marks a new era.

Wait. Pause. It turns out littlelailo had already discovered the bug, a few months ago, calling it “Apollo”:

This bug was also called Moonshine in the beginning.
  1. When usb is started to get an image over dfu, dfu registers an interface to handle all the commands and allocates a buffer …
  2. if you send data to dfu the setup packet is handled by the main code which then calls out to …
  3. the interface code [which] verifies that wLength is shorter than the … buffer length and if that's the case it updates a pointer … with a pointer to the … buffer
  4. it then returns wLength which is the length it wants to receive …
  5. the usb main code then updates a global var with the length …
  6. if a data package is received, it gets written to the … buffer via the pointer … and another global variable is used to keep track of how many bytes were received …
  7. if all the data was received, the dfu specific code is called again and that [copies the] buffer to the memory … from where the image is later booted …
  8. the usb code resets all variables and goes on to handle new packages
  9. if dfu exits, the … buffer is freed and if parsing of the image fails, bootrom reenters dfu …
At step 5, the global variables are updated and the bootrom gets ready to receive the data, but … you can violate the usb spec and don't send any. … Then you can trigger a usb reset to trigger image parsing.

If that parsing fails, bootrom will enter dfu once again, but step 8 wasn't executed so the global variables still contain all the values. However step 9 was executed, so the … buffer is freed while the pointer … still points to it.

Because of that you can easily trigger a write to an already freed buffer by sending data. … The payload will overwrite the usb task struct and the next allocation after it will be the usb stack.

Meanwhile, Infranto sees the upside for Apple shareholders:

[Apple] will be able to just make new iPhones with this [bug] patched and sell millions by claiming they’ve, “improved security even more.”

The moral of the story?

Consider protecting your high-value users by upgrading their devices.

[ Effective SecOps requires staying one step ahead. Get up to speed with this Webinar covering UEBA and MITRE ATT&CK ]

And finally

The Real Fake Cameras Of Toy Story 4


You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or sbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE.

Image source: Microsiervos (cc:by)

[ Find out how to take control of credentials privilege in your organization in this Oct. 31 Webinar. You'll learn best practices, more. ]