hoakley March 8, 2021 Macs, Technology, Updates

Apple has released Big Sur 11.2.3 (updated)

Apple has this evening released yet another ‘patch’ update to Big Sur, bringing it to version 11.2.3. This contains “important security updates” which Apple recommends for all those using Big Sur.

It’s 2.44 GB for Intel Macs and 3.37 GB for M1 Macs, and even on a fast iMac Pro here takes around 25 minutes to install, in addition to download and 15 minute preparation time. M1 Macs still have to download the first 1 GB or so of the update direct from Apple’s servers, and only benefit from a Content Caching Server for the remaining 2.4 GB or so of the update.

According to Apple’s security release notes, this contains a single fix for a vulnerability in WebKit.

This update downgrades your MRT installation from version 1.75 to 1.72, which was originally pushed as an update on 12 November 2020. If your Mac doesn’t get a pushed update to restore 1.75 fairly quickly, you may need to run SilentKnight or LockRattler to install the correct version of MRT.

This update is already available as a full installer via
softwareupdate --list-full-installers
and Apple still lists 11.2.1 and 11.2.2 there too.

It’s also already available as an IPSW file for restoring M1 Macs in DFU mode, via Mr Macintosh, of course.

There’s still no sign of any form of standalone updater, other than the full installer itself.

The security content of this update has been provided to those still using Mojave and Catalina in the form of a Safari update. Some get all the luck.

Big Sur 11.2.3 does update a lot of Safari and WebKit components. There are no changes in the version or build numbers of any of the bundled applications, in which I don’t include Safari, as I explain below. However, there are changes in the following:

Several AppleIntel Graphics kernel extensions, which increment from version 16.1.11 to 16.1.12.
ImageIO framework, which has a single point increment in build number to 2130.3.5.
JavaScriptCore framework, which has a small increment in build number to 16610.4.3.1.7.
SafariServices framework, which has the same small increment in build number.
WebKit framework, which has the same small increment in build number.
Several Safari frameworks, which have the same small increment in build number.
WebDriver and WebInspector private frameworks, with the same incremented build number.
Safari-related templates, with the same incremented build numbers.

Safari itself now shows the same version number (14.0.3) with the common build number of 16610.4.3.1.7 which it shares with its components, as noted above.

In Big Sur, Safari itself is installed on the Data volume, not the SSV, but most if not all of its supporting frameworks and other immutable files are stored on the SSV. This division was originally intended to ensure that updating Safari itself in Catalina didn’t require long and complex installation. Unfortunately for Big Sur users, in this case the changes required to address the security vulnerability have been in those immutable files protected by the SSV, making installation considerably slower and more complex.

The minor updates in AppleIntel Graphics kexts and the ImageIO framework appear unrelated and undocumented.

[Updated 0740 UTC 9 March 2021 with final details for Safari.]

26Comments

Add yours

1

Rick on March 8, 2021 at 8:28 pm

If Apple are going to produce frequent updates to macOS, then they really need to look at the update process. A 2.4GB download and lengthy install process seems to be somewhat unreasonable for a patch to webkit.

LikeLiked by 2 people
- 2
  
  AppleEE on March 10, 2021 at 10:35 am
  
  Yup. Make no mistake, Apple is now Micro$oft. BS, Bugs, Bloatware, Security issues, Sad.
  
  LikeLiked by 2 people
3

DaveG on March 8, 2021 at 8:41 pm

FWIW, new Safari for the Catalina 10.15.7 clan. Shows 14.0.3 (15610.4.3.1.7, 15610). I would note that the installations log shows that this is the second Safari 14.0.3 to be installed (the earlier one on 3 Feb).

LikeLiked by 1 person
4

Rick on March 8, 2021 at 9:34 pm

Also it’s interesting that Catalina and Mojave resolve this webkit vulnerability with an update to Safari whereas Big Sur requires what seems like a whole OS replacement. I’m not sure I like the SSV if that’s what make this a necessity.

Also, if you have Little Snitch installed the installer may kernel panic (at least it did for me). I had to remove Little Snitch and reboot to install successfully. If it does kernel panic, the installer downloads the whole 2.4GB and goes through the 15 minute preparation process again.

LikeLiked by 1 person
- 5
  
  Jerry Fritschle on March 8, 2021 at 9:53 pm
  
  Rick, on Catalina and Mojave this was simply a standalone update to Safari. It did not “resolve” the WebKit issue at all. It had nothing to do with WebKit. The release is, at least mostly, coincidental.
  
  As I said in my own comment, I personally expect the WebKit update to be part of their next security updates, but it was considered more urgent for Big Sur.
  
  I have a large Linux VM farm of different distros, half for business, half for fun. Most have WebKit, either by default or by Jerry. When recently updating, they ALL updated WebKit (libwebkitgtk); this is particularly fun on Gentoo, where almost all packages are built from source, and this one takes forever. True, on Linux the update doesn’t require a reboot. That’s because it is not baked into the OS–nor, for that matter, is a GUI. 🙂
  
  LikeLiked by 1 person
  - 6
    
    Rick on March 8, 2021 at 10:14 pm
    
    Hi Jerry, it would seem that Apple need to review their release notes. as the email I received says the following:
    
    APPLE-SA-2021-03-08-3 Safari 14.0.3
    
    Safari 14.0.3* addresses the following issue.
    
    Information about the security content is also available
    at https://support.apple.com/HT212222.
    
    WebKit
    Available for: macOS Catalina and macOS Mojave
    Impact: Processing maliciously crafted web content may lead
    to arbitrary code execution
    Description: A memory corruption issue was addressed with
    improved validation.
    CVE-2021-1844: Clément Lecigne of Googleʼs Threat Analysis Group,
    Alison Huffman of Microsoft Browser Vulnerability Research
    
    Installation note:
    
    * After installing this update, the build number for Safari 14.0.3 is
    14610.4.3.1.7 on macOS Mojave and
    15610.4.3.1.7 on macOS Catalina.
    
    Safari 14.0.3 may be obtained from the Mac App Store.
    
    Which seems to infer that the same CVE is resolved by a Safari update on Catalina and Mojave and a major update on Big Sur. If that’s not the case, then this email is somewhat misleading.
    
    LikeLiked by 2 people
- 7
  
  Jerry Fritschle on March 8, 2021 at 11:22 pm
  
  Thanks for the link. I’ve read it with interest. Either this is misleading, or I’ll have to stand corrected. I’m a grownup.
  
  I understand WebKit to be more of a dependency for Safari, than an intrinsic part of it. I wonder whether, even with that, it was simply part of the app bundle on these older systems (or is now.) Alternately, it might be possible on these systems to update WebKit without rebooting.
  
  Having said that, it seems to me that there was a time when ANY standalone Safari update required a restart. It was not presented as an OS patch.
  
  Either that, I’m right and the WebKit update will in fact be in Mojave/Cat’s forthcoming security updates which are around the corner. Howard writes often about Apple’s documentation. Perhaps he can illuminate us here. 🙂
  
  LikeLiked by 1 person
  - 8
    
    hoakley on March 9, 2021 at 12:22 am
    
    I think you’ll find that the 3 updates address the same vulnerability, it’s just that Big Sur is a pain because of the SSV. I’m really beginning to regret that Apple ever thought of it – 10.15 was quite finicky enough, 11 is getting to be a complete pain, and we’ve not even got to 11.3 yet.
    Howard.
    
    LikeLiked by 1 person
  - 9
    
    jerryfrit on March 9, 2021 at 1:00 am
    
    Future Jerry: I looked at the Safari 14.0.3 bundles in BS and Mojave respectively. Interestingly, the Mojave one is fully twice the size. So there is a possibility that it is more self-contained with respect to WebKit.
    
    However, I sure could not find anything obvious in there like a “Webkit.dylib”. It seemed that the size difference was mainly in the Resources folder.
    
    LikeLiked by 1 person
- 10
  
  hoakley on March 9, 2021 at 12:18 am
  
  Thank you – hopefully the reasons are now more clear.
  I’m concerned about the panic, though – my second M1 has Little Snitch installed.
  Howard.
  
  LikeLiked by 1 person
  - 11
    
    Rick on March 9, 2021 at 1:24 am
    
    Both of the Macs on which I saw the panic are Intel based, so there’s some hope for you that your M1 doesn’t panic. I moved the Little Snitch app to the trash which removed the system extension and then rebooted. After the upgrade I moved it back from the trash into /Applications and it seemed to pick up where it left off. I just need to remember to do that for future updates to Big Sur.
    
    LikeLiked by 1 person
    - 12
      
      hoakley on March 9, 2021 at 7:28 am
      
      Thank you. I’ll see shortly.
      Howard.
      
      LikeLike
13

Jerry Fritschle on March 8, 2021 at 9:40 pm

An updated Safari 14.0.3 build was also released for Mojave and Catalina. I’ve installed it on my VMs and yes, it is just the browser and nothing with WebKit (which requires the reboot.) It is my guess, though, that WebKit was not considered the same level of “hot fix” as it was for BS, and will likely be rolled into their security updates that coincide with 11.3.

As to that notorious download size, I still managed to update the four Macs in my office in reasonably short order. Content Caching was my friend, here. 🙂

LikeLiked by 1 person
- 14
  
  hoakley on March 9, 2021 at 12:19 am
  
  Thank you.
  Unfortunately M1 Macs still seem to need to download a lot of the update direct and not from the CCServer.
  Howard.
  
  LikeLike
  - 15
    
    jerryfrit on March 9, 2021 at 1:03 am
    
    The M1 seemed to need roughly 1.3 GB more. However, it at least seemed that the common data was fetched locally. It was ultimately quite fast.
    
    LikeLiked by 1 person
16

Michael Tsai - Blog - macOS 11.2.3 on March 8, 2021 at 9:49 pm

[…] also: Howard Oakley and Mr. […]

LikeLike
17

Yaroslav Fedevych on March 9, 2021 at 9:34 am

There is one thing about all this volume sealing that I don’t quite understand.

At least for more than a decade, macOS can boot from a disk image. This is how installers and recoveries boot. The disk images are as close to “immutable containers” as it gets.

Apple’s updates contain everything, up to and including data that doesn’t strictly need to be transferred over the network, like kernel and dyld caches. Theoretically, one could use signed and trusted components to generate those in place, at least this would justify some of the time spent on updating everything (and I guess the second reboot of OSes prior to Big Sur does just that). But they transfer those files ready-made over the network, then put them into place, and then recalculate all the checkcsums to reseal the volume. All to make sure it’s all immutable, untampered with, and bit for bit identical to what Apple gave us.

But what if a malicious process tampers with those files between the moment they are put into place and the volume reseal gets to those files?

If every minor update has to be 2 gigabytes, why not distribute a signed sealed disk image, and just boot from that?

LikeLike
- 18
  
  hoakley on March 9, 2021 at 3:59 pm
  
  Thank you.
  Your supposed tampering seems a tad difficult, as that would have to take place during the macOS update process, when only Apple’s installer system is running. So to be able to do that, an actor would have to take over Apple’s software update servers. While I’m sure that they get plenty of attacks, that seems so far to have been something of an insurmountable challenge.
  And please don’t give Apple ideas about distributing signed sealed disk images – that would mean in excess of 10 GB for every small patch, which would be untenable.
  Finally, one reason that Big Sur boots from a snapshot rather than a disk image is performance: a snapshot functions just like a normal disk, and individual files can be loaded as required. A disk image has to be mounted into (virtual) memory, and runs far more slowly as a result. But smaller disk images are used for limited environments such as Recovery mode and Diagnostics.
  Howard.
  
  LikeLiked by 1 person
  - 19
    
    Yaroslav Fedevych on March 10, 2021 at 7:53 pm
    
    Keeps me also wondering, how lucrative a target is it to plant a rootkit nowadays? Most malware today runs as regular user applications, or they socially engineer users to give them root, but it’s all userland anyway. Create an application that does some useful things (or is a silly addictive game), but also has a malicious component; advertise it well, and you have your user base. No rootkit needed.
    
    If, however, a rootkit is desirable, the install process at least creates opportunities. It’s hard to exploit the vulnerabilities of the Spectre/Meltdown kind, and yet attacks of this class exist in the wild, and apparently succeed in extracting sensitive data — inefficiently, slowly, but nevertheless.
    
    The sole fact that there is a moment when files just lie unsealed for a while before the OS gets to seal them, creates an opportunity. Say I get a root and inject a malicious payload into the installer’s sandbox because I can see from the process list that it’s there and it’s downloading updates. Add a component to install to the plist that describes the sandbox. Sure, it may complain that the package is unsigned or damaged, but it will have to open it and read bits from it to say so. Which prompts to look for causing a buffer overflows. Get one that enables code execution in the Installer’s context, and you’re home. Find a bug that lets it execute that preinstall Javascript, and you’re home.
    
    There are multiple lotteries one needs to win to get this to work, but I see the problem in that the process enables this class of vulnerabilities to begin with.
    
    And it’s also slow.
    
    And wasteful to boot.
    
    Yaroslav
    
    LikeLiked by 1 person
    - 20
      
      hoakley on March 10, 2021 at 7:58 pm
      
      I look forward to seeing your PoC, then.
      I think a lot of effort has already been wasted trying to get into Apple’s installers, one way or another. And those for Big Sur are even tougher to crack. It’s not as if they’re even available as packages – have you tried taking apart one of the new installer apps?
      Howard.
      
      LikeLike
21

josehill on March 9, 2021 at 3:44 pm

For people running Big Sur in virtual machines, it’s a case of “Another week; another 12.2 GB download for a minor OS update.”

LikeLiked by 1 person
- 22
  
  hoakley on March 9, 2021 at 4:10 pm
  
  I’m afraid so. And it’s not long before we should get 11.3.
  Howard.
  
  LikeLiked by 1 person
  - 23
    
    Dakotamoons on March 27, 2021 at 12:58 pm
    
    Sticking with v11.2 now for some time, due to all of the convolutions going on. It’s still (v11.2) ostensibly very stable now for several weeks running on my test-bench M1 MacBoot Air test-bench setup. I’ll wait a week or so after the v11.3 is released for any bugs in the wild, and then give v11.3 a shot. But for now, way too much going on in these incremental patches to bother with.
    
    I can’t begin to imaging the general public having to deal with suddenly having BS forced upon them (and unwittingly installing it, after it downloads) if they have their Update Prefs set to download and install all the latest operating systems! Yikes. It’s hard enough for me just tinkering around with my test-bench setup to iron out the bugs, and deal with all the changes, and incompatibilities.
    
    LikeLiked by 1 person
    - 24
      
      hoakley on March 27, 2021 at 9:57 pm
      
      Thank you.
      In some ways, Big Sur is easier when it does suddenly come upon you. I’ve now known of quite a few who have taken to it readily. It seems more difficult the more experienced you are with older versions of macOS, perhaps because it changes many things you have come to expect.
      Howard.
      
      LikeLike
25

Marcos on March 9, 2021 at 4:06 pm

I’ve been having kernel panics with MacBookPro11,2 + Little Snitch since 11.0.1. It always tries to install the update and during the process, there is a kernel panic. When the computer reboots, it has to download the whole update again. I did not realize it was caused by having Little Snitch installed until I read these comments above.
With 11.2.3, instead of one panic then successful install, there were three kernel panics and then successful install. I did not know the panics were caused by Little Snitch and in all updates, the update successfully installed after all.
Until now, I suspected the panics were because I switched the original SSD to an NVMe.

LikeLiked by 1 person
- 26
  
  hoakley on March 9, 2021 at 4:12 pm
  
  I’m sorry to hear that. Have you contacted Objective Development and reported this?
  Howard.
  
  LikeLike