There’s been a lot of discussion about the possible benefits and costs of notarization recently. Given that Apple’s Notary Service has been operational since last June, and most details were announced at WWDC 2018, this might seem surprising. You may also have been surprised to read the knowledgeable and insightful Jeff Johnson dismissing much of this as of no benefit, and largely ‘security theatre’. I’m going to disagree here, largely on the grounds that those opinions are based on a narrow view of what happens in Mojave.

There are, and always will be, lots of ways of coming into contact with malware. Apple is, like all platform vendors, constrained in what it can do to protect us from every means of attack. But among the most serious, and potentially controllable, are hijacked legitimate apps. In macOS 10.15, Apple is attempting to control that by restricting the user to running apps which are either supplied by its App Store, or which it notarizes on behalf of those developers who choose or have to distribute outside Apple’s direct control.

Anyone who distributes their own software outside the App Store is well aware of the dangers, as Eltima realised, and Handbrake users discovered. The effort required to protect a limited number of cryptocurrency traders from promiscuously handing round malware is disproportionately great, whereas that to secure hundreds of thousands who use legitimate distribution sources for more prosaic software is much more important.

Currently, it’s relatively easy to distribute malware through a legitimate distributor. What you need to do boils down to:

• Purchase an unused Developer ID and certificates on the black market, which is cheap and easy.
• Obtain the source code to the app, or mimic it, inserting your malicious code.
• Build and sign the hijacked app on any Mac anywhere in the world.
• Replace the genuine app with your malware, either directly on the server or by redirection.

All of these can be performed remotely, by anyone with fairly minimal knowledge and resources.

Notarization doesn’t prevent such hijacking, but makes it significantly more difficult. As I will argue below, Apple’s Notary Service can easily check that the developer certificate matches other details including the app’s signature and location of the build system. To be reasonably confident of notarization being successful, you might need to:

• Obtain the target’s Developer certificate and source code, ideally on one of the developer’s build systems.
• Insert your malicious code.
• Build the hijacked app and submit it for notarization.
• Prevent the legitimate developer from receiving Apple’s notification and email reporting the result of notarization. Note that Apple doesn’t inform the developer just by email, but by a pushed notification too.
• Replace the genuine app with your malware, either directly on the server or by redirection.

Of course, malware doesn’t have to pose as the app which it pretends to be, but users tend to get suspicious if they’ve just downloaded a database which promptly turns out to be BadNewzPhlashInstaler.

This is what Jeff describes as a “true benefit” but “not a huge benefit”. I think that underestimates its impact on the distribution of malware from legitimate third-party sources.

When it comes to security matters in particular, Apple tells us, even developers, what it wants us to know. I’m sure that the notarization process involves some form of scan of each app to try to detect whether it’s likely to behave maliciously. However the very process of notarization gives Apple uniquely detailed information about every single app distributed for macOS. Not only that, but as Jeff describes elsewhere, when each notarized app is first run by each user, macOS ‘phones home’ to Apple.

This gives Apple detail from the moment of submission of the app, to each user running it for the first time, including a complete copy of the app as distributed. If a developer certificate from Fred Wong in Lesotho is used to sign a new version of my app LockRattler on a Mac in Albania, then Apple might be suspicious and refuse that notarization without further information. I believe that Apple’s Notary Service is not just about malware scanning, but detecting developer behaviours which could raise suspicion of malicious intent.

It’s interesting how, more than four months before the likely release of macOS 10.15, Apple is pushing developers to get their apps notarized, even though many of those apps may need to be revised before they’re compatible with whatever changes are to come in 10.15. For two groups – developers who haven’t signed code before, and anyone creating kernel extensions – Apple has without warning brought that forward to the release of 10.14.5. One good reason for wanting developers to get all their software notarized now is for Apple to learn those behaviours and assemble baseline examples of each app before September.

With so many apps to process, Apple is highly likely to be using Machine Learning (ML) in its Notary Service. Training a system to tell genuine software from malware isn’t likely to be too productive because of the very few samples of genuine malware available. Training a system to recognise the notarization behaviours of different developers simply gets better and better as more submit their products for notarization. This is where the fine granularity of notarization is important too: whether Apple would ever revoke an individual version of a product may be moot, but by tracking changes across different versions Apple can learn a great deal about code behaviour.

In the event that a notarized app does prove malicious, Apple then has a full audit trail which includes each user who has run the affected version of that app since notarization – something which has previously hampered every clean-up operation when a legitimate server has been compromised.

Another trap into which we have all fallen in the context of notarization is the assumption that there will no other changes in security in macOS 10.15 beyond making notarization compulsory for downloaded software supplied outside the App Store. Jeff has in previous comments dismissed hardening, a requirement of notarization, as being of no security benefit. In the security environment of Mojave as we know it, that may be true, but that anticipates that the environment won’t change in 10.15.

Like all entitlements and restrictions, they’re only as good as is enforced. Take two of the Runtime Exceptions currently involved in hardening, behaviours which a hardened app must opt into if it intends using them:

• allowing execution of JIT-compiled code, which can permit creation of writable and executable memory,
• disabling library validation, which allows an app to load plugins or frameworks signed by other developers, or even unsigned perhaps.

Both of these have long been known to be serious vulnerabilities which can, and have been, exploited by malware. At present, as far as I’m aware, Mojave can’t enforce either of those limitations of hardening. What if changes in 10.15 enabled their enforcement on hardened apps which haven’t explicitly opted out of that restriction?

Apple has already told developers (last June) that, for hardened apps:
“the system will enforce that every single executable page within your address space must be backed by the original code signature that shipped with your app.” “The system will enforce the code signature of every library, framework, and plug-in that you dynamically load at runtime, and by default will enforce that.” “These objects have to be signed by Apple and shipping as part of the OS – or that they be signed with the same Team ID as the main executable that ships with your app.” (Pierre-Olivier Martel, Session 702, WWDC 2018.)

This could all be hot air, of course. In just over a month we’ll see the first evidence of what the new system will be, at WWDC 2019. All the indications are that hardening and notarization are just part of major changes which we’ll then spend the coming months and years trying to discover in detail. Only then will we be able to judge whether notarization is snakeoil or a valuable advance.