I previously described a serious vulnerability in macOS High Sierra versions to 10.13.1 which was discovered by Sarah Edwards. I regret to say that a very similar bug remains in High Sierra 10.13.2 and 10.13.3, in which encryption passwords are still written to the unified log in plain text.

Thanks to @moelassus, who reported seeing this bug persist in 10.13.3, and Sarah Edwards, we have established that this is a 100% reproducible bug in 10.13.3. It does not, any longer, affect the creation of new encrypted APFS volumes, but occurs when an existing unencrypted APFS volume is encrypted, by erasing just that volume in Disk Utility.

If you have erased an existing unencrypted APFS volume to change it into an encrypted APFS volume in the last 20 days or so, then you can be certain that the passphrase to that encrypted volume is stored in your unified log, and accessible to anyone who can access your Mac as an admin user (or when an admin user is logged on).

When Apple ‘fixed’ the original bug, which occurred when creating a new encrypted APFS volume, it clearly did so by accident, and was unaware that the change that was made to the volume creation step blocked the entry of the plaintext password in the log. Consequently, another instance in which an almost identical call was made by diskmanagementd, to newfs_apfs to make an existing volume encrypted, was left in the code. It is that call which is currently appearing in the log.

Prior to macOS 10.13.2, when a user created a new encrypted APFS volume, three calls were made by diskmanagementd to run external commands: the first to newfs_hfs, the second and third to newfs_apfs. It was the third which contained an undocumented option -S which passed the passphrase as plain text. As that call was always being logged as a Fault level entry, the plaintext password was always being recorded there.

Whatever change Apple made to diskmanagementd in 10.13.2 removed that third call (I suspect that they used a more secure calling mechanism, as should have been done in the first place).

However, when encrypting an existing APFS volume in 10.13.3, an almost identical sequence of calls is made, all three of which end up as Fault level entries in the log:
diskmanagement: execve(2) pid=583 /System/Library/Filesystems/hfs.fs/Contents/Resources/newfs_hfs -J -v transit /dev/rdisk3s2
diskmanagement: execve(2) pid=608 /System/Library/Filesystems/apfs.fs/Contents/Resources/newfs_apfs -C disk3s2
diskmanagement: execve(2) pid=628 /System/Library/Filesystems/apfs.fs/Contents/Resources/newfs_apfs -i -E -S thisisthepassword -v transit disk4s1

The third and final call still uses the same undocumented -S option with the plaintext passphrase which caused the vulnerability in the first place.

Apple: you still have at least one (maybe more) serious vulnerabilities to fix. And best you look really hard at all execve() and similar calls made in macOS 10.13 to ensure that they don’t leak other data elsewhere.

Thanks to @moelassus and Sarah Edwards for raising this when we all thought it had been ‘fixed’. As I wrote:
It also raises further questions about the security and privacy of the unified log. When developers use its public and private protection properly, the log’s privacy mechanisms do indeed prevent the leakage of private data into the log. However, that protection is easily removed by programming errors, which may still lurk in macOS 10.13.3 High Sierra. Don’t be surprised if you stumble across other sensitive data in your logs.