RIP RSR?
It has been more than four months since Apple last released a Rapid Security Response (RSR), but last week’s Sonoma update to version 14.1.2 looked like it should have come as one. It fixed two vulnerabilities, both in WebKit, that were already being exploited in older versions of iOS. Does the fact that it didn’t come as an RSR indicate that Apple has given up with them already?
RSR
Apple announced RSRs at WWDC 2022, as one of the new security features in macOS 13 Ventura. As described in its list of new features: “Get important security improvements to your devices even faster. This isn’t a standard software update. These improvements can be applied automatically between normal updates — without a restart.”
As we discovered in Ventura, there’s more to an RSR than that brief description. They’re built on the cryptex, which 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. 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, 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).
Cryptex contents
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 14.1.2, you’ll see three Disk Images:
app.dmg, 23 MB in size, containing Safari,
os.clone.dmg, 1.79 GB, apparently a copy of os.dmg,
os.dmg, 1.79 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. 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.
Public releases
On 1 May this year, Apple released the first public RSR, macOS Rapid Security Response 13.3.1 (a), a small download of just over 300 MB even for Apple silicon Macs. That passed largely without problem, although Macs still had to reboot at the end of installation. That fixed two vulnerabilities in WebKit that were both being actively exploited at the time.
The next RSR on 10 July wasn’t as successful. Rapid Security Response 13.4.1 (a) fixed one WebKit vulnerability, but unfortunately it also changed the version number of Safari to 16.5.2 (a), which was reflected in its User Agent, so broke access to many popular websites including Facebook. That was rectified in Rapid Security Response 13.4.1 (c) released three days later. Both of these also required rebooting at the end of installation.
Recent unscheduled updates
The next unscheduled macOS update, 14.1.1, was released on 7 November, but to this day Apple hasn’t provided any further information as to the bugs or vulnerabilities that it fixed, apart from issues with a limited range of MacBook Pro models. The only significant change that I was able to discover in it was in its QuartzCore framework, which isn’t suitable for an RSR.
That brings us to macOS 14.1.2 on 30 November, whose security patches consist of two in WebKit. Surely that must have been a candidate for release as an RSR?
If that was the complete account of what Apple yet again glosses over as “important bug fixes and security updates”, maybe. But there was slightly more to the 14.1.2 update than just those two patches to WebKit. Also updated, albeit with small changes in build number, are /System/Library/CoreServices/UAUPlugins/SafariUserAccountUpdater.bundle and /System/Library/PrivateFrameworks/SafariSafeBrowsing.framework. Whether Apple was alluding to those as “important bug fixes” or they were consequences of the fixes to WebKit we’ll never know, but it’s clear that the 14.1.2 update again required more than an RSR.
I suspect that Apple’s engineers have greater aspirations for RSRs in the future, but for the moment they’ll continue to deliver early fixes for serious vulnerabilities in software like Safari and WebKit that’s already delivered in cryptexes. Even if they do require the reboot that hadn’t been intended when advertised for Ventura.
Perhaps what we should have noticed, and be commenting on, is how small the 14.1.2 update was: at 845 MB for Apple silicon Macs, that’s little larger than an RSR, and significantly smaller than the smallest update in Ventura.
