macOS 14.1.2
Juli Clover (release notes, security, developer, enterprise, full installer, M3, IPSW, M3):
According to Apple’s security support page, the update fixes two vulnerabilities that Apple says were exploited on versions of iOS earlier than iOS 16.7.1.
See also: Mr. Macintosh and Howard Oakley.
Previously:
Update (2023-12-08): Nick Heer:
According to Project Zero’s spreadsheet, Apple patched ten zero-days in 2022, thirteen in 2021, three in 2020, two in 2019, three in 2016, and none in 2018, 2017, 2015, and 2014. It seems like a similar story across the board: the 2014 spreadsheet contains just eleven entries total, while the 2023 sheet contains fifty-six so far.
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?
[…]
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.
We’re currently in another phase when that’s the case: while those Macs released before September should now be running macOS 14.1.2 build 23B92, M3 models from November have their own build number of 23B2091.
This means that if you have an M3 and an older model, they’re running incompatible releases of macOS.
[…]
There are other differences that are harder to explain, like an apparently much newer build of the News app, which has reached 3529.0.3 on all other Macs, but the M3’s build number is given as 5323, as do all the private frameworks that support it, despite having the same version number of 9.1.
The red menu bar usually appears when switching between Stage contents, shown here when bringing the X (formerly Twitter) app and Safari onto the Stage. While the new windows appear correctly, instead of switching to the correct menu for either of them, the menu bar turns red and loses the menus that should appear at the left, for the front app.
7 Comments RSS · Twitter · Mastodon
@Ben That’s what Apple’s page says.
So you're right—I must have looked at the wrong Apple page (I couldn't find that that passage).
So I shift the blame from Clover to Apple: it's an indication of either shoddy editing or injudicious software design, neither of which bodes well for such fundamental works.
(I'm ashamed to realize I started not just one but both of my paragraphs with a needless, noisy, empty “So”—a popular affectation that makes me cringe to read. 😜)
It’s also possible it wasn’t exploited on macOS, but both platforms share the same code path, and thus macOS benefits from the fix being made just as much as iOS does.
@Dimitri Yes, that’s what I think Apple means.
You're almost surely right. But that supports my first hypothesis: poor technical writing. The document pertains to MacOS, the bug was fixed in MacOS, and a reasonable person wonders why a different operating system is being discussed.
Juli Clover appears to have confused MacOS and iOS.