+1Hi Everyone,
With the announcement of the latest zero day, how is everyone going about upgrading there fleet? I have a policy to delay MacOS Minor Version for 30Days, Would that not delay our users receving this new update? or does enabling the box "Allow devices to install Rapid Security Responses (macOS 13 or later) " allow this to happen?
Curious to know how everyone else is handling it. Worse case scenario I can remove the Delay 30 days policy upgrade and put the 30 days back into place
+26I wait for Security to determine the risk of the vulnerability. Not all 0 days are critical to all organizations as some have other mitigating factors. My org did assess the risk and said patch.
My work flow
With how horrible Apple Operating Systems are at allowing us to reliably install OS updates, I usually defer to users for critical updates. Then I will attempt to issue the MDM command to install updates which unfortunately has about a 30% fail rate which is just to high. For users who refuse to patch on devices that don't want to update with MDM commands I have a series of software restrictions in place to block many of our core applications. When a user tries to open the app they are told to run OS updates. Heavy handed? Probably. Does Apple give us better options? No.
I use JAMF Helper to notify users, and set the policy to run once a day on devices not running the desired OS. I need to update this script to check the OS version and exit out if the OS is compliant rather than relying on JAMF data, but it works as is. If on Ventura the script will open system setting software update, I also need to add an if statement to open system preferences software update for Monterey and older but I did not have time to before putting the script in place.
#!/bin/bash
#* FileName: Notifications: MacOS Update Security Compliance
#*=============================================================================
#* Script Name: Notifications: MacOS Update Security Compliance
#* Created:
#* Author:
#*=============================================================================
#* Purpose:
#*=============================================================================
#JAMF Helper
jamfHelper="/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper"
OSVersion="$4" #ie macOS 13.2.1 Ventura
Date="$5" #ie Thursday the 16th
ComplianceDate="$6" #ie Monday the 20th
windowType="hud"
description="Hello,
Technology has identified your computer as needing an important update to $OSVersion to patch Security Vulnerabilities. Your Mac will receive the $OSVersion $Date and will be forced to reboot to install it. You will not receive notification prior to the reboot due to the urgency of this update.
- The update to be installed is $OSVersion
- Mac Policies limiting macOS updates have been temporarily removed
- If you are able, please manually install this OS update as soon as possible, the update will be forced Monday
- Macs that are updated to $OSVersion before Thursday will not be forced to reboot when the OS update command is deployed
- You may update your Mac by opening System Preferences and Navigating to Software Update
- Devices that fail to update to $OSVersion by $ComplianceDate will receive software restrictions until they become compliant
Thank you for helping to make sure that your computer remains updated and secure. If you need assistance, please contact the support center at {some number here}.
"
heading="Critical MacOS Updates: Action Required"
button1="Acknowledge"
button2="Cancel"
icon="/Library/Desktop Pictures/Some_image.jpg"
title="Critical OS Updates"
defaultButton="1"
cancelButton="2"
iconSize="240"
#JAMF Helper
#*=============================================================================
#*Begin JAMF Helper
#*=============================================================================
#Running JAMF Helper
userChoice=$("$jamfHelper" -windowType "$windowType" -title "$title" -heading "$heading" -description "$description" -defaultButton "$defaultButton" -cancelButton "$cancelButton" -icon "$icon" -iconSize "$iconSize" -alignHeading "$alignHeading" -button1 "$button1") #-button2 "$button2")
#Rebooting device or canceling based on user choice
if [ "$userChoice" == "0" ]; then
echo "User clicked Acknowledge, Opening Software Update Preference Pane."
open -b com.apple.systempreferences /System/Library/PreferencePanes/SoftwareUpdate.prefPane
exit 0
#elif [ "$userChoice" == "2" ]; then
#echo "User clicked Cancel; now exiting."
#exit 1
fi
#*=============================================================================
#*End JAMF Helper
#*=============================================================================
+8Yesterday, I started off reading the reports. Since it included an allegedly observed wild exploit of the vulnerability, because it affects all Safari webview implementations and because the update being released means the cat is out of the bag now, I recommended to my boss that we patch immediately. She concurred and I started working.
First an e-mail to all users stating that they must update their devices in the next two days or risk losing access to company resources. While responding "Yes, you too" to everyone, I set up monitoring smart groups on the Jamf dashboard and start downloading the relevant install assistants, in case it comes to that. I start setting up, but not scoping, forced updates in Jamf and new conditional access requirements in Intune.
Just for laughs, I issue mass actions for updates but like @AJPinto I have no hope that they will actually be performed. In a few cases, the mass action at least reminds some 13.1 machines that 13.1 is not, in fact, the latest version of macOS and that they too must update. I spend the rest of the day responding to users who are stuck on the choice of which "disk" to install the update to, who wonder what to do with iPhone 7 or "how long will this go on for?"
I might remind the remaining non-updated users in a moment.
Tomorrow, I enact my threats, scoping patch policies for the four categories of Macs: prestage or user enroll multiplied by Intel or M1 and activate minimum OS requirements for conditional access with a 7 day grace period and two deferrals maximum.
+8Not to be too critical of a fellow admin, but I would never willingly set up a 30 day wait for updates. It is difficult enough getting users to update their OS or applications without us daring to do it either. There's a reason software gets patched and it is rarely for laughs. An organig spread of a few days is fine, but deferring all updates for 30 days after release seems much, much riskier than applying them ASAP.
+26Yesterday, I started off reading the reports. Since it included an allegedly observed wild exploit of the vulnerability, because it affects all Safari webview implementations and because the update being released means the cat is out of the bag now, I recommended to my boss that we patch immediately. She concurred and I started working.
First an e-mail to all users stating that they must update their devices in the next two days or risk losing access to company resources. While responding "Yes, you too" to everyone, I set up monitoring smart groups on the Jamf dashboard and start downloading the relevant install assistants, in case it comes to that. I start setting up, but not scoping, forced updates in Jamf and new conditional access requirements in Intune.
Just for laughs, I issue mass actions for updates but like @AJPinto I have no hope that they will actually be performed. In a few cases, the mass action at least reminds some 13.1 machines that 13.1 is not, in fact, the latest version of macOS and that they too must update. I spend the rest of the day responding to users who are stuck on the choice of which "disk" to install the update to, who wonder what to do with iPhone 7 or "how long will this go on for?"
I might remind the remaining non-updated users in a moment.
Tomorrow, I enact my threats, scoping patch policies for the four categories of Macs: prestage or user enroll multiplied by Intel or M1 and activate minimum OS requirements for conditional access with a 7 day grace period and two deferrals maximum.
The compliance for people with iOS is on Monday for us, update or die. RIP iPhone 7. May you find the headset jack you killed in the afterlife.
Our iOS devices are managed in Intune because its "free" so I dont keep up on them thankfully. However, I was surprised by the number of questions I was asked about the iPhone 7's. I was shocked to see Apple was still updating iOS15 as of last month. Its nice of Apple to have drawn the line and stop issuing updates for iOS15 with a 0-day. A not insignificant number of our iOS devices are iPhone 7's as unlike with the Macs that team does not have a refresh cycle.
+8The compliance for people with iOS is on Monday for us, update or die. RIP iPhone 7. May you find the headset jack you killed in the afterlife.
Our iOS devices are managed in Intune because its "free" so I dont keep up on them thankfully. However, I was surprised by the number of questions I was asked about the iPhone 7's. I was shocked to see Apple was still updating iOS15 as of last month. Its nice of Apple to have drawn the line and stop issuing updates for iOS15 with a 0-day. A not insignificant number of our iOS devices are iPhone 7's as unlike with the Macs that team does not have a refresh cycle.
Yeah I guess we should have replaced those iPhone 7:s as soon as we heard they weren't going to get iOS 16, but there was an iPhone shortage at the time and I had to Configurator non-ADE devices by hand, which is a super annoying process in itself.
The iPhone 7 came on the tail of the iPhone 6s, which was and is the longest-supported cell phone of all time, with the most supported major OS cycles (iOS 11 to iOS 15!). I guess nobody expected Apple to drop the iPhone 7 support any faster than they did the 6s. Apple is basically dropping iPhone 7 at the same time as iPhone 6s.
+26Not to be too critical of a fellow admin, but I would never willingly set up a 30 day wait for updates. It is difficult enough getting users to update their OS or applications without us daring to do it either. There's a reason software gets patched and it is rarely for laughs. An organig spread of a few days is fine, but deferring all updates for 30 days after release seems much, much riskier than applying them ASAP.
Some orgs require testing* and validation before an OS build goes out. We also use a 30 day, but this will be the 4th time in 5 months I have had to back it out. With all the NIST stuff going around now I am tempted to take away the deferral and have Macs auto update as staying totally current is becoming the popular thing to do thankfully.
*not that anyone actually test any of their stuff on macOS, internally I find myself pulling teeth to get business partners to actually test. Nor to any vendors participate in beta seed.
+8Some orgs require testing* and validation before an OS build goes out. We also use a 30 day, but this will be the 4th time in 5 months I have had to back it out. With all the NIST stuff going around now I am tempted to take away the deferral and have Macs auto update as staying totally current is becoming the popular thing to do thankfully.
*not that anyone actually test any of their stuff on macOS, internally I find myself pulling teeth to get business partners to actually test. Nor to any vendors participate in beta seed.
Here's my problem with that idea: That an org in I dunno food sciences or tyre replacement would even have an IT squad with the resources to realistically test and validate an update released and already tested by the pure tech company that made the patch for their own product.
I understand the impulse, but it feels like a total illusion of control. Especially when, as you point out, we keep skipping past the queue when there is real danger.
I have a bigger problem with cosmetic forced-yearly so called "major" updates that add risk rather than fix them, but people want animated smiley face avatars - not security.
+26Here's my problem with that idea: That an org in I dunno food sciences or tyre replacement would even have an IT squad with the resources to realistically test and validate an update released and already tested by the pure tech company that made the patch for their own product.
I understand the impulse, but it feels like a total illusion of control. Especially when, as you point out, we keep skipping past the queue when there is real danger.
I have a bigger problem with cosmetic forced-yearly so called "major" updates that add risk rather than fix them, but people want animated smiley face avatars - not security.
One thing to keep in mind, Apple literally only validates with 1st party software and tools. Apple expects vendors (Microsoft, Carbon Black, Cisco, etc) to validate their software against macOS. I have never seen a vendor validate in AppleSeed, I have been told by Cisco and Lexmark specifically they never validate against Beta OS's and wait for the production release to perform any testing. This means the development for new versions of applications to work with the new version of macOS starts the day you are releasing that version of macOS to your environment. If there is a break, it will take 30 days at least for a fix to be released as a gold standard. Even JAMF which advertises day 1 support, just added support for background services the end of last month or 3 months later.
When you release an update day 0, you are hoping that your non-apple tools will just work with the newer version of macOS. Last year with 12.5 Apple updated CUPS with no documentation to patch PrinterNightmare. If you were using a print server with the PrinterNightmare patch bypassed (as macOS did not support the patch yet) it broke your Macs ability to print. This kind of stuff is found in testing as Apples documentation is crap. If Apple let you roll OS updates back it may not be as big of a deal, but needing to reinstall macOS to remove an OS update is a bit extreme. I get a kick in the fact that it took Apple nearly a year after Microsoft to patch PrinterNightmare, never mind Apple insists they are security first.
I used to work the back office for GoodYear, I would be amazed to see any tire company with a fleet of Macs. Those companies are normally run on a shoe string budget. 15 years ago GoodYear was already running thin clients for POS terminals. (yes, POS stood for point of sale, and the other thing you are thinking of)
Generally speaking the smaller the organization the less testing they probably need to do as the less complex the environment. However for enterprise, the IT infrastructure is usually very complex. A simple update can break syslog redirection or any number of other function and cause a slue of findings. Waiting for a fix must be weighed with the importance of the security patches being delayed.
I have a feeling Apples attempt to acknowledge this is with Rapid Security Response. Which will let you deploy a #.#.1 release without the feature updates. Though to deploy 13.2.1 you still need 13.2 installed. This would let you install 13.2.1 around your OS update deferrals without needing to mess with the configuration profiles. (its not out yet, I'm figuring we will see it with 13.3's feature updates in the spring)
Rapid Security Responses on Apple devices - Apple Support
+26Yeah I guess we should have replaced those iPhone 7:s as soon as we heard they weren't going to get iOS 16, but there was an iPhone shortage at the time and I had to Configurator non-ADE devices by hand, which is a super annoying process in itself.
The iPhone 7 came on the tail of the iPhone 6s, which was and is the longest-supported cell phone of all time, with the most supported major OS cycles (iOS 11 to iOS 15!). I guess nobody expected Apple to drop the iPhone 7 support any faster than they did the 6s. Apple is basically dropping iPhone 7 at the same time as iPhone 6s.
The iPhone 13 and SE2 were available. Not everyone needed the new and shiny iPhone 14, though everyone here also tries to get the brand new and shiny since they dont have to buy it.
The iPhone 6s was a really good phone. Though the 8 years the iPhone 7 got was respectable. However there was probably politicking involved to try to force holdouts to upgrade. Apples direction looks to be going to device as a service to me.
+24Does anyone know if the Safari 16.3 updates for Big Sur and Monterey addresses the same issue on the older OSes? Or, to fix this, will it require all Macs to be upgraded to Ventura 13.2.1? I can't seem to find any definitive information on this, as usual. As stated above, Apple's documentation is really pretty crap on this stuff.
+24Does anyone know if the Safari 16.3 updates for Big Sur and Monterey addresses the same issue on the older OSes? Or, to fix this, will it require all Macs to be upgraded to Ventura 13.2.1? I can't seem to find any definitive information on this, as usual. As stated above, Apple's documentation is really pretty crap on this stuff.
I think I answered my own question, maybe. Apple's security releases page lists the same CVE and fix for both the Safari 16.3 update and the 13.2.1 update, so most likely if a Mac is still running, say, Monterey, as long as it gets Safari 16.3 it should be ok.
https://support.apple.com/en-us/HT213633
That said, I'm still digging into this to find out for sure. If anyone has the exact answer, I'm all ears.
+14@AJPinto and @piotrr, I would highly recommend testing this dumpster fire of an update. There are multiple reports of bricking, booting to recovery, wifi issues, and name changes. Took me a while to get my intel test machine running this morning. I just want some consistency from Apple with these updates. This is ridiculous.
+17@AJPinto and @piotrr, I would highly recommend testing this dumpster fire of an update. There are multiple reports of bricking, booting to recovery, wifi issues, and name changes. Took me a while to get my intel test machine running this morning. I just want some consistency from Apple with these updates. This is ridiculous.
please provide some links to reported issues.. so far we have seen zero..
+26@AJPinto and @piotrr, I would highly recommend testing this dumpster fire of an update. There are multiple reports of bricking, booting to recovery, wifi issues, and name changes. Took me a while to get my intel test machine running this morning. I just want some consistency from Apple with these updates. This is ridiculous.
Oh, I know. I trust Apples "testing and validation" about as far as I can throw them. I had installed it on several devices in my lab. Thankfully I have not noticed any issues. Its installed on about 1/3rd of my environment as of this point and no issues have been reported. I have read others have not been so lucky. You would think Apple having total control over the hardware and software would have OS updates sorted out, but alas this is Apple.
I think I would settle for any consistency from Apple. A roadmap would also be nice, RIP iPhone 7.
+14please provide some links to reported issues.. so far we have seen zero..
It's mostly being reported in Apples private beta channel and in #ventura on Slack. I can't post from the beta channel because I'm under NDA.
+14please provide some links to reported issues.. so far we have seen zero..
+7This happened on my test M1 machine as well. :(
+8@AJPinto and @piotrr, I would highly recommend testing this dumpster fire of an update. There are multiple reports of bricking, booting to recovery, wifi issues, and name changes. Took me a while to get my intel test machine running this morning. I just want some consistency from Apple with these updates. This is ridiculous.
I've had the boot to recovery, but it wasn't recovery per se, it was user authorization for the forced reboot on M1. Is there another boot-to-recovery scenario?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.