Perpetual IT

We’ll start with the important stuff: the widely awaited OpenSSL bugfixes announced last week are out.

OpenSSL 1.1.1 goes to version 1.1.1s, and patches one listed security-related bug, but this bug doesn’t have a security rating or an official CVE number.

We strongly recommend that you update, but the CRITICAL update that you will have seen in the cybersecurity media does not apply to this version.

OpenSSL 3.0 goes to version 3.0.7, and patches not one but two CVE-numbered security bugs that are official designated at HIGH severity.

We strongly recommend that you update, with as much urgency as you can muster, but the CRITICAL fix that everyone has been talking about has now been downgraded to HIGH severity.

This reflects the opinion of the OpenSSL team:

Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described [in the release notes] have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible.

Ironically, a second and similar bug, dubbed CVE-2022-3786, was discovered while the fix for CVE-2022-3602 was being prepared.

The original bug only allows an attacker to corrupt four bytes on the stack, which limits the exploitability of the hole, while the second bug allows an unlimited amout of stack overflow, but apparently only of the “dot” character (ASCII 46, or 0x2E) repeated over and over again.

Both vulnerabilities are exposed during TLS certificate verification, where a booby-trapped client or server “identifies” itself to the server or client at the other end with a deliberately malformed TLS certificate.

Although these sorts of stack overflow (one of limited size and the other of limited data values) sound as though they will be hard to exploit for code execution (especially in 64-bit software, where four bytes is only half of a memory address)…

…they are almost certain to be easily exploitable for DoS (denial of service) attacks, where the sender of a rogue certificate could crash the recipient of that certificate at will.

Fortunately, most TLS exchanges involve clients verifying server certificates, and not the other way around.

Most web servers, for instance, don’t require visitors to identify themselves with a certificate before allowing them to read the site, so the “crash direction” of any working exploits is likely to be rogue servers crashing hapless visitors, which is generally considered much less severe than servers crashing every time they’re browsed to by a single rogue visitor.

Nevertheless, any technique by which a hacked web or email server can gratuitously crash a visiting browser or email app must be considered dangerous, not least because any attempt by the client software to retry the connection will result in the app crashing over and over and over again.

You therefore definitely want to patch against this as soon as you can.

What to do?

As mentioned above, you need OpenSSL 1.1.1s or OpenSSL 3.0.7 to replace whatever version you have at the moment.

OpenSSL 1.1.1s gets a security patch described as fixing “a regression [an old bug that reappeared] introduced in OpenSSL 1.1.1r not refreshing the certificate data to be signed before signing the certificate”, that bug doesn’t have a severity or a CVE assigned to it…

…but don’t let that put you off updating as soon as you can.

OpenSSL 3.0.7 gets the two CVE-numbered HIGH-severity fixes listed above, and even though they don’t sound quite as scary now as they did in the news-fest leading up to this release, you should assume that:

• Many attackers will quickly figure out how to exploit these hole for DoS purposes. That could cause workflow disruption at best, and cybersecurity trouble at worst, especially if the bug can be abused to slow down or break important automated processes (such as updates) in your IT ecosystem.
• Some attackers may be able to wrangle these bugs for remote code execution. This would give criminals a good chance of using booby-trapped web servers to subvert client software used for secure downloads in your own business.
• If a proof-of-concept (PoC) does get found, it will attract huge interest. As you will remember from Log4Shell, as soon as PoCs were published, thousands of self-proclaimed “researchers” jumped on the scan-the-internet-and-attack-as-you-go bandwagon under the guise of “helping” people find problems on their networks.

Note that OpenSSL 1.0.2 is still supported and updated, but privately only, for customers who have paid contracts with the OpenSSL team, which is why we don’t have any information to disclose about it here, other than to confirm that the CVE-numbered bugs in OpenSSL 3.0 don’t apply to the OpenSSL 1.0.2 series.

You can read more, and get your OpenSSL updates, from the OpenSSL website.

Note also that Google’s BoringSSL library, Firefox’s Network Security Services (NSS), and OpenBSD’s LibreSSL, all of which provide similar functionality to OpenSSL (and in the case of LibreSSL, is closely compatibile with it) are all unaffected by these bugs.

Oh, and if PoCs do start to show up online, please don’t be a clever-clogs and start “trying out” those PoCs against other people’s computers under the impression that you are “helping” with any sort of “research”.

You’ve probably seen story after story in the media in the past week about a critical bug in OpenSSL, though at the time of writing this article[2022-11-01T11:30:00Z], no one covering OpenSSL actually knows what to tell you about the bug, because the news is about an update that is scheduled to come out later today, but not yet disclosed.

We’ll be covering that bug once we actually know what it is, so we can explain it rather than simply say, “Patch at once.” (If you aren’t interested in the details of that flaw, you can indeed simply patch any vulnerable versions of OpenSSL in your own ecosystem.)

But there’s another, unrelated, cryptographic library bug, fixed recently, that hasn’t had a lot of publicity, and although we’re guessing that it’s much less dangerous than the soon-to-be-revealed OpenSSL bug, it’s nevertheless worth knowing about.

So, in the tense and exciting wait for the OpenSSL disclosure, we thought we’d quickly cover CVE-2022-37454.

That vulnerability is a buffer overwrite bug caused by an arithmetic overflow in the SHA-3 cryptographic code provided by the team that originally designed the SHA-3 hashing algorithm, originally known as Keccak (pronounced ‘ketchak’, like ‘ketchup’).

This official implementation, known as XKCP, short for eXtended Keccak Code Package, is a collection of open source library code for Keccak and a range of related cryptographic tools from the Keccak team, including their authenticated encryption algorithms Ketje and Keyak, pseudorandom generators called Kravatte and Xoofff (yes, three Fs), and a lightweight encryption algorithm for low-power processors called Xoodyak.

Hard to exploit

Fortunately, the CVE-2022-37454 bug is almost certainly going to be difficult, or even impossible, to trigger remotely, given that it relies on provoking a very peculiar sequence of calls to the hashing library.

Simply put, you need to perform the hash by feeding it a sequence of data chunks, and making sure that one of those chunks is nearly, but not quite, 4GB in size (at least 4,294,967,096 bytes, and at most 4294967295 bytes).

As you can imagine, code that hashes remotely uploaded data is likely either to retrieve the entire object before hashing it locally, typically by processing a fixed-length buffer of much smaller size over and over, or to fold each received chunk into the hash as it goes, typically receiving far more modestly-sized chunks at each network call.

Nevertheless, this bug is reminiscent of one we wrote about earlier this year in a networking protocol called NetUSB, which allows access to USB devices to be virtualised across a network, for example so you can plug a USB device such as a disk drive, a real-time clock or a weather station directly into your router, and then access it from any computer on your LAN as though it were plugged in locally:

In that bug, the code checked that you weren’t trying to use too much memory by comparing the pre-declared size of a request packet to a known limit…

…but, before checking, it silently added an extra 17 bytes to the amount of memory requested, in order to provide a bit of spare buffer space for its own use.

So, if you told the NetUSB code that you wanted to send an unimaginably large amount of data that just happened to be within 17 bytes of the 4GB limit imposed by using 32-bit integers, you provoked an integer overflow.

Using 32-bit integers, 0xFFFFFFFF + 1 gets truncated to 32 bits, so it wraps round like a old-school car odometer to 0x00000000. There isn’t room to store the correct 33-bit answer 0x100000000, in the same way that the Millennium bug wrapped the value 99+1 back round to 0, which represented the year 1900, instead of reaching 100, which would have represented the year 2000.

Thus the code would allocate just a few bytes of memory (at most (0xFFFFFFFF + 17) mod 2³², i.e. 16) but then accept almost any amount of data you wanted to send, which it would then try to squeeze into a memory block where it simply couldn’t fit.

The XKCP bug is similar, caused by a size check that is supposed to fail 200 bytes short of the 4GB limit, but that effectively gets tested against the 4GB limit instead, thus potentially leading to a range of possible outcomes, all bad:

• Crash of program calling the library. This could cause an exploitable DoS (denial of service) attack, where otherwise innocent booby-trapped data could be submitted over and over to crash a vital server, and then crash it again, and again, and again.
• Incorrect calculation of final hash value. If the calling code didn’t crash or detect the unexpected error, it could produce an incorrect result, which could cause a hash validation to go wrong. In theory, this could lead to outcomes such as prohibited data not getting picked up by a blocklist check, or modified data being wrongly identified as unmodified in an allowlist check.
• Remote code execution. If a crash can be provoked remotely with data chosen by an attacker, there is often a chance that well-informed cybercriminals might be able to manipulate the crash and trick the CPU into runing malicious code, instead of “failing safely” under the control of the operating system itself.

What to do?

Unlike OpenSSL,the XKCP implementation of SHA-3 is not very widely used (OpenSSL has its own Keccak code, by the way, and therefore isn’t affected by thus bug), but the XKCP code does appear in at least PHP 8, which has recently been patched to prevent this bug.

If you have PHP 8, patch now to 8.0.25 or 8.1.12, or later.

If you have Python 3.10 or earlier (Python 3.11 switched to a different implementation of SHA-3 that is not affected), you may be vulnerable.

Fortunately, some builds of Python 3.9 and 3.10 (this was the case on our own Linux system, Slackware-current with Python 3.9.15), are compiled so that the hashlib functions use OpenSSL, making them immune to this particular bug.

You can check whether your Python version is using the OpenSSL implementation of SHA-3, instead of using XKCP, by doing this:

>>> import hashlib
>>> hashlib.sha3_224
<built-in function openssl_sha3_224>

A vulnerable Python version will say something like <class '_sha3.sha3_224'> instead of referencing openssl_sha3_224.

According to the Python team, “Python 3.8 and earlier did not delegate sha3 to OpenSSL regardless of version, so those are vulnerable”.

You can use this code as a basic proof-of-concept to determine if you are at risk:

$ python3.x
>>> import hashlib
>>> h = hashlib.sha3_224() # set up a SHA-3 hash calculation
>>> h.update(b"\x00" * 1) # hash one byte
>>> h.update(b"\x00" * 4294967295) # then hash a further 2^32 - 1 bytes

If Python crashes at this point with an error such as python3.x terminated by signal SIGSEGV (an attempt to access memory that isn’t yours), then you need to wait for an update to your Python version, or to reorganise your code, for example by wrapping the buggy update() function so that it proactively returns an error if presented with dangerously-sized inputs.

If Python doesn’t crash, then you should be able to complete the hashing process correctly:

>>> d = h.digest()
>>> d.hex() 'c5bcc3bc73b5ef45e91d2d7c70b64f196fac08eee4e4acf6e6571ebe'

If you have any code of your own that uses XKCP, you can update XKCP from its Github page.

Imagine that you’d spoken in what you thought was total confidence to a psychotherapist, but the contents of your sessions had been saved for posterity, along with precise personal identification details such as your unique national ID number, and perhaps including additional information such as notes about your relationship with your family…

…and then, as if that were not bad enough, imagine that the words you’d never expected to be typed in and saved at all, let alone indefinitely, had been made accessible over the internet, allegedly “protected” by little more than a default password giving anyone access to everything.

Now imagine, some time later (according to some reports, the company that ran the clinic suffered data breaches in 2018 and 2019, but the overt criminality surrounding the stolen data didn’t start until 2020), that your deepest secrets, and those of tens of thousands of other trusting patients, were used in a blackmail attempt against the company.

And then, given that the company itself didn’t pay up (and what good would that have done anyway, given that the data was already out there “in the wild”?), imagine that you received a blackmail demand yourself, putting the squeeze on you to pay EUR200 to “suppress” the publication of those not-so-private-after-all talks where you had unburdened yourself to a therapist whom you reasonably assumed would keep your secrets secret.

Remember that the stolen data included things you’d said about your family and others close to you…

…and then imagine, as Wired magazine wrote in 2021 in the case of a youngster who had become an adult in the interim, if the extortionist had also contacted other people whose personal information appeared in your note, and menaced them for money, too.

That’s how the data breach saga apparently unfolded at an infamous Finnish heathcare provider, now bankrupt, called Psychotherapy Centre Vastaamo.

Thousands of complaints filed

Fortunately, if that is the right word, thousands of victims filed complaints with the police, giving Finnish authorities a clear and vital mandate to go after not only the criminals involved in the extortion, but also the senior executives at the company that allowed such an egregious data breach to happen in the first place.

Early in October 2022, the Helsinki Times reported that the former CEO of Psychotherapy Centre Vastaamo, Ville Tapio, will himself face charges over what it described as a “data protection offence [relating to] information security vulnerabilities that resulted in a leak of sensitive information on thousands of patients”.

In an interesting parallel with the recent US criminal case against Joe Sullivan, formerly CSO at Uber, Ville Tapio looks to be in trouble not only for leaving the door open in the first place, but also for not reporting the breach until long afterwards, when it could be covered up no more.

Sullivan was recently convicted in a US Federal court of what is still known in American jurisprudence by the Anglo-Norman word misprision, or covering up a crime.

According to the court, Sullivan paid off the perpetrators of a breach that involved more than 50,000,000 customer and driver records by writing up the blackmail demand from the criminals as if it were an official bug bounty report, and making the payoff look like an unexceptionable “responsible disclosure” payment instead:

Ville Tapio, like Sullivan, seems to have decided that he could get away with hiding the breach from the authorities until it couldn’t be denied any more because the extortion demands gave it away.

According to the Helisinki Times, Tapio faces up to a year in prison if convicted.

Suspected extortionist listed for arrest

But there’s more, with the alleged extortionist himself now in the spotlight of European law enforcement following an arrest warrant issued in Finland.

The Finnish National Bureau of Invesigation announced last Friday that:

[We] remanded one person in absentia on probable cause of aggravated computer break-in, attempted aggravated extortion, and aggravated dissemination of information violating personal privacy [in connection with the Psychotherapy Centre Vastaamo incident].

The police have established that the suspect currently resides abroad. For this reason, he was remanded in absentia. A European arrest warrant has been issued against the suspect. He can be arrested abroad under this warrant. After that the police will request his surrender to Finland. An Interpol notice will also be issued against the suspect, who is a Finnish citizen and about 25 years of age.

We’ve not been told his name, or where he is currently thought to be hiding out, but we’ll keep our eyes on this case, as well as the case of the CEO who is alleged not to have done enough to stop the breach in the first place, and to have effectively swept it under the carpet until it came out anyway when tens of thousands of victims were blackmailed as a result.

What to do?

• Rehearse what you will do if you suffer a breach yourself. You are not preparing to fail if you do so, but you are failing to prepare if you don’t. Learn what your reporting obligations are, and practise what you would say to those affected by the breach. As this case suggests, prompt disclosure would at least have prevented tens of thousands of vulnerable people finding out about the breach from extortion demands made directly to them and their families.
• Consider filing a personal report if you are caught up in a breach. This helps regulators and law enforcement collect evidence; helps to determine an appropriate level of response (if no one says anything, then it’s hard to convince a court that real harm was done); and helps the authorities demand higher cybersecurity standards in future.

By the way, the Finnish authorities are still hoping to persuade about 10,000 affected people who haven’t yet filed a report in the Vastaamo case to do so…

…so, if you were caught up in this vile crime and you are willing to come forward, you can learn more about what to do on the Police of Finland site. (Suomi [Finnish] – Svenska [Swedish] – English.)

Google pushed out a bunch of security fixes for the Chrome and Chromium browser code earlier this week…

…only to receive a vulnerability report from researchers at cybersecurity company Avast on the very same day.

Google’s response was to push out another update as soon as it could: a one-bug fix dealing with CVE-2022-3723, described with Google’s customary we-can-neither-confirm-nor-deny legalism saying:

Google is aware of reports that an exploit for CVE-2022-3723 exists in the wild.

(Apple also regularly uses a similarly disengaged flavour of OMG-everybody-there’s-an-0-day notification, using words to the effect that it “is aware of a report that [an] issue may have been actively exploited”.)

This Chrome update means that you’re now looking for a version number of 107.0.5304.87 or later.

Confusingly, that’s the version number to expect on Mac or Linux, while Windows users may get 107.0.5304.87 or 107.0.5304.88, and, no, we don’t know why there are two different numbers there.

For what it’s worth, the cause of this security hole was described as “type confusion in V8”, which is jargon for “there was an exploitable bug in the JavaScript engine that could be triggered by untrusted code and untrusted data that came in apparently innocently from outside”.

Loosely speaking, that means it’s almost certain that merely visiting and viewing a booby-trapped website – something that’s not supposed to lead you into harm’s way on its own – could be enough to launch rogue code and implant malware on your device, without any popups or other download warnings.

That’s what’s known in cybercrime slang as a drive-by install.

“Aware of reports”

We’re guessing, given that a cybersecurity company reported this vulnerability, and given the almost immediate publication of a one-bug update, that the flaw was uncovered in the course of an active investigation into an intrusion on a customer’s computer or network.

After an unexpected or unusual break-in, where obvious entry paths simply don’t show up in the logs, threat hunters typically turn to the gritty details of the detection-and-response logs at their disposal, attempting to piece together the system-level specifics of what happened.

Given that browser remote code execution (RCE) exploits often involve running untrusted code that came from an untrusted source in an unexpected way, and launched a new thread of execution that wouldn’t normally show up in the logs…

…access to sufficiently detailed forensic “threat response” data may not only reveal how the criminals got in, but also exactly where and how in the system they were able to bypass the security protections that would normally be in place.

Simply put, working backwards in an environment in which you can replay an attack over and over, and watch how it unfolds, will often reveal the location, if not the exact working, of an exploitable vulnerability.

And, as you can imagine, safely removing a needle from a haystack is much, much easier if you have a map of all pointy metal objects in the haystack to start with.

In short, what we mean is that when Google says “it is aware of reports” of an attack launched by exploiting Chrome in real life, we’re ready to assume that you can translate this into “the bug is real, and it really can be exploited, but because we didn’t actually investigate the hacked system in real life ourselves, we’re still on safe ground if we don’t come straight out and say, ‘Hey, everyone, it’s an 0-day’.”

The good news about bug disoveries of this sort is that they probably unfolded this way because the attackers wanted to keep both the vulnerability and the tricks needed to exploit it secret, knowing that bragging about the technique or using it too widely would hasten its discovery and thus shorten its value in targeted attacks.

Today’s browser RCE exploits can be fiendishly complex to discover and expensive to acquire, considering how much effort organisations like Mozilla, Microsoft, Apple and Google put into hardening their browsers against unwanted code execution tricks.

In other words, Google’s fast patching time, and the fact that most users will receive the update quickly and automatically (or at least semi-automatically), means that the rest of us can now not only catch up with the crooks, but get back ahead of them.

What to do?

Even though Chrome will probably update itself, we always recommend checking anyway.

As mentioned above, you’re looking for 107.0.5304.87 (Mac and Linux), or one of 107.0.5304.87 and 107.0.5304.88 (Windows).

Use More > Help > About Google Chrome > Update Google Chrome.

The open-source Chromium flavour of the browser, at least on Linux, is also currently at version 107.0.5304.87.

(If you use Chromium on Linux or one of the BSDs, you may need to check back with your distro maker to get the latest version.)

We’re not sure whether the Android version of Chrome is affected, and if so what version number to look out for.

You can watch for any forthcoming update announcements for Android on Google’s Chrome Releases blog.

We’re assuming that Chrome-based browsers on iOS and iPadOS aren’t affected, because all Apple App Store browsers are compelled to use Apple’s WebKit browsing subsystem, which doesn’t use Google’s V8 JavaScript engine.

Interestingly, at the time of writing [2022-10-29T14:00:00Z], Microsoft’s release notes for Edge described an update dated 2022-10-27 (two days after this bug was reported by the researchers), but didn’t list CVE-2022-3723 as one of the security fixes in that build, which was numbered 107.0.1418.24.

We’re therefore assuming that looking for any Edge version greater than this will indicate that Microsoft has published an update against this hole.

You can keep your eye on Edge patches via Microsoft’s Edge Security Updates page.

Regular readers will know two things about our attitude to Apple’s security patches:

• We like to get them as soon as we can. Whether it’s a full version upgrade that also includes a bunch of security fixes, or a point release (one where the leftmost verion number doesn’t change) with the primary purpose of patching bugs rather than adding new features, we’d rather err on the side of applying known security fixes than leaving our devices with holes that attackers are now aware of, even if they don’t know how to exploit them yet.
• We nevertheless very frequently find Apple’s bulletins confusing. For example, you never quite know where you stand if you’re stuck on a version that didn’t get an update this time.

Apple’s latest security bulletins, which came out earlier this very week, seem to exemplify how the company sometimes seems to increase confusion by saying too little… which is not always a happy alternative to finding out too much:

Emergent confusion

Based on the enquiries and comments we’ve received from readers in the past few days, the following confusion emerged:

• Why did a single security bulletin describe updates dubbed iOS 16.1 and iPadOS 16? We know that iPadOS 16 was delayed, so did this recent update mean that iPadOS was now getting patched only to the same security level as iOS 16, which came out more than a month ago, while iOS advanced to 16.1, thus leaving iPadOS more than five weeks adrift in cybersecurity terms?
• Why did iPadOS 16 ultimately report itself as version 16.1? (Thanks to Stefaan from Belgium for taking screenshots of his iPad update process and sending them in.) After updating, the About screen apparently says iPadOS 16, like the security bulletin did, while the iPadOS Version screen explicitly says 16.1. It sounds as though iPhones and iPads now not only both support “the version family known as 16”, but also both have the very latest security fixes, so why not simply call both of them version 16.1 everywhere for clarity, including in the security bulletin and on the About screen?
• Where did macOS 10 Catalina go? Traditionally, Apple drops support for macOS version X-3 when version X comes out, but is that the actual explanation of why macOS 11 Big Sur and macOS 12 Monterey (versions X-2 and X-1 respectively) got updates while Catalina didn’t?
• What happened to iOS/iPadOS 15.7.1? When iOS 16 came out in September 2022, the previous version family received critical updates as well, taking it to version 15.7. This inclued a critical fix to close off a kernel-level zero-day hole under active exploitation, which often translates as “someone out there is sneaking spyware onto iPhones, folks”. So, given that iOS 16.1 included yet another kernel zero-day fix, perhaps closing off an avenue being exploited by yet more spyware, where was the corresponding patch for the iOS/iPadOS 15 family, which by analogy you would assume would be 15.7.1?

As we said in yesterday’s podcast, faced with the fourth question above from a concerned reader, our short answer was simply, “DUCK: Don’t know./DOUG: Clear as mud.”

Sometimes, security bugs in operating system version X simply don’t apply to version X-1, for example because the bugs exist in code that was only added, or only exposed to danger, in newer releases.

But we’ve also seen Apple fail to produce updates for previous versions for two other reasons, either [a] because an update is genuinely needed, but turned out to be too tricky to get ready and test in time, or [b] because the previous version was now considered out of support, and wasn’t going to get an update, whether necessary or not.

And with Apple security bulletins almost always only telling you about patches that are available right now, missing updates regularly remain an unexplained (and unexplainable) mystery.

A blast of bulletins

Well, this morning we received a blast of 15 security bulletin emails from Apple , most of them listing many of the CVE-numbered bugs and security problems reported in the bulletins we’d already seen earlier in the week.

None of them directly clarified the first three questions above, although we now assume that the reason for Apple referring to “iPadOS 16” as well as to “iPadOS 16.1” was a possibly misguided attempt to convey the information that iPadOS was now getting its belated upgrade to version family 16, as well as getting an update equivalent in security fixes to the new iOS 16.1.

But the very first bulletin in the latest salvo from Apple did solve the last question listed above, by announcing iOS/iPadOS 15.7.1, which turns out to be a critical fix:

APPLE-SA-2022-10-27-1: iOS 15.7.1 and iPadOS 15.7.1 iOS 15.7.1 and iPadOS 15.7.1 addresses the following issues.
Information about the security content is also available at
https://support.apple.com/HT213490. [. . .] Kernel
Available for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation) Impact: An application may be able to execute arbitrary code with kernel privileges. Apple is aware of a report that this issue may have been actively exploited. Description: An out-of-bounds write issue was addressed with improved bounds checking. CVE-2022-42827: an anonymous researcher

So, iOS/iPadOS 15 is still supported, and if you didn’t bite the bullet and upgrade to iOS 16.1 (or to the schismically named iPadOS 16-that-is-also-16.1) earlier in the week…

…then you should make sure you get iOS/iPadOS 15.7.1 right away, because the CVE-2022-42827 kernel zero-day hole fixed in iOS 16.1 is right there in iOS/iPadOS 15.7, under active exploitation.

In other words, this was one of those cases where the reason for the missing update a few days ago was almost certainly simply that the patches weren’t ready in time.

What to do?

TL;DR if you’re an iPhone or iPad user: if you’re still on iOS/iPadOS major version 15, go to Settings > General > Security Update right away.

Check even if you’ve got automatic updates turned on, and remember not only to approve the download if you don’t have it already, but also to force your device though the install stage, which requires one or more reboots (and does, of course, take your phone or tablet offline for a while).

TL;DR if you’re Apple: a little more clarity would go a long way in security bulletins, especially when you know either that a critical update is the wings for users of earlier versions, or that they won’t be needing an update because their version isn’t affected.

By the way, if you decided to jump ahead to iOS/iPadOS 16.1 earlier this week, just to be safe…

…you can’t now go back to iOS/iPadOS 15.7.1, because Apple doesn’t allow downgrades.

(Downgrades facilitates jailbreaking, which Apple aims to prevent, and in any case would require a full data wipe first to prevent a downgrade being used as a malevolent “bring your own bug” security bypass to exfiltrate personal information.)