Love Notes? Examining the Messages of Apple’s T2 Coprocessor
This Valentine’s Day, the Duo Labs team is spreading the love by extending our previous analysis of Apple’s T2 security chip to investigate the communication channel between the T2 and host macOS system.
The T2 chip is integral to not just the secure boot process on new generations of the iMac Pro and MacBook Pro, but also to Touch ID, one of the first biometric authenticators suitable for our passwordless future. The integrity of this system is critical. If a third-party can compromise the T2’s firmware, the chain of trust fails. However, like much of the *OS ecosystem, the T2 chip is proprietary and opaque, complicating the independent evaluation of its attack surface. We have continued to evaluate, and illuminate, the attack surface of the T2 so that those who are relying on the security of the chip can include these considerations in their evaluation of the platform. In this third phase of research, we look at the T2 surface exposed to the macOS host after the boot process has completed. We show how the messaging format differs from traditional XPC and how valid packets can be constructed to interact with the T2 chip directly.
To communicate with macOS, the T2 chip exposes a list of services over a machine-internal network interface. After disabling SIP, we can capture and analyze the T2’s network traffic. By leveraging the remotectl utility, we can open a socket to communicate with these services directly, without disabling SIP. However, the messaging protocol used is based on the XPC Services framework, for which documentation of the underlying messaging format is sparse. In our full research report, we explore this messaging format in depth.
As part of this research, we developed tooling to not only decode and monitor the messages passed between macOS and the T2 chip, but also to forge valid packets and communicate with the T2 chip directly. We have released our tooling as open source so that the entire research community can continue to evaluate the security of Apple’s T2 ecosystem.
In the process of deciphering the messaging format, we also performed an in-depth analysis of the Sysdiagnose protocol that macOS uses to retrieve system diagnostic information, including diagnostic information about the T2 chip. Unlike the sysdiagnose client utility, which requires root to query the T2 chip, the remotectl utility can be run by unprivileged processes. Our custom sysdiagnose client can leverage this to pass arbitrary diagnostic collection parameters to the remote sysdiagnose server on the T2.
For a detailed technical discussion of the research, experimental tooling and the conclusions reached, grab a box of candy hearts and check out the full research report.