In case it slipped your attention, macOS 10.14.5 brings major changes in security. Not the full mitigation against MDS, another new tranche of vulnerabilities in Intel processors, but in kernel extensions and some apps. And I’m bewlidered at how Apple has announced them.

MDS is the latest in a series of design blunders made by Intel in its processors. Unfortunately, it affects hyper-threading, a feature on which modern CPUs rely for much of their performance. The only workaround, at least for the moment, is to disable the feature altogether, which Apple’s testing suggests leads to a reduction in performance by as much as 40%. So the only users who are likely to want to do this are those who could be specifically targeted in attacks, such as senior figures in government and industry. For that small elite, Apple provides detailed advice.

For the rest of us, much greater impact is already occurring because of Mojave’s new policies on kernel extensions. As I’ve been unable to find any articles from Apple informing users of this, I’ll try here to explain what has happened.

Prior to macOS Mojave 10.14.5, kernel extensions were already tightly controlled. Developers had to ask Apple to grant them special code signing certificates in order to sign them, and when a user wanted to install one, they had to give their explicit approval in the Security & Privacy pane. This was documented in developer technical note TN2459, which is now no longer being updated, leaving a void.

When Apple started to release betas of macOS 10.14.5, it announced to developers that when that update was released, two groups of software would need to be notarized using Apple’s Notary Service: all new kernel extensions, and first releases from new developers. I think it’s fair to say that this took developers by surprise, as notarization was only expected to become mandatory for apps distributed outside the App Store in the release of 10.15, anticipated this coming autumn/fall.

Apple didn’t, though, reveal when 10.14.5 was going to be released, nor did developers know until it appeared in Software Update on 13 May. There’s no mention of these changes, nor of their impact on users, in the few lines which Apple refers to as “detailed information about this update” at this page. However, information is slightly more forthcoming in Apple’s developer release notes, where a new security feature is announced:
“Kernel extensions signed after April 7, 2019 must be notarized in order to load on macOS 10.14.5.”

Within a very short time of the release of the 10.14.5 update, some Mac users started installing Oracle VirtualBox 6.0.8, which was unfortunately released the following day. It’s unclear whether this complies with the new notarization requirement, but those trying to install this new version discovered that they couldn’t do so on Macs which had already been updated to 10.14.5.

I don’t know the origin of the information (I suspect a leak from Apple), but some users then learned – not from Apple or Oracle support, though – that they could work around this block by restarting in Recovery mode, there typing the following command in Terminal
spctl kext-consent add VB5E2TV963
and restarting. Others, perhaps lacking that advice, discovered that disabling SIP from Recovery mode using csrutil disable allowed them to install and run VirtualBox, but once SIP was re-enabled the problem returned. Some Mac users found that ATTO kernel extensions failed too, although I’m not sure of the cause of that.

Further evidence of this change came in an undocumented part of the 10.14.5 update: replacement of the data used in the macOS KEXT block extension at /System/Library/Extensions/AppleKextExcludeList.kext. Fortunately this is one of the macOS components which is watched by my free LockRattler utility, and I was surprised to see not only its version number substantially incremented, but to discover that this kernel extension had a whole new file listing signatures of over 18,000 existing kernel extensions which have apparently been granted exceptions to the new notarization requirement.

Without informing developers, system administrators or users, Apple has switched from a short blacklist of known incompatible extensions, to that and a huge and largely historical whitelist of all the KEXTs it knows about. But not, apparently, including that for Oracle VirtualBox 6.0.8.

Apple has also warned developers of a “known issue” (bug to you and I) which can result in newly installed kernel extensions failing to load if Internet access isn’t available. This is because ‘Gatekeeper’ fails to register notarization properly for installer packages which aren’t scanned by it. To work around this bug, developers have to create a preinstall script to register the notarization during the install process, and include that in their installer.

macOS 10.14.5 thus introduces three changes which can cause installation of software containing a kernel extension to fail:

• the new kernel extension whitelist,
• the requirement for notarization of all new or updated kernel extensions as of 7 April,
• the bug which fails to register notarization properly in some cases.

What Apple hasn’t even informed developers about is the biggest change in Mojave’s security. When amfid calls for first run checks in macOS 10.14.5, not only does it now check notarization (showing the new modified dialog on app first run), but in some circumstances it will now block loading of code which hasn’t been notarized, either in a new kernel extension or an app signed with a new developer ID.

When Apple told us almost a year ago that it would be making notarization mandatory in some future version of macOS, I doubt that many would have expected it this early. But here we are, on the verge of the next WWDC, and Apple has introduced mandatory notarization, albeit for two limited classes of software, in macOS 10.14.5. Without so much as mentioning it to macOS users, unlike its detailed information on MDS. I think that’s completely the wrong way round. Don’t you?