Betteridge’s Law of Headlines insists that any headline posed as a question can instantly be answered with a simple “No.”
Apparently, the theory behind this witticism (it’s not actually a Law, nor yet a rule, nor even in fact anything more than a suggestion) is that if the author knew what they were talking about, and had real evidence to support their case, they’d have written the headline as an undiluted fact.
Well, we’re not journalists here on Naked Security, so fortunately we’re not bound by this law.
The ruthless answer to our own question in the headline above is, “No one knows except Apple, and Apple isn’t saying.”
A better but admittedly middle-of-the-road answer is, “Wait and see.”
Rapid responses
This story started late yesterday, at the tail end of 2023-06-10 UK time, when we excitedly [do you mean ‘excitably?’ – Ed.] wrote an advisory about Apple’s second-ever Rapid Security Response (RSR):
These RSRs are, as we explained previously, Apple’s effort to deliver single-issue emergency fixes as promptly as well-managed open source project generally do, where zero-day patches often come out within a day or two of a problem being found, with updates-to-the-updates following promptly if further investigations reveal further issues needing to be fixed.
One reason open source projects can take this sort of approach is that they usually provide a download page with the full source code of every officially-released version ever, so that if you rush to adopt the latest fixes in hours, rather than in days or weeks, and they don’t work out, there’s no barrier to rolling back to the previous version until the fix-for-the-fix is ready.
Apple’s offical upgrade pathway, however, at least for its mobile devices, has always been to supply full, system-level patches that can never be rolled back, because Apple doesn’t like the idea of users deliberately downgrading their own systems in order to exploit old bugs for the purpose of jailbreaking their own devices or installing alternative operating systems.
As a result, even when Apple produced emergency one-bug or two-bug fixes for zero-day holes that were already being actively exploited, the company needed to come up with (and you needed to put your faith in) what was essentially a one-way upgrade, even though all you really needed was a minmalistic update to one component of the system to patch a clear and present danger.
Enter the RSR process, allowing rapid patches that you can install in a hurry, that don’t require you to take your phone offline for 15 to 45 minutes of repeated reboots, and that you can later remove (and reinstall, and remove, and so on) if you decide that the cure was worse than the disease.
Bugs patched temporarily via an RSR will be patched permanently in the next full version upgrade…
…so that RSRs don’t need or get a whole new version number of their own.
Instead, they get a sequence letter appended, so that the first Rapid Security Response for iOS 16.5.1 (which came out yesterday) is displayed in Settings > General > About as 16.5.1 (a).
(We don’t know what happens if the sequence ever goes past (z), but we’d be willing to take a small wager on the answer being (aa), or perhaps (za) if alphabetic sortability is considered important.)
Here today, gone tomorrow
Anyway, just a few short hours after advising everyone to get iOS and iPadOS 16.5.1 (a), because it fixes a zero-day exploit in Apple’s WebKit code and could therefore almost certainly be abused for malware nastinesses such as implanting spyware or grabbing private data from your phone…
…commenters (special thanks to John Michael Leslie, who posted on our Facebook page) started reporting that the update was no longer showing up when they used Settings > General > Software Update to try to update their devices.
Apple’s own security portal still lists [2023-07-11T15:00:00Z] the most recent udpates as macOS 13.4.1 (a) and iOS/iPadOS 16.5.1 (a), dated 2023-07-10, with no notes about whether they’ve officially been suspended or not.
But reports via the MacRumors site suggest that the updates have been withdrawn for the time being.
One suggested reason is that Apple’s Safari browser now identifies itself in web requests with a User-Agent string that includes the appendage (a) in its veraion number.
Here’s what we saw when we pointed our updated Safari browser on iOS at a listening TCP socket (formatted with line breaks to improve legibility):
$ ncat -vv -l 9999
Ncat: Version 7.94 ( https://nmap.org/ncat )
Ncat: Listening on :::9999
Ncat: Listening on 0.0.0.0:9999
Ncat: Connection from 10.42.42.1.
Ncat: Connection from 10.42.42.1:13337.
GET / HTTP/1.1
Host: 10.42.42.42:9999
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,
application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (iPhone;
CPU iPhone OS 16_5_1 like Mac OS X)
AppleWebKit/605.1.15 (KHTML, like Gecko)
Version/16.5.2 (a)
Mobile/15E148 Safari/604.1
Accept-Language: en-GB,en;q=0.9
Accept-Encoding: gzip, deflate
Connection: keep-alive
NCAT DEBUG: Closing fd 5.
According to some MacRumors commentators, that Version/ string, consisting as it does of the usual numbers and dots along with some weird and unexpected text in round brackets, is confusing some websites.
(Ironically, the sites we’ve seen blamed in this apparently version-string-misparsing-blame-game all seem to be services that are much more commonly accessed by dedicated apps than via a browser, but the theory seems to be that they apparently choke on that 16.5.2 (a) version identifier if you decide to visit them with an updated version of Safari.)
What to do?
Strictly speaking, only Apple knows what’s going on here, and it’s not saying. (At least, not officially via its security portal (HT201222) or its About Rapid Security Responses page (HT201224.)
We suggest, if you already have the update, that you don’t remove it unless it genuinely interferes with your ability to use your phone with the websites or apps you need for work, or unless your own IT department explicitly tells you to roll back to the “non-(a)” flavour of macOS, iOS or iPadOS.
After all, this update was deemed suitable for a rapid response because the exploit it fixes is an in-the-wild, browser-based remote code execution (RCE) hole.
If you do need or wish to remove the RSR, you can do this:
- If you have an iPhone or iPad. Go to Settings > General > About > iOS/iPadOS Version and choose Remove Security Response.
- If you have a Mac. Go to System Settings > General > About and click the
(i)icon at the end of item entitled macOS Ventura.
Note that we installed the RSR right away on macOS Ventura 13.4.1 and iOS 16.5.1, and haven’t had any problems browsing to our usual web haunts via Safari or Edge. (Remember that all browsers use WebKit on Apple mobile devices!)
Therefore we don’t intend to remove the update, and we’re not willing to do so experimentally, because we have no idea whether we’ll be able to reinstall it again afterwards.
Commenters have suggested that the patch simply doesn’t get reported when they try from an unpatched device, but we haven’t tried re-patching a previously-patched device to see if that gives you a magic ticket to fetch the update again.
Simply put:
- If you’ve already downloaded macOS 13.4.1 (a) or iOS/iPadOS 16.5.1 (a), keep the update unless you absolutely have to get rid of it, given that it’s securing you against a zero-day hole.
- If you installed it and really need or want to remove it, see our instructions above, but assume that you won’t be able to reinstall it later, and will therefore put yourself into the third category below.
- If you haven’t got it yet, watch this space. We’re guessing that the
(a)patch will rapidly be replaced by a(b)patch, because the whole idea of these “lettered updates” is that they’re meant to be rapid responses. But only Apple knows for sure.
We’ll patch our usual advice from yesterday by saying: Do not delay; do it as soon as Apple and your device will let you.