Anthony’s Mac Labs Blog

Posted 2017 August 05

Apple has been providing security updates for the current macOS and any major version released within two years of the release of the current OS. Since Apple adopted an annual OS release schedule, that has translated into security updates for the terminal release of the previous two major OS versions.

Well, some security updates.

Both when El Capitan was the current OS and now with Sierra, there has come a point where one or more security patches has not been ported back to the previous two OSes. It is, of course, possible that the vulnerability or vulnerabilities in question did not exist in those previous OSes. But those in the Mac Admins community that dig deep on security issues are operating on the assumption that only the current OS is patched for all publicly-shared vulnerabilities. There are two very specific firmware updates that I want to address in this regard.

The Mac’s Boot ROM

Periodically, Apple will release an EFI firmware update to address an issue in the Boot ROM. Until 2015, Apple would often offer these as standalone updates, but the pattern now is to roll them into OS and security updates. These firmware updates are redundantly included in future system updates (e.g., if you had missed the firmware update in 10.12.4, you would still get it if you moved from 10.12.3 to 10.12.5, even though most Macs didn’t change firmware in 10.12.5). This new practice is beneficial for end users, as it is one less update they need to worry about; if observant, they might notice that their computer reboots twice when applying the latest system update, but it requires no additional intervention on their part. This increases the odds that the user is running a secure system. For the Mac Admin, this does require that you have disciplined workflows.

If you deploy images, regardless of whether you build them modularly using a tool like AutoDMG or you still capture the boot volume of a “Golden Machine” using a tool like DeployStudio or Carbon Copy Cloner, the firmware update will not be applied to the Mac when you deploy your image. You need to run the actual system software update on the target Mac, then deploy the image. (Of course, if your image contains a version of the OS that has not had all of its security/minor version patches applied, running Software Update after you deploy the image will have the same effect.)

Further complicating matters, the firmware offered for your Mac model may vary depending on the version of the OS you are running. That’s right, if you are running El Capitan or Yosemite and have applied all of Apple’s security updates, you may not have the most current version of the firmware for your Mac. Pepijn Bruienne has created an excellent spreadsheet listing all the firmware updates by Mac model and OS/Security release where you can see those differences. Based on the patterns you see there, it certainly appears that Apple prepares the security fix for the current OS and if the fix for the two older OSes can be ported back and tested without significantly holding up the release, they release it at the same time. If not, they don’t release it or release it later. For example, let’s look at the EFI firmware version history for the Mac mini (Late 2012) in front of me as I write this:

Originally, I speculated that Apple was freezing firmware at the version that existed when the terminal version of the OS was released, but in the example you see above, they broke that pattern when 10.12.5 / Security Update 2017-002 was released, at least with El Capitan Macs. Nevertheless, this pattern does suggest that if you are not running the current major version of macOS, your Mac may still be susceptible to a known security vulnerability.

BroadPwn: Similar but Different

One of the most notable security vulnerabilities discovered recently is BroadPwn, named after the Broadcom WiFi chip that is targeted by this exploit. This attack is a little different in that you need to be in physical proximity to the device (WiFi range). Nevertheless, a broad number of devices use the Broadcom 43xx series WiFi chip (including the phone you might have in your pocket), making it an attractive target. Apple rolled out a fix for iOS in 10.3.3 and also released a patch for Macs running Sierra that used the vulnerable series of WiFi chips. Based on some of the data that Michael Lynn collected from the community, it appears that the patched Broadcom WiFi firmware is loaded dynamically by the operating system. This was supported by my testing, where System Information (system_profiler) reported an earlier Broadcom firmware version when I booted from an earlier operating system (Yosemite) on a Mac whose normal boot volume was a fully-patched version of Sierra.

So there seems to be two ways to avoid the BroadPwn vulnerability on your Mac: upgrade to 10.12.6 or don’t use WiFi. (There was a discussion in the MacAdmins Slack #security channel that suggested you could confirm the vulnerability in older OSes using the method described by Zhuowei Zhang online. Until someone chooses to do that, we’re making an educated guess based on Apple’s release notes and the evidence we have collected. The community is pretty certain, but not 100%.)

What To Do? What To Do?

The situation at this moment for Mac security patches should be a bit of a wake-up call for Mac Admins, especially those involved in mass deployment. Here are my main takeaways:

• If APFS doesn’t kill imaging, the need to keep your Macs secure will.
  To Do: Work on modular and no-imaging workflows, even if they are not your production workflow right now. Make certain your production workflow delivers all firmware updates.
• If you have hardware whose terminal OS is 10.11 El Capitan, replace that 7+ year old hardware as soon as possible (unless you’re OK using it without an Internet connection).
  To Do: Have a security discussion with the people preparing the budget.
• In Education, we need to be prepared for a mid-year OS upgrade, even if we’ve always waited until the end of the school year to do it; security needs might force our hand.
  To Do: Create a macOS testing strategy if you don’t already have one. Have a goal of being ready to support the next major OS release within X number of days of release, with X = as close to 0 as possible (macOS Beta testing must be an active consideration).

Updated 2017-08-06 to make the EFI firmware table show up better on small screens. Caption altered to reflect the change.