Let’s talk about that thing nobody’s talking about. Let’s talk about a vulnerability that’s exposing 2018-2020 Macs while most are declining to act nor report about the matter. Oh, and did I mention it’s unpatchable?
Buckle up buckaroo, we’re in for a wild ride.
Skip to #security-issues for the technical mumbo-jumbo.
The following post is an industry analysis of the code and research performed by twitter.com/axi0mx, twitter.com/h0m3us3r, twitter.com/aunali1, twitter.com/mcmrarm and twitter.com/su_rickmark who poured endless hours of work into this, allowing companies and users to understand their risks concerning this issue.
This blog post only applies to macOS systems with an Intel processor and the embedded T2 security chip. Apple silicon systems will run completely on a set of Apple-designed ARM processors and mighth have a different topology, e.g. based on the A12. Since the A12 chip seems to have fixed this issue (to be confirmed), it’s highly likely the new Apple Silicon machines will not be vulnerable. And while the new upcoming Intel Macs at the end of year will probably receive a new hardware revision of the T2 chip (e.g. based on the A12), we are still stuck with this vulnerability on Macs between 2018 and 2020.
In case you are using a recent macOS device, you are probably using the embedded T2 security chip which runs bridgeOS and is actually based on watchOS. This is a custom ARM processor designed by Apple based on the A10 CPU found in the iPhone 7. The T2 chip contains a Secure Enclave Processor (SEP), much like the A-series processor in your iPhone will contain a SEP.
While newer Macs and/or Apple Silicon (including the dev kit) will use a more recent A-series processor such as the one found in the recent iPhone (A12), current Macs still use the A10.
It performs a predefined set of tasks for macOS such as audio processing, handling I/O, functioning as a Hardware Security Module for e.g. Apple KeyChain or 2FA, hardware accelerating media playback, whitelisting kernel extensions, cryptographic operations and ensuring the operating system you are booting is not tampered with. The T2 chip runs its own firmware called bridgeOS, which can be updated when you install a new macOS version. (ever notice the screen flickering? that’s the display driver being interrupted and possibly updated.)
Edit: I first mentioned the iPad Pro to be impacted by the T2 vulnerability, but while it could suffer from the same vulnerability, it does not contain a T2 chip.
So let’s focus on the boot image verification on macOS. What exactly happens when you press that power button? There’s also a visual representation for any conaisseurs. For the enthusiasts, I personally find Booting Secure by mikeymikey a more in-depth description.
The T2 chip is fully booted and stays on, even if your Mac device is shutdown.
The press of the power button or the opening of the lid triggers the System Management Controller (SMC) to boot.
The SMC performs a Power-On-Self-Test (POST) to detect any EFI or hardware issues such as bad RAM and possibly redirect to Recovery.
After those basic sanity checks, the T2 chip is triggered and I/O connectors are setup. (USB, NVMe, PCIe, …) It will use NVMe and PCIe to talk to NAND storage.
The applicable boot disk is selected and a disk encryption password is asked if enabled to mount APFS volumes possibly via FileVault2 disk encryption.
/System/Library/CoreServices/boot.efi is located on your System APFS volume and depending on your secure boot settings is validated.
boot.efi is ran which loads the Darwin kernel (throwback to BSD) (or Boot Camp if booting Microsoft Windows) & IODevice drivers. If a kernel cache is found in /System/Library/PrelinkedKernels/prelinkedkernel, it will use that.
Any User Approved Kernel Extensions are initialized & added to the kernel space -if- they are approved by the T2 chip. This will go away with System Extensions.
So Apple has a couple of tricks up its sleeve to limit the attack surface of any potential security vulnerabilities. A small summary of related measures since macOS Big Sur on Intel processors:
System Integrity Protection (SIP): a read-only /System partition so the base install of macOS (including the kernel) cannot be tampered with.
System Extensions: a move to away from Kernel Extensions, getting external code out of the Kernel framework-wise.
Secure Boot: verifies the signature validity of the operating system on disk.
Filesystem seals: every byte of data is compared to a hash in the filesystem metadata tree, recursively verifying integrity.
As you probably all already know, Apple pushes forward privacy & security as important weapons in todays world of technology. They tout their devices as highly secure and vouch to handle your personal data using a privacy-centric approach. While there have been mistakes made in the past (who can blame them?), Apple has been generally quick to fix any security issues that were disclosed to their responsible disclosure program or in public.
Jailbreaking has been a big thing in the iOS for a long time. The process of exploiting vulnerability flaws in your iPhone or iOS installation is a popular way of completely customizing your otherwise pretty trimmed down iPhone. There even are jailbreak app stores to download modified apps or a very active salesmarket for tweaks, to tweak your system or apps in some way.
The mini operating system on the T2 (SepOS) suffers from a security vulnerable also found in the iPhone 7 since it contains a processor based on the iOS A10. Exploitation of this type of processor for the sake of installing homebrew software is very actively discussed in the /r/jailbreak subreddit.
So using the checkm8 exploit originally made for iPhones, the checkra1n exploit was developed to build a semi-tethered exploit for the T2 security chip, exploiting a flaw. This could be used to e.g. circumvent activation lock, allowing stolen iPhones or macOS devices to be reset and sold on the black market.
Normally the T2 chip will exit with a fatal error if it is in DFU mode and it detects a decryption call, but thanks to the blackbird vulnerability by team Pangu, we can completely circumvent that check in the SEP and do whatever we please.
Since sepOS/BootROM is Read-Only Memory for security reasons, interestingly, Apple cannot patch this core vulnerability without a new hardware revision. This thankfully also means that this is not a persistent vulnerability, so it will require a hardware insert or other attached component such as a malicious USB-C cable.
Every Apple iDevice (which includes the T2 and the Watch, via a port under the band) ships with a firmware recovery USB interface called Device Firmware Update (DFU), which is triggered when the device is not be able to boot or by pressing a particular set of buttons when turned on. It is always available because it is code run from SecureROM. This is the mode in which checkm8 runs.
Apple also leaves the ability to access various debug functionality which is disabled on production devices unless a special boot payload is used which runs in DFU. Since Apple is the only one who can sign code for DFU, they can demote any device they like, including the most recent A14 processors. But since the checkm8 vulnerability runs so early in the boot process, we too can demote the T2 into DFU mode. Without checkm8, we would not be able to run unsigned code in DFU and thus not be able enable debug interfaces. Once the debug interface is enabled Apple uses specialized cables with simian names (see Chimp, Kanzi, Gorilla).
Once you have access on the T2, you have full root access and kernel execution privileges since the kernel is rewritten before execution.
Good news is that if you are using FileVault2 as disk encryption, they do not have access to your data on disk immediately.
They can however inject a keylogger in the T2 firmware since it manages keyboard access, storing your password for retrieval or transmitting it in the case of a malicious hardware attachment.
The functionality of locking an Apple device remotely (e.g. via MDM or FindMy) can be bypassed (Activation Lock).
A firmware password does not mitigate this issue since it requires keyboard access, and thus needs the T2 chip to run first.
Any kernel extension could be whitelisted since the T2 chip decides which one to load during boot.
If the attack is able to alter your hardware (or sneak in a malicious USB-C cable), it would be possible to achieve a semi-tethered exploit.
While this may not sound as frightening, be aware that this is a perfectly possible attack scenario for state actors. I have sources that say more news is on the way in the upcoming weeks. I quote: be afraid, be very afraid.
See my next blog post for the exact exploitation instructions and examples.
I’ve reached out to Apple concerning this issue on numerous occasions, even doing the dreaded cc tcook@apple.com to get some exposure. Since I did not receive a response for weeks, I did the same to numerous news websites that cover Apple, but no response there as well. In hope of raising more awareness (and an official response from Apple), I am hereby disclosing almost all of the details. You could argue I’m not following responsible disclosure, but since this issue has been known since 2019, I think it’s quite clear Apple is not planning on making a public statement and quietly developing a (hopefully) patched T2 in the newer Macs & Silicon.
If you suspect your system to be tampered with, use Apple Configurator to reinstall bridgeOS on your T2 chip described here. If you are a potential target of state actors, verify your SMC payload integrity and don’t leave your device unsupervised. You could try resetting your SMC with a keyboard combination.
Contact your Apple rep & wait for official news from Apple. Don’t use the T2 chip for any sensitive credentials for now such as MFA. Raise awareness to your users to not leave their device unattended.
Wait for a fix, keep an eye on the checkra1n team and be prepared to replace your Mac. Be angry at news websites & Apple for not covering this issue, despite attempts from me and others to get them to report this matter.
TL;DR: recent Macs (2018-2020, T2 chip) are no longer safe to use if left alone and physical access was possible, even if you had them powered down.
