At first sight, it might look as if the vulnerability discovered by Sarah Edwards last week, in which passphrases for encrypted APFS volumes were written in plain text to the log, was not only another serious blunder in High Sierra, but also an alarming failure to warn users. Having dug around a bit and a bit more, I’m beginning to think that Apple may have been as surprised as we were to hear about the bug.

The basic facts are open to interpretation and misinterpretation.

Guilty?

From its release as macOS 10.13, and possibly through the beta releases too, High Sierra’s Disk Utility happily wrote the plaintext passphrase of each APFS encrypted volume which it created into its unified log. Anyone with local access to that Mac as an admin user could then extract the passphrase from the log, and use it to gain access to the encrypted volume.

This vulnerability remained in Disk Utility (and the tools which it uses to perform APFS operations, notably diskmanagementd) through macOS 10.13.1, which included the Supplemental Update of 5 October, 10.13.1 itself on 31 October, Security Update 2017-001 on 29 November, and wasn’t fixed until macOS 10.13.2 on 6 December 2017.

Despite searching the security release notes for those updates, I can find no mention of this bug and vulnerability, nor of it being fixed in 10.13.2. The release notes for 10.13.2 have been well-maintained since their release, receiving updates on 21 December 2017, 5 January 2018, 10 January 2018, 11 January 2018, 22 January 2018, 14 February 2018, and 14 March 2018 (which seems an exceptional circumstance in itself).

I have been unable to find any warning published by Apple of the fact that the logs of a large number of Macs would have contained encryption passphrases in plaintext.

If you want to jump to a conclusion, it might be that Apple thought that, as it had fixed the bug in 10.13.2 and no one had reported it, no one was aware. As unified log files are usually deleted automatically after about twenty days, by about Christmas all those plaintext passphrases would have vanished, and no one would be any the wiser.

Except, of course, that anyone who hadn’t updated to 10.13.2 would still have the vulnerability, and anyone who made a logarchive of their log before the passphrases were aged out would have retained those leaked passphrases in the logarchive. And, as we now know, the bug was only ‘fixed’ when creating a new volume; erase an existing APFS volume to encrypt it and the bug persists even in 10.13.3.

Innocent?

I think that there is an alternative account which is far more probable, in which Apple was unaware of this vulnerability until Sarah Edwards discovered it on 21 March 2018.

Disk Utility and StorageKit were little more than kludges in the early releases of High Sierra. The Supplemental Update of 5 October fixed a glaring vulnerability which could reveal encryption passphrases, and a number of other serious bugs were fixed in 10.13.1, although none were listed in its sparse release notes. The version of Disk Utility which fixed this particular vulnerability was 17.0 (1635), compared with 17.0 (337) in 10.13.1. For the build number to have risen from 337 to 1635, Apple’s engineers have been building long and hard.

Looking at the log entries made by these initial versions of Disk Utility and diskmanagementd, they hand off the three key steps in creating an APFS encrypted volume to external tools: first to newfs_hfs, presumably to initialise the disk, then to newfs_apfs to create the APFS Container, and finally to newfs_apfs a second time to create the encrypted volume.

That third step appears to have been a kludge, which was replaced by a more secure mechanism in Disk Utility 17.0 (1635), in 10.13.2, which only performs the first two steps using an ‘open’ execve() call.

I suspect that the engineers responsible for fixing those early releases of Disk Utility were either unaware that the third step wrote the passphrase in plain text to the log, or were unmindful of the impact of so doing. I think it most probable that they improved that third step to turn what had been an interim kludge into a better and more lasting solution, not specifically to prevent the leaking of the passphrase. Furthermore, they appear to have forgotten that encrypting an existing volume uses very similar code, and haven’t got round to securing that yet.

Supporting my contention is the fact that the fix, as implemented, only addresses half of the bug, in which the volume encryption should not have proceeded through this ‘open’ calling of newfs_apfs. The other half of the bug is that the execve() call from diskmanagementd should not have deliberately made public its dynamic string, which would by default have been censored from the log entry. That clearly remains, as it is still the behaviour shown in the first two steps in 10.13.3, and is in all three when encrypting an existing volume.

I think that Apple fixed this vulnerability by serendipity, in the course of fixing other bugs in Disk Utility, and therefore remained unaware of this large leak of passphrases until 21 March, more than three months later, when Sarah Edwards discovered it.

Apple still needs to come clean and explain fully to users what happened, what the consequences are now, and when the remaining lesser bug will be fixed too. However, there is a world of difference between Apple having been fully aware of those consequences for around four months and deliberately keeping quiet about the issues, and learning about them a few days ago. I hope that my confidence is not misplaced.