There were three potential vulnerabilities reported in macOS 10.14 Mojave’s new privacy protection. Two, discovered by Patrick Wardle and Jeff Johnson, were not disclosed, to allow Apple to address them, and the third, in ssh, was not so much a vulnerability as a feature which could be exploited. This article considers whether the 10.14.1 update addresses them.

The most obvious way to start would have been to check Apple’s Security Notes on that update. The only mention there is of one vulnerability which was reported by Patrick Wardle affecting the Dock:
Dock
Available for: macOS Mojave 10.14
Impact: A malicious application may be able to access restricted files
Description: This issue was addressed by removing additional entitlements.
CVE-2018-4403: Patrick Wardle of Digita Security
That suggests that at least a part of the vulnerability which he reported may have been addressed.

Those Security Notes don’t mention any change in the behaviour of ssh. Although I had a confusing experience testing this out recently, it now appears that, despite updating some of its components, Apple hasn’t changed the behaviour of ssh or sshd since 10.14.

Neither is any credit given to Jeff Johnson, nor is there an entry which refers to the bug which he reported. Jeff Johnson has now published an account of his vulnerability, which he states is fixed following the 10.14.1 update. In essence, what his code did was to call the automator command tool to run a workflow to copy items from a protected folder (the Address Book) to an unprotected location, the Desktop. This uses a calling chain
testapp ➜ automator ➜ workflow

In TCC’s terms, it should have been asked to authorise that workflow being run by automator; as that is a command tool, TCC should have looked up the attribution chain and discovered that testapp didn’t have access to the protected folder, so presented the user with a consent dialog. In 10.14, there appears to have been a bug in which the workflow was allowed to proceed without consent being sought.

Jeff reports this behaviour has changed in 10.14.1, and the consent dialog is now correctly triggered. So this bug in TCC is fixed, and it would be good if Apple were to record this, with due credit to Jeff Johnson, in its Security Notes.

It’s hard to know why that bug existed in the first place, but my guess is that TCC was using the wrong attribution chain, and maybe arriving at an app, such as Automator.app itself, which was already on the Full Disk Access list. This doesn’t look as if it is the first example of a whole family of undiscovered vulnerabilities, and I’m sure that Apple’s security engineers have looked carefully for related flaws.

Jeff raises two other issues which are worth considering whilst we’re here.

The first is a ‘denial of patience’ attack, in which malware could keep using tccutil to reset privacy settings, forcing so many consent dialogs to be triggered that the user eventually gives their consent to allow the malware access to protected data. I think that this would require very careful psychological engineering: even the most pressured user would quickly recognise that something was amiss, which might make them more rather than less alert to the stream of dialogs.

It is his last example which I think is most important for Mac users: the hidden dangers of giving apps Full Disk Access. In this, he proposes a malicious app which ‘piggybacks’ onto Terminal.app to get it to do its dirty work. The calling chain here is
testapp ➜ Terminal.app ➜ shellscript

If the user has already given Terminal Full Disk Access, or more specific access to protected data, the attribution chain will take the shell script’s request back to Terminal, where consent will already have been given, so access will be allowed to proceed.

One good thing is that, at present, there doesn’t seem to be any way for an app to check TCC’s list of apps with Full Disk Access, or any other form of protected access. This would put the malware at risk of advertising its activity, which might best be buried in a short ‘denial of patience’ attack to disguise it and mislead a user to give unwitting consent.

This is the type of attack of which the security engineers are constantly mindful, and why Apple has been so reluctant to give any apps ‘easy’ access to user consent or user-controlled privacy settings. The moment that an app can discover those settings or manipulate them directly, those techniques can be exploited in attacks too.

The most important lesson is that, if you want TCC to protect your privacy, you shouldn’t give many (any?) apps free rein over protected data unless their access is really necessary, and once that need has lessened, you should open your privacy settings and turn access off. And don’t start wishing that that could be scripable, because the moment it was, that too would be exploited. Much of your privacy protection has to be manual and ponderous, as the quicker and more programmable it became, the greater it could be exploited.

According to beta testers, macOS 10.14.2 will bring a new version of TCC’s security data. I suspect that there will be further changes in its behaviours, and more bugs will have been fixed. It will be interesting to see what changes in privacy protection come with that next update.

[Amended 11 November 2018 to correct status of ssh.]