I wrote yesterday that macOS High Sierra 10.13.4 finally fixes the leakage of APFS encryption passphrases into the unified log, and it does. But the ever-vigilant Sarah Edwards has discovered an even more extraordinary bug in High Sierra which has left many encryption passphrases in plain text on many Macs which have used APFS encryption: passphrases didn’t just leak into the unified log, but they were written to /var/log/install.log too.

Sarah Edwards’ article is here, and is essential reading for anyone who has used APFS encryption.

install.log is one of the very few remaining traditional logs maintained since macOS Sierra introduced the new unified log. As its name suggests, it is supposed to contain messages about installations. Writing to it is now significantly more complex than writing to the unified log – as it is no longer supported by any of the regular calls to write to logs. Those are all now diverted to make entries in the unified log.

Unlike the unified log, install.log gets rolled very infrequently. Sarah states that it gets replaced when performing a macOS major version upgrade, e.g. from Sierra to High Sierra, but that is not necessarily so: it can persist across such upgrades. In any case, this release of encryption passphrases was one of the ‘new features’ in High Sierra, so entries from Sierra’s days are of no relevance.

However, unless your Mac has undergone a full wipe and install since installing High Sierra, it is very likely to have an install.log in plain text which retains all entries since it was first upgraded to High Sierra.

Sure enough, in among those entries you will find plenty from services such as storagekitd and diskmanagementd, which have nothing to do with software installation, but everything to do with sensitive tasks such as encrypting APFS volumes.

Until your Mac installed 10.13.2, each time that Disk Utility or diskmanagementd encrypted an APFS volume, there will be an entry in your install.log which contains the passphrase used. Until your Mac installed 10.13.4, there will be an entry containing your passphrase for APFS volumes which were converted from unencrypted to encrypted format.

Although 10.13.4 fixes this leak, it still only does part of the job. It doesn’t roll the install.log to remove all those old plaintext passphrases, which remain in the log for all to see. What is worse, to my mind, is that it doesn’t stop diskmanagementd and associated processes from writing to install.log.

Even after updating to 10.13.4, these are typical entries in my install.log:
2018-03-30 14:55:09+01 Howards-MacBook-Air storagekitd[1179]: Recache Complete, Mount Point: /Volumes/Transit
2018-03-30 14:56:37+01 Howards-MacBook-Air diskmanagementd[1224]: diskmanagement: rawLaunch: execve(2) pid=1224 /System/Library/Filesystems/hfs.fs/Contents/Resources/newfs_hfs -J -v Transit /dev/rdisk3s2 .
2018-03-30 14:56:50+01 Howards-MacBook-Air diskmanagementd[261]: diskmanagement: rawLaunch_block_invoke: waitpid(2) pid=1224 ret/errno=1224/0 status=0x00000000 exit=0
2018-03-30 14:56:51+01 Howards-MacBook-Air deleted[399]: diskmanagement: [DMManager(PrivateMethods) clientConforms:error:]: currentThread=80415=0x13a1f expectedThread=21259=0x530b
2018-03-30 14:56:51+01 Howards-MacBook-Air storagekitd[1179]: Erase Complete, Mount Point: (null)
2018-03-30 14:56:51+01 Howards-MacBook-Air storagekitd[1179]: Recache Complete, Mount Point: (null)
2018-03-30 14:56:57+01 Howards-MacBook-Air storagekitd[1179]: Removing client connection <SKDaemonConnection: 0x7f9426501b60>
2018-03-30 14:56:57+01 Howards-MacBook-Air storagekitd[1179]: No more connections, storagekitd will exit...

So, what should be done?

If you have applied APFS encryption to any volume since first installing any version of High Sierra, remove install.log immediately. If you want to keep it for future reference, ensure that it is encrypted and kept somewhere where prying eyes can’t reach. macOS should generate you a fresh install.log, which will then be safe from such vulnerabilities. You should also remove or encrypt all backup and other copies of install.log.

Apple needs to:

1. Alert all High Sierra users to this very serious vulnerability as a matter of urgency.
2. Push an urgent update which wipes out all entries in install.log prior to updating to 10.13.4. That will not, of course, remove copies on Time Machine and other backups, which must be addressed in Apple’s alert.
3. Instruct all its engineers about log discipline, to ensure that log entries properly destined to the unified log are not written out to other logs such as install.log. There is absolutely no excuse for continuing to write these messages from diskmanagementd and other services to install.log in 10.13.4.
4. Thoroughly investigate security failures, rather than continuing to apply quick partial fixes, and communicate openly with users.