MacInTouch Amazon link...

Apple security and privacy

Channels
Apple, Security
This may seem like a stupid question, but should I install the new macOS 10.14.6 update over the old one or just leave things alone?
There is no new macOS 10.14.6 update.

The updates only involved macOS 10.12.6, 10.13.6 and BridgeOSUpdateCustomer for some people with a T1/T2 Mac.

If System Preferences > Software Updates tells you that you need something, go ahead and install it — otherwise, "just leave things alone".
 


I guess it's installed in the invisible EFI partition — the first partition on the drive. ...
One other thing that might help here: Although EFI is uploaded to a normally hidden partition of the boot drive, it's just an interim placement which is transferred to the computer's firmware at first boot after a change.
On a typical EFI-based PC, the EFI partition contains extensions to the motherboard's ROMs in order to provide support for add-on hardware and bug fixes for the ROM-based firmware. During the pre-boot sequence, the ROM-based firmware will load device drivers from that partition in order to make the associated hardware available to the operating system's boot loader.

On Macs, however, Apple puts all of their firmware in the BootROM (flash memory on the motherboard, separate from any SSD that may be present). Third-party hardware that is to be used during the pre-boot sequence must have extension ROMs containing the drivers (which is why video cards without Mac-compatible ROM code don't work until after macOS loads). If you mount the EFI partition, you will almost certainly find it empty. As far as I know, if you try to manually put an EFI driver in there, it will be ignored by the BootROM and won't actually load.

As I understand it, Apple's firmware updaters may use the EFI partition as temporary storage while performing the firmware update, but that update will write the updated firmware into your BootROM storage. Once the BootROM is updated, those files will be deleted from the EFI partition.
 


Ric Ford

MacInTouch
Marcel Bresink, who created TinkerTool and other Mac software, posted some helpful notes (emphasis added):
Marcel Bresink Software-Systeme said:
Blog

July 29, 2019:
Apple releases new software via macOS Software Update:
  • Security Update 2019-004 for macOS Sierra (Update Product ID: 041-93815)
  • Security Update 2019-004 for macOS High Sierra (Update Product ID: 041-93819)
  • BridgeOS Customer Update (Update Product ID: 041-93793)
  • Whitelist for Macintosh firmware security checks (“EFICheck AllowList”), version 71 (Update Product ID: 041-82043)
BridgeOS is the secondary hardware management operating system running on the Apple T2 processors of selected Macintosh model series.

July 24, 2019:
Apple has officially withdrawn the following updates, originally published on July 22:
  • Security Update 2019-004 for macOS Sierra (Update Product ID: 041-59910)
  • Security Update 2019-004 for macOS High Sierra (Update Product ID: 041-59906)
  • BridgeOS Customer Update (Update Product ID: 041-51542)
These updates are known to cause operating system crashes on specific Macintosh model series.
...
July 22, 2019:
Apple releases new software via macOS Software Update:
  • macOS Mojave 10.14.6 Update (Update Product ID: 041-88928)
  • macOS Mojave 10.14.6 Combo Update (Update Product ID: 041-88925)
  • macOS Mojave 10.14.6 Upgrade for users of macOS Sierra (Update Product ID: 041-88929)
  • Security Update 2019-004 for macOS Sierra (Update Product ID: 041-59910)
  • Security Update 2019-004 for macOS High Sierra (Update Product ID: 041-59906)
  • Safari 12.1.2 for macOS Sierra (Update Product ID: 041-62930)
  • Safari 12.1.2 for macOS High Sierra (Update Product ID: 041-56829)
  • BridgeOS Customer Update (Update Product ID: 041-51542, 041-88933)
  • Gatekeeper version 173 Configuration Data (Update Product ID: 041-88218)
  • Command Line Tools for Xcode 10.3 and macOS 10.14 (Update Product ID: 041-86543)
 



FWIW, here's what the EFI partition on my Mac Pro 6,1 looks like. Not entirely empty, but not much there, either.
Interesting. I wonder if a system update was interrupted during an update, since you've got all those cache files.

But it does appear that Apple is putting something in there these days. The last time I checked, my EFI partition just had a few empty directories, but I just checked on my system (2011 MacBook Air running Sierra):
Bash:
diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *121.3 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Grover                  120.5 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

sudo mount -t msdos -o rdonly /dev/disk0s1 tmp
cd tmp
ls -Rl
total 1
drwxrwxrwx  1 dcharlap  staff  512 Mar 31  2017 EFI/

./EFI:
total 1
drwxrwxrwx  1 dcharlap  staff  512 Jul 29  2017 APPLE/

./EFI/APPLE:
total 2
drwxrwxrwx  1 dcharlap  staff  512 Mar 31  2017 EXTENSIONS/
drwxrwxrwx  1 dcharlap  staff  512 Jul 29 22:28 FIRMWARE/

./EFI/APPLE/EXTENSIONS:
total 30722
-rwxrwxrwx  1 dcharlap  staff  15729264 Jul 29 22:34 Firmware.scap

./EFI/APPLE/FIRMWARE:
total 16514
-rwxrwxrwx  1 dcharlap  staff  8454768 Jul 29 22:28 MBA41.scap
A copy of Firmware.scap can be found in /usr/standalone/i386.
MBA41.scap is definitely hardware related (since the computer is a MacBook Air 4,1).

Which is very interesting. One of the things Apple used to write about is that their BootROM code understands HFS+ (and now APFS) and therefore doesn't need a FAT-formatted partition (the EFI partition) to hold the bootloader and related code.

The files are dated this past Monday night, when I installed Security Update 2019-004 and I didn't interrupt the upgrade. So now the big question is if they are actually being used or if they are temporary files that didn't get deleted.
 


El Capitan's last security update was released in July 2018 (Security Update 2018-004 El Capitan), which leads me to wonder if this month's Security Update 2019-004 will be the end of the road for Sierra. Even if it's not, it seems prudent for Sierra users to start giving some serious thought to when/whether they will move to a newer OS.

I really wish Apple would publish an official lifecycle support policy for its software, rather than leaving us guessing.
 


Ric Ford

MacInTouch
El Capitan's last security update was released in July 2018 (Security Update 2018-004 El Capitan), which leads me to wonder if this month's Security Update 2019-004 will be the end of the road for Sierra. Even if it's not, it seems prudent for Sierra users to start giving some serious thought to when/whether they will move to a newer OS.
I've been wondering about the same thing. An experimental update to Mojave wasn't great, but I've avoided High Sierra because of its horrendous quality and security problems initially.

I'm wondering if High Sierra is now good enough to replace Sierra (where I'm finding a few bugs, too, in color/display handling and there may be more).

I also wonder about HFS+ vs. APFS for High Sierra. I understand the benefits of APFS (particularly for snapshots, as recently discussed for security and backups), but I don't understand whether or not High Sierra APFS has somehow been updated to the newer APFS code of Mojave, and I'm also not sure whether HFS+ or APFS would be best for a High Sierra boot drive.
 


I've been wondering about the same thing. An experimental update to Mojave wasn't great, but I've avoided High Sierra because of its horrendous quality and security problems initially.
Exactly. I'm not interested in Dark Mode, and the few truly useful new features since Sierra don't seem to outweigh the pitfalls of Apple's increasing focus on pushing consumption of its "services" instead of enhancing productivity.

I hesitate to go any further down the "services" road than is absolutely necessary, which would suggest High Sierra for now, but perhaps it would be better just to suck it up and move to Mojave, accepting the nag messages, "services," and other questionable changes, to avoid having to do another major update later. (Experimenting with the Catalina beta has gone much better than I expected, but I don't see myself moving to it in the foreseeable future, if ever.)

My main personal machine is a mid-2012 MacBook Pro (non-Retina). The apps and documents on its drive can be traced through an unbroken string of in-place upgrades and Migration Assistant machine transfers all the way back to a 12" PowerBook G4 running Panther, so I'm thinking it may be time to clear the cruft and do a full nuke-and-pave clean install of whatever comes next. If I'm going to do the work of a new installation, it seems Mojave would be a better use of my time and labor than High Sierra, at least in terms of how long it will be before Mojave itself reaches end-of-life.

I remember decades of excitedly installing a new version of Mac OS as soon as it was released. The idea that someday I would try to delay installing a new version of Mac OS by years just seems insane to me.
 



A copy of Firmware.scap can be found in /usr/standalone/i386.

MBA41.scap is definitely hardware-related (since the computer is a MacBook Air 4,1).
I discovered the very useful UEFITool, which can unpack .scap files. At least some of the MBA41 contents are updates to the boot ROM, but I’m not sure if any of it is needed after the updates are applied.
 


I also wonder about about HFS+ vs. APFS for High Sierra.
Although my production OS is Sierra, I also have a High Sierra boot drive that I use for testing. Unwilling to try APFS in the early versions of High Sierra, I was able to create an HFS+ drive for it.

I think APFS in Mojave is probably more polished and wonder if any of the changes were backported to High Sierra.

But in the long run, I'll probably install the final version of Mojave on the Mac Pro 5,1. Catalina is not going to be an option.
 


... If you mount the EFI partition, you will almost certainly find it empty. As far as I know, if you try to manually put an EFI driver in there, it will be ignored by the BootROM and won't actually load.....
Even if Apple primarily just uses it as scratch space, it is a useful partition to leave in place. Alternative EFI bootloader applications may use that partition (e.g., rEFInd), and other OS (Windows may stuff some supplementary things there — at least on pre-T2 systems).

However, even if there are no working drives in a Mac system, the computer still should be able to boot into EFI. Nothing critical to booting into EFI should be there, because the drive may not always be there.

For T2 systems, even if there is something there, the system is booting in secure boot mode at least through the EFI stage. Even if there was something there, if it isn't properly signed it still won't get loaded. The T2 puts a barrier by the master copy of the EFI boot image where it can't be directly accessed. The system will get a copy of that to work with when the system boots (so post boot code injections are not [an attack] vector).
 


I did Security Update 2019-004 for both the Sierra and High Sierra boot drives on my Mac Pro 5,1 quad-core 2.8GHz machine today.

The Sierra boot drive is a Samsung 850 EVO SSD mounted on a PCIe card.
The High Sierra boot drive is a Samsung 860 EVO SSD mounted in the SATA bay.

The Sierra update took about 4 minutes. The High Sierra update was longer and took about 9 minutes with one extra reboot. There was no change to the firmware.
Code:
  Boot ROM Version:                MP51.0089.B00
  SMC Version (system):            1.39f11
  SMC Version (processor tray):    1.39f11
The EFI partition -> Firmware.scap was updated on some drives but not all.
 


Ran into an issue last week trying to update our 2018 Mac Minis, which we use for exhibits (at a museum) to macOS 10.14.6 to hopefully fix some display issues we've seen. The downloaded Combo updater just fails with a generic error. Relevant portion of log:
Jul 25 07:36:58 EXH-<ComputerName> softwareupdated[338]: Attempting to adopt manual product: macOS 10.14.6 Update
Jul 25 07:37:12 EXH-<ComputerName> softwareupdated[338]: bridgeOS: Minimum bridge version requirement not satisfied (16.16.6568.0.0,0), will search for bridgeOS update
Jul 25 07:37:12 EXH-<ComputerName> softwareupdated[338]: bridgeOS: Active product _ManualUpdate requires bridgeOS update to version 16.16.6568.0.0,0 or newer. Scanning for active bridgeOS update.
Jul 25 07:37:12 EXH-<ComputerName> softwareupdated[338]: SoftwareUpdate: Could not obtain bridgeOS update required for adoption at /var/folders/zz/zyxvpxvq6csfxvn_n00000s0000068/C/com.apple.SoftwareUpdate/localhost/AdoptedManual/macOSUpdCombo10.14.6.pkg
Jul 25 07:37:12 EXH-<ComputerName> softwareupdated[338]: Manual product is nil, therefore an error occured, stashing token will NOT be created...
Jul 25 07:37:12 EXH-<ComputerName> Installer[19710]: ManualAdoption: Error adopting /Volumes/macOS 10.14.6 Update/macOSUpdCombo10.14.6.pkg: Error Domain=SUErrorDomain Code=605 "An error occurred installing the update." UserInfo={NSLocalizedDescription=An error occurred installing the update., NSLocalizedRecoverySuggestion=}
Jul 25 07:37:12 EXH-<ComputerName> Installer[19710]: ManualAdoption: stashToken is Nil, softwareupdated did not authorize a token, stashing has failed!
Jul 25 07:37:12 EXH-<ComputerName> Installer[19710]: Failed to adopt update: An error occurred installing the update.
After a couple of attempts and getting escalated up apparently to Apple Enterprise Support (we have over 200 Macs and a similar number of iOS devices), the official answer was that the only way to update T2-based Macs is to have Internet access. There is no way to do an offline update.

We keep our exhibit computers on an isolated network for security reasons - no internet access.

I know we aren't the only ones that keep at least some computers isolated from the internet - I've known individuals and companies that keep production computers entirely offline or isolated - no email, no web browsing - and the combo updaters were the way to keep the OS updated (along with app update downloads).

I am trying to escalate to get a solution for true offline updates and have provided feedback through the Apple website, but if they hear from more people that it is an issue, or would be an issue that could keep people from purchasing a new model, it is more likely to be flagged as something they need to do.
 


El Capitan's last security update was released in July 2018 (Security Update 2018-004 El Capitan), which leads me to wonder if this month's Security Update 2019-004 will be the end of the road for Sierra.
Probably, but there is still time before Catalina release if a sufficiently serious vulnerability is found anytime soon. But you have to go all the way back to Mountain Lion to find a Security Update released after July.

In my experience (and that of many other users I work with), High Sierra was a big improvement over Sierra, and at the time I updated, I had absolutely no APFS issues on my iMac with a spinning hard drive that was never reformatted from HFS+. Users who converted to APFS did report access appeared slower.
 



Where did you see improvements, specifically?
Primarily stability. I still see crashes occasionally when I spend time in Sierra that I never found in High Sierra. Most of them occur after I've left my computer overnight without shutting down.

I also experienced issues with background updates not occurring when they should have, but those seem to have been resolved somehow.
 


Ric Ford

MacInTouch
I still see crashes occasionally when I spend time in Sierra that I never found in High Sierra. Most of them occur after I've left my computer overnight without shutting down.
Sierra doesn't crash on me in constant use with lots of sleep and wake and display sleep and wake, plus shutdown/restart usually a few times per day.

However, I did have a pretty nasty problem with crashing/corruption associated with sleep/wake while using a 4K monitor. Switching back to a 1440p display resolved the problem. I haven't had enough free time to go back to try to isolate the cause (but tests indicated that it was not related to SwitchResX).

I also got different crashes while working with settings in System Preferences > Displays > Color, raising more concerns about bugs in Sierra's display/color software.

Meanwhile, I'm having nightmarish Bluetooth problems that started just this month, where I can't pair Logitech Triathlon bluetooth mice for the life of me, even though I'm using one full time on Bluetooth, and I've been able to pair them with Mojave and a fresh Sierra install (not up to date). Hours of troubleshooting and testing many different factors haven't helped.

I just bought a Contour Mouse wired mouse (from Contour Designs) to work around this problem, and the Logitech WiFi receiver security problems, and pain from trying to use Apple's "Magic" Mouse. The wired Contour mouse locks up on wake from sleep, so I have to unplug it and plug it in again to the USB port. I’ve only tried it with Sierra on the iMac, so far.

As noted elsewhere, Spotlight (mds_stores) in Sierra seems to be using a crazy amount of CPU and storage resources.

If High Sierra solved all these problems, has reliable/updated APFS code, and lets me choose HFS+ or APFS, it might make sense to update, though I'm not looking forward to more Apple "machine learning" for silent analysis of personal data of all types, and I don't like the boot delays I've experienced with APFS.
 


Ric Ford

MacInTouch
2017 iMac 5K, running macOS Sierra, after the first Security Update 2019-004 Sierra:
Model Identifier: iMac18,3
Boot ROM Version: 175.0.0.0.0
SMC Version (system): 2.41f1
System Version: macOS 10.12.6 (16G2127)​
Kernel Version: Darwin 16.7.0​
2015 MacBook Pro 15", running macOS Sierra, after the first Security Update 2019-004 Sierra:
Model Identifier: MacBookPro11,4
Boot ROM Version: 194.0.0.0.0
SMC Version (system): 2.29f24
System Version: macOS 10.12.6 (16G2127)​
Kernel Version: Darwin 16.7.0​

I came up with this idea:
  1. Clone the boot drive to a backup clone with Carbon Copy Cloner.
  2. Clone the boot drive to a second backup clone with Carbon Copy Cloner. Set this one aside.
  3. Install the software update (i.e. the second Security Update 2019-004, in this case).
  4. Clone again to the first backup volume with Carbon Copy Cloner with SafetyNet on.
  5. Review the contents of the SafetyNet folder for this latest backup to see what changed in the software update between backups.
2015 MacBook Pro 15", running macOS Sierra, after the second Security Update 2019-004 Sierra (SecUpd2019-004Sierra.dmg, created Jul 29, 2019, 9:00 PM)
Model Identifier: MacBookPro11,4​
Boot ROM Version: 194.0.0.0.0​
SMC Version (system): 2.29f24​
System Version: macOS 10.12.6 (16G2128)​
Kernel Version: Darwin 16.7.0​

What changed between the first Security Update 2019-004 Sierra update and the second, according to SafetyNet? Wow, a lot more than I'd expected... many hundreds (thousands) of files - too many to detail.
 


What changed between the first Security Update 2019-004 Sierra update and the second, according to SafetyNet? Wow, a lot more than I'd expected... many hundreds (thousands) of files - too many to detail.
I suppose I should become more comfortable with SafetyNet before replying, but I'll give it a try anyway.

I do know that the update was recompiled because all the dates that I examined were changed to 7/25, but I didn't bother to check whether the content had changed in any way. If SafetyNet is checking all aspects of those new files, including creation date and inode, then it's not surprising. If it's checking the hash value of the file, then that's what I would be most interested in. If the hash didn't change, then the code wasn't changed, either. Recompiling from source will change the creation and/or modification date. Replacing the file on your drive will change the inode (exact location on the drive).
 


If High Sierra solved all these problems, has reliable/updated APFS code, and lets me choose HFS+ or APFS, it might make sense to update, though I'm not looking forward to more Apple "machine learning" for silent analysis of personal data of all types.
What I normally do in a case such as yours is to install the new macOS on an external drive with a full migration. That will give you an easy way to try all those issues out with an easy way to bail if things don't go well.

It's been a while since I did all that, and, over time, I believe things may have changed with respect to being able to choose HFS+ or APFS, so I'm not altogether certain that's an option any more.
 


Ric Ford

MacInTouch
I do know that the update was recompiled because all the dates that I examined were changed to 7/25... If the hash didn't change, then the code wasn't changed, either.
OK, that makes sense and probably explains why so many files were backed up. I don't know of a simple way to check the hashes of the first Security Update 2019-004 Sierra files vs. the second Security Update 2019-004 Sierra files, though.
 


Ric Ford

MacInTouch
Primarily stability. I still see crashes occasionally when I spend time in Sierra that I never found in High Sierra. Most of them occur after I've left my computer overnight without shutting down.
What Mac are you running it on, exactly, and what are the details of your display? Thanks!
 


Ric Ford

MacInTouch
I didn't realize how much information Bluetooth gives up, and Bluetooth is required for so many things, including Apple Watch pairing, that it can be awkward to keep it turned off, as Dan Goodin reports:
Ars Technica said:
Apple’s AirDrop and password sharing features can leak iPhone numbers
... Simply having Bluetooth turned on broadcasts a host of device details, including its name, whether it's in use, if Wi-Fi is turned on, the OS version it’s running, and information about the battery. More concerning: using AirDrop or Wi-Fi password sharing broadcasts a partial cryptographic hash that can easily be converted into an iPhone’s complete phone number.
 


Ric Ford

MacInTouch
Could Apple's software updates possibly get any more confusing? I guess they could...
The Eclectic Light Co. said:
Apple has pushed an update to Gatekeeper’s data with two version numbers
Apple has pushed an update to the data used by Gatekeeper, bringing its version number to 175, dated 31 July 2019. The last update had taken it to 173. Unfortunately, the installer claims that this update is version 174, but the bundle version is given as 175. This is likely to cause considerable confusion...
Mr. Macintosh said:
New Full Installer of Mojave 10.14.5 (18F2059) released after 10.14.6???
No, we didn’t time travel 3 weeks into the past. A new version of macOS Mojave 10.14.5 (18F2059) was released yesterday.
...
Why would Apple do this? I honestly have no clue! Again since 10.14.6 is a unified build we should have no need for a updated installer of a previous build.
 


I still see crashes occasionally when I spend time in Sierra that I never found in High Sierra. Most of them occur after I've left my computer overnight without shutting down.
Sierra doesn't crash on me in constant use with lots of sleep and wake and display sleep and wake, plus shutdown/restart usually a few times per day. However, I did have a pretty nasty problem with crashing/corruption associated with sleep/wake while using a 4K monitor. Switching back to a 1440p display resolved the problem....
Mojave completely addressed all crashing problems with my D300 Trashcan Mac Pro and a 4K 38" LG monitor. With High Sierra I was seeing a crash an hour and every morning at a minimum.
 


I'd hoped for more specifics when Steve Gibson covered the NAS malware attacks in Security Now Episode #725 "Urgent /11" July 30, 2019, but the QNAP NAS attack was a dictionary attack on weak credentials. Once implanted, the malware ran on the QNAP to encrypt files and phone its status home to prepare for collection of Bitcoin.

Strong credentials and two-factor authentication should be protection against that kind of attack.

Apart from that, Steve did mention 11 critical vulnerabilites found in VxWorks, which he reported is a firmware OS embedded in two billion devices, including the Apple Airport Extreme.

VxWorks has been patched, which may explain the recent and unexpected security update of our old 802.11n Airport Extremes. If so, good on Apple for not leaving them wide open to published vulnerabilies.

Steve publishes transcripts of his Security Now podcasts. His website hasn't been updated to reflect #725, but it is possible today (8/1/19) to find the PDF version through a web search engine. Of course, the podcast itself is available.
 


What changed between the first Security Update 2019-004 Sierra update and the second, according to SafetyNet? Wow, a lot more than I'd expected... many hundreds (thousands) of files - too many to detail.
So, I extracted the entire contents of the SecUpd2019-004Sierra installers, both the old version and the new replacement version, using Pacifist, then compared them with the mtree* command-line utility, comparing size and checksum.

Below is a list of the files that are apparently different. All are in SecUpd2019-004Sierra.pkg, which is one of four installer packages inside the main installer. (The main installer is also named SecUpd2019-004Sierra.pkg.)
  • /System/Library/CoreServices/SystemVersion.plist
  • /System/Library/Frameworks/OpenCL.framework/Versions/A/_CodeSignature/CodeResources
  • /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
  • /System/Library/Frameworks/OpenCL.framework/Versions/A/Resources/BridgeSupport/OpenCL.bridgesupport
  • /System/Library/PrivateFrameworks/Swift/libswiftCoreGraphics.dylib
  • /System/Library/PrivateFrameworks/Swift/libswiftsimd.dylib
Sorry, I don't have the old version of the High Sierra update.

* From the manual page: "The mtree utility compares the file hierarchy rooted in the current directory against a specification read from the standard input."
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts