Add support for Rapid Security Response updates

[natewalck]

This is more of a place holder to see what might need to be changed in Nudge to support RSRs (if anything).

If we can get away with just build numbers then great, but it seems like the docs around this are a little light still.

[carlashley]

Just a note that sw_vers will have a means of determining versions of an RSS update if one/more is installed.
It's got a new version flag in Ventura.

[xirianlight]

In the 13.2 beta, sw_vers has the following output BEFORE the RSR is applied:

ProductName: macOS
ProductVersion: 13.2
BuildVersion: 22D5027d

And this is the output after:

ProductName: macOS
ProductVersion: 13.2
ProductVersionExtra: (a)
BuildVersion: 22D7750270d

Build version looks like a feasible solution, or searching for matching ProductVersionExtra values.

[erikng]

Note that RSRs only apply to the latest minor. So you have to be careful how you implement nudging for one

This is going to require A LOT of work and thought before I implement it.

[erikng]

Apple does not plan to disclose the security changes a RSR contains. We will however continue to document security changes in HT201222 when they're included in a subsequent software update.

I am not incentivized to support this if they are going to be cagey about what it fixes.

[colorenz]

Quick idea add a new key to nudge to a BuildVersion?

[erikng]

That's just one aspect. I have to tie it to all the logic.

[aysiu]

There's a lot of extra potential for Nudge admin user error, too.

Right now, you could have targeted OS version rules that say everyone has to be on 13.3.1, whether they're on 13.3, 13.2.1, or even 12.6.5.

But if you say "everyone" has to be on 13.3.1 (a), it will just confuse your users, as they won't see 13.3.1 (a) until they're on at least 13.3.1.

Not saying that means Nudge shouldn't support this, but it definitely adds more complications.

[loceee]

I was under the impression these could be delivered without out a reboot - which at least for this RSR - is a nope. Both my Mac and iPhone restarted during deployment and I was prompted for the volume owner credentials on my Mac, and my passcode on iOS.

Now we've seen one in the wild I can only ask why the heck does the RSR in this form even exist? This generates confusion for users and more overhead to Apple admin's already mostly toasted software update and reporting processes. I don't care how different or clever it is under the hood, the user experience is naff.

It should have just been 13.3.1.1 - users would have understood it was a software update they should just install. Patching our fleets and most version comparison code in our management tools probably would have kept working too.

This is just yet another poorly conceived idea that makes me want to go and make cheese for a living.

[robban247]

In my mind RSR could be handled by Nudge in a different/separate way.

Simply put i think it can be done with some (global - non-rule related) preferences;

1. One key to disable/enable RSR functionality.
2. One key to set the number of hours/days for deadline for the RSR. (Nudge could check the date the RSR was discovered by the device and add the deadline accordingly)
3. Separate RSR keys for displaying some other text for the end users telling them about the urgency of this update.

If key 1 was set to enabled and key 2 was set to like 72 then Nudge would otherwise behave according to the your other preferences regarding approachingWindowTime and so on.

I think the key here is that end user should be presented with an separate message that is different from the more default message (I think a lot of admins use) that are more general for regular updates. In this way they can be to told that this update is urgent and one can explain to them why they have to upgrade from 13.3.1 to 13.3.1 (a) already a few days after getting to 13.3.1.

No idea if this can ble implemented or not - just putting my idea out there for what it is worth.

[mimscalepoint]

So for now, Rapid Security Response updates are not supported. Is this correctly understood?

[bp88]

@loceee my only comment is that this should not have been 13.3.1.1 but rather 13.3.2. Versions should increment up in a consistent manner with numbers. Why Apple has decided that RSRs should use letters is beyond me. But here we are. I won't even touch on the requirement that RSRs have to restart. Seems like a benefit only to the developers at Apple and not for the end users. To their credit, the update is much quicker, but that's about the only benefit for end users imo.

[James-von-Detroit]

@loceee my only comment is that this should not have been 13.3.1.1 but rather 13.3.2. Versions should increment up in a consistent manner with numbers. Why Apple has decided that RSRs should use letters is beyond me. But here we are. I won't even touch on the requirement that RSRs have to restart. Seems like a benefit only to the developers at Apple and not for the end users. To their credit, the update is much quicker, but that's about the only benefit for end users imo.

I'm going to guess that 13.3.2 as a code stream is different and wasn't ready. Hence the (a) or rapid response to plug a hole quickly in 13.3.1 and not create a new stream. But yeah, i agree.

This isn't good and doesn't exactly allow us to be "rapid" about this situation... Seems like we're stuck until 13.3.2 comes out...

Anyone have a workaround on making Nudge come up and enforce 13.3.1 (a)?

[revaniki]

hi folks, wanted to provide some perspective from the corporate security pov in our partnership with @aysiu. Albeit Apple has yet to provide declarative clarity on the impact of RSR, the framing of this vulnerability and patch class gives security folks the strong impression that these matter and should be handled in an expedited manner. We will talk to our apple enterprise rep to share the feedback, however from the perspective of a large mac install base that uses nudge, supporting RSR would be highly appreciated.

[erikng]

PRs are welcome :) 99% of the code is maintained by me and thinking through this as a solution is not going to be easy.

I have other security issues internally at Uber that I have to prioritize over this and the risk to companies is unclear as there are no CVEs posted. I have a hard time dropping everything for likely weeks/month of work for something that is likely changing in macOS 14.

This may be the only RSR issued for macOS 13. Id rather use a "wait and see" approach for now unless someone is willing to co-author this feature with my guidance.

[dan-snelson]

I nominate Bart Reardon.

[loceee]

I concur with @erikng. I’d wait and see if we see
any more of these before exerting effort. I’d also suggest we all file feedback that the user and admin experience of the current implementation of RSR is far from exceptional.

[mobofixer]

Not sure how this can be implemented because if you are 13.2 and update to 13.3.1, the RSR is not included. It is not until you are on 13.3.1 that you will even see the RSR. So nudging someone who is out of compliance will have to do 2 updates essentially.
Even when you wipe a computer on 13.3.1(a) it reverts to just 13.3.1 and you have to reapply the RSR once you get the computer set back up.

[aysiu]

For what it's worth, I just did an Erase All Content and Setting on 13.3.1 (a), and it's still on 13.3.1 (a), but the rest I fully agree with.

[rougegoat]

Looks like Apple released another RSR that requires a reboot to install. Have they provided any information on how this will be implemented through macOS 14? No sense building support for these (a) updates if later on they're going to be full version number bumps.

[addihetja]

Apple hasn't published an updated version of their Platform Security guide, but from I have been able to gather from WWDC videos and The Eclectic Light Company, RSRs are here to stay.

In macOS 11, Apple started using something called Signed System Volume (SSV), which necessitates a whole System partition replacement when you need to update components on the System partition. Replacing the whole partition is the reason why small updates like 13.4.1 are gigabytes in size.

From my understanding, RSRs fall in between the old method, where Apple would deliver a "delta updater" consisting of a .pkg that updates individual files and the new method, which replaces the entire System partition with a new one. From my understanding, Apple is now able to install small updates that are megabytes in size, instead of gigabytes, by installing them what Apple is calling Cryptexes on the Preboot volume that are cryptographically verified at boot time and grafted on top of the code that is already installed. When Apple delivers an update to vulnerable code on the System partition (f.x.), the old vulnerable code is still there after the RSR has been installed, but it is completely covered by the new code contained in the grafted cryptex that got installed, effectively neutralizing the security risk. The reason why the "patch version" (the ".1" in "13.4.1" isn't bumped is because of how the update is delivered.

This allows Apple to rapidly install small update without bogging down the network. Yes, RSRs (usually?) require a reboot, but they are arguably much lighter on their feet than the super-heavy complete updates we got with macOS 11 and more granular than ye olde Combo updates we had back in the bad old days.

Should Apple have used Semantic Versioning? Probably not, because the fourth element of SemVer [usually] denotes a build, which is something that an RSR is not. Instead we get this confusing thing from Apple that we all have to live with.

References:
https://developer.apple.com/videos/play/wwdc2022/10045/
https://eclecticlight.co/2023/04/05/how-cryptexes-are-changing-macos-ventura/
https://eclecticlight.co/2023/05/02/what-is-a-rapid-security-response-rsr/
https://en.wikipedia.org/wiki/Software_versioning#Semantic_versioning

[colorenz]

Hi,

@erikng develops Nudge in his free time, he is not paid for it and does not get any money for it.....
So if the feature is so urgently needed for you and your organistaiton, help him and make a PR. ;-)

Best Regards
colorenz

[aysiu]

I think one of the technical challenges here is that Nudge seems to be leveraging a built-in property called OperatingSystemVersion

The Apple Developer documentation doesn't seem to have that include Rapid Security Responses or have a native RSR object, so if I'm understanding the situation correctly, Nudge would either have to rewrite getting the OS version by combining the native property with some hack of parsing sw_vers -productVersionExtra or just parse sw_vers for everything and ditch the native property. Neither seems ideal, again, if I'm understanding the code correctly.

[erikng]

I'm going to close this as it's quite apparent RSRs in their current form are dead.

[loceee]

So long and a good riddance. Haha!