Apple zero-day drama for Macs, iPhones and iPads – patch now!

Here on Naked Security, we’ve been lamenting the mysterious nature of Apple’s security updates for ages.

For example, even when widely-known security problems appear in components that are part of Apple’s operating system, Apple routinely refuses to say when, or even if, it plans to address the issues itself.

Back in February 2013, for instance, a dangerous bug was found and patched in the widely-used sudo command:

As you probably know, sudo is a program that allows you to substitute the current user and do a command (strictly, su here stands for setuid(), the Unix/Linux function used to switch between accounts).

Because the most prevalent use of sudo is to switch up to the root account, rather than down to a less privileged one…

…any authentication bypass bug in sudo should be considered critical, because it could provide anyone who’s currently logged into your computer with a trivial and apparently official way to to turn themselves instantly into an administrator.

Quickly patched by most

The bug in this case, CVE-2013-1775, was patched almost immediately by the sudo project, and the update was distributed almost immediately and universally throughout the BSD and Linux ecosystems.

Apple, however, infamously said nothing, even though the bug affected its own products.

After six months of silence, a public exploit appeared for use with the popular cybersecurity attack tool Metasploit, perhaps in an effort to squeeze Apple into action:

By not saying anything at all – and that is Apple’s official policy on cybersecurity updates: no comment until after the fix is out – the company leaves its users unable to figure out whether Apple:

• Has yet to notice that the problem even exists.
• Knows about the problem but has figured out that its own products are immune.
• Knows about the problem but has decided it won’t be fixed.
• Knows about the problem but can’t figure out how to fix it.
• Has a workaround for the time being but won’t tell anyone about it.
• Is working on a fix but won’t say so.

Slowly fixed by Apple

In the sudo bug case, Apple did eventually come to the party, and updated its own products in September.

Of course, Apple’s style of public security discourse means that we still don’t know whether the company sluggishly took seven months to implement a fix that took other operating system distros just a few days to sort out, or worringly decided to ignore the bug it altogether until the Metasploit exploit forced its hand:

The flip side of Apple’s “cybersecurity cone of silence” is that security patches that arrive suddenly – as welcome as they are if they fix critical problems – often show up with uncertain and incomplete explanations that leave users and network administrators with little to work with.

When a zero-day security hole gets patched, how do you go threat hunting to see if you were one of the unlucky people who already got targeted by cybercriminals…

…if you have next to nothing to go on even after the update is available and you know you’re safe now?

That’s where Apple users are today, following last night’s release of emergency updates for macOS, iOS and iPadOS.

If this were a Microsoft patch, we’d probably be referring to it as “out of band”, a jargon term commonly used to denote that an update is a critical one-off that just couldn’t wait for the next round of scheduled updates, and therefore doesn’t fit into the expected cycle.

Of course, in Apple’s world, there is no “band” that an individual update can be “out of”, given that all its updates arrive unnannounced and unexpected.

Even more urgent and important than usual

Nevetheless, this one feels even more urgent and important than usual, given that there is just one bug fixed, dubbed CVE-2022-22620, that affects Apple’s WebKit browser substrate, and is described with these words:

Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.

Description: A use after free issue was addressed with improved memory management.

You should assume this means “booby-trapped web pages could pwn your phone in a zero-click attack.”

A zero-click browser attack means that just looking at a web page, even if you don’t download anything from it or see any warnings or pop-ups on it, could steal private data, make unauthorised changes, or implant malware, including spyware.

(You may also have heard this sort of attack, when used to infect your device with malware, referred to by the jargon term drive-by download, where just window-shopping a website could leave you unknowingly infiltrated.)

Remember that bugs in WebKit always affect Safari, which is based on WebKit, and often affect apps with browser-like features, because those apps often use WebKit as a utility library to simplify their own coding.

Also, bugs in WebKit also affect every browser on iPhones and iPads, even non-Apple browsers like Firefox, Edge and Chrome, because Apple won’t allow other vendors’ browsers into the App Store if they bring their own low-level browser engine with them: under the surface, it’s WebKit or nothing.

What to do?

• Update to Monterey 12.2.1: If you have a Mac that is running the latest macOS version, this is for you. See Apple bulletin HT213092.
• Update to iOS 15.3.1 or iPadOS 15.3.1: If you have a recent iPhone or iPad on the latest version, this is what you need. See Apple bulletin HT213093.
• Update to Safari 15.3*: For users of the previous two macOS versions, Catalina and Big Sur, the patch comes as a Safari-only update, and doesn’t change your operating system build number. See Apple bulletin HT213091.

Users of the previous two iOS and iPadOS versions, iOS 14 and iOS 12, you’re out of luck yet again: Apple has once more maintained its oath of silence about your situation.

Are you unaffected because this bug isn’t in older WebKit code? Affected but won’t get the update for a while yet? Or simply and silently unsupported and never going to get a fix for this or any other future bugs? (Those are rhetorical questions: there’s no way to tell.)

In the list above, you’ll note that we wrote Safari 15.3* for Catalina and Big Sur users (that asterisk is not a typo), which is how Apple denotes the patch in its own bulletin.

Annoyingly, the version you already have is Safari 15.3, and the version you’ll have after updating is still Safari 15.3.

The only way to tell the old and new verions apart is to do Safari > About, and check the five-part version meganumber that comes up: if it ends 4.9.1.7 then you are out of date; if it says 4.9.1.8 then you’re patched.

Surprisingly, perhaps, the copyright notice still says 2003-2021 in both versions, as though Apple knew about this bug and coded up the fix last year, even though there have been numerous other WebKit bugs fixed in the interim: