Big Sur brought us the immutable boot volume, signed and sealed, with the SSV. This makes it almost impossible for malicious software to change anything in the System, as it’s a snapshot with every last bit verified using its tree of hashes. Its downside is that making wanted changes to update macOS or any components on the SSV is cumbersome: changes have to be written to the System volume, a snapshot made, the tree of hashes rebuilt and verified against Apple’s setting for that build of macOS, and macOS rebooted from the new snapshot.

Initially, the solution for apps like Safari, security data such as that for XProtect, and other components like Rosetta 2 that need to be installed separately from macOS, was to store them on the Data volume, where they can only be protected by SIP. That’s how Big Sur and Monterey worked, but this started to change in late versions of Monterey (in 12.6.1, if not before), and Ventura, with the introduction of the cryptex.

Cryptexes first appeared on Apple’s customised iPhone, its Security Research Device, which uses them to load a personalised trust cache and a disk image containing corresponding content. Without the cryptex, engineering those iPhones would have been extremely difficult.

What is a cryptex?

According to its entry in the File Formats Manual from two years ago (man cryptex), ‘A cryptex is a cryptographically-sealed archive which encapsulates a well-defined filesystem hierarchy. The host operating system recognizes the hierarchy of the cryptex and extends itself with the content of that hierarchy. The name “cryptex” is a portmanteau for “CRYPTographically-sealed EXtension”.’

In practice, a cryptex is a sealed Disk Image containing its own file system, which is mounted at a randomly chosen location within the root file system during the boot process. Prior to mounting the cryptex, macOS verifies it matches its seal, thus hasn’t been tampered with. Managing these cryptexes is the task of the cryptexd service with cryptexctl. Because cryptexes aren’t mounted in the usual way, they’re not visible in mount lists such as that produced by mount(8).

A cryptex can contain a wide range of different contents, typically including command tools, system executables, libraries, man pages, apps and frameworks. Many of the system components that used to be stored on the Data volume are now loaded by Ventura in cryptexes, including Safari and all its supporting components, the JavaScriptCore framework, some AMD graphics drivers, and most importantly dyld shared caches (which had been a heavy burden for Big Sur updates).

How are cryptexes updated?

Looking for cryptexes and their contents gets confusing, as they appear in multiple paths, although the cryptexes themselves are found on the Preboot volume (mounted at /System/Volumes), in the path /[UUID]/cryptex1/current/. In macOS 13.0.1, you’ll see three Disk Images:

• app.dmg, 23 MB in size, containing Safari
• os.clone.dmg, 1.53 GB, apparently a copy of os.dmg
• os.dmg, 1.53 GB, containing much of the other components, including dyld caches.

app.dmg and os.dmg are accompanied by files containing their root hash (seal) and trust cache. There’s also a folder named Cryptexes on the Preboot volume containing the mounted contents of those cryptexes, which are repeated from links in /System/Cryptexes.

Late in the preparation phase of a macOS update, changed cryptexes are installed by ‘ramrod’. These are referred to as Splat, the internal name for the cryptex subsystem. Unlike the rest of a macOS update, these don’t require the full ‘Update Brain’ needed to build a new System snapshot, nor should they require macOS to be rebooted.

How will Rapid Security Responses work?

The goal in RSR updates is that the payload will be far smaller than a macOS update, and that installation and application of the RSR will be accomplished without a reboot. Cryptexes appear ideal for this, as the size of an RSR update should be little more than that of the cryptex to be installed, and once mounted, it should take effect immediately, although patched services will need to be restarted.

Inevitably, this does limit what can be achieved in an RSR, but for many patches to vulnerabilities should be effective. Apple has also promised that RSRs can be uninstalled, presumably by simply removing the cryptex. The mechanism for doing that doesn’t appear to have shipped in macOS 13.0, and it’s rumoured this will be one of the new features of the 13.1 update due in December. It will be interesting to see how it works out, whether Apple uses it to fix other bugs not affecting security, and whether Monterey will also be able to use cryptexes (in 12.6.1 there are just empty folders).

The other big unknown is how secure the cryptex subsystem will prove, something I’m sure that every macOS security researcher is poised to test.

Acknowledgement

Pioneering work was first reported in this random blog article.