Congratulations to Sarah Edwards for unearthing a security vulnerability in macOS 10.13 High Sierra, in which copies of old system logs, contained in a logarchive, may contain a plaintext copy of the passphrase used to encrypt APFS volumes.

If you:

• encrypted an APFS volume using macOS 10.13 to 10.13.1 using Disk Utility, and
• have a copy of the unified log collected at the time of that encryption, in a logarchive

chances are, that logarchive will contain the passphrase recorded in plain text. You therefore might like to destroy or encrypt that logarchive.

The bug she has found affected early versions of Disk Utility in High Sierra, up to 10.13.1, but was fixed in 10.13.2. During the process of encryption, Disk Utility called on the newfs_apfs tool (part of APFS) to perform the task using an undocumented option -S. This option took the password in plaintext, and the call was duly recorded in full, including that plaintext password, in the unified log.

You can see this and read fuller details on her blog.

This is a different gaping security hole from that in Disk Utility encryption which was fixed in the urgent Supplemental Update of 6 October, and Sarah has confirmed that this bug persisted into 10.13.1.

If you:

• didn’t encrypt using Disk Utility prior to macOS 10.13.2, or
• don’t have any old logs stored in logarchive files, and
• performed any encryption more than 30 days ago,

then you shouldn’t have any retained plaintext record of your passphrase in an old log file. The unified log normally removes old log files after about 20 days.

However, if you encrypted using Disk Utility in 10.13.1 or earlier in the last 20 days or so, it is likely that your live log files, stored in /var/db, still contain the passphrase in plaintext, and will continue to do so until that log file is aged from your disk. As far as I know there is no documented way to accelerate its removal, and you cannot tamper with the .tracev3 file to remove that information, without damaging your logs. There may be undocumented ways of using the log tool to remove old log files – I am currently looking into those.

I am not aware that Apple has issued any warning of this potential security breach. Given that the bug appears to have been recognised and fixed, that seems more than a little remiss. However, I cannot find any mention of this security fix being made to Disk Utility or any related process between 10.13.1 and 10.13.3 either.

Updated 0600 22 March – this bug was fixed in 10.13.2, which is not vulnerable.