Encrypted APFS Volume’s Password Exposed as Hint
Matheus Mariano (via Jeff Johnson):
This week, Apple released the new macOS High Sierra with the new file system called APFS (Apple File System). It wasn’t long before I encountered issues with this update. Not a simple issue, but a potential vulnerability.
The bug was easy to reproduce on my Mac. Plugging the drive into another Mac also shows the password as the hint. So I’m guessing it’s not actually an APFS flaw but rather that Disk Utility is passing the wrong variable as the hint parameter.
Update (2017-10-05): See also: Felix Schwarz.
Including a comma in the name or password of a APFS volume when creating it makes the process failing, miserably. #onlyApple
Apple (via Rene Ritchie):
Your password might be displayed instead of your password hint if you used the Add APFS Volume command in Disk Utility to create an encrypted APFS volume, and you supplied a password hint.
Changing the password on an affected volume clears the hint but doesn’t affect the underlying encryption keys that protect the data.
[…]
If your disk password for any affected encrypted APFS volume is the same as the password that you use for a macOS user account or an internet service, you should change the password of the user account or internet service.
I don’t understand why the underlying encryption keys need to be changed. In any event, Apple recommends downloading the “macOS High Sierra 10.13 Supplemental Update” and then completely erasing your drive and restoring it from backup.
See also: Howard Oakley, MacRumors, Howard Oakley.
Update (2017-10-06): macOS High Sierra 10.13 Supplemental Update:
Impact: A local attacker may gain access to an encrypted APFS volume
Description: If a hint was set in Disk Utility when creating an APFS encrypted volume, the password was stored as the hint. This was addressed by clearing hint storage if the hint was the password, and by improving the logic for storing hints.
CVE-2017-7149: Matheus Mariano of Leet Tech
Update (2017-10-09): Daniel Martín (tweet):
I decided to apply a binary diffing technique to the update to learn more about the root cause of this bug and hypothesize about how the defect could have been prevented.
[…]
The most interesting keys in the dictionary are
kSKAPFSDiskPasswordOptionandkSKAPFSDiskPasswordHintOption, which are responsible for storing the password and the password hint, respectively. The bug is that the same variable, which contains the password, (represented in the decompilation as the same virtual register,v50) was used as value for both keys in the dictionary, meaning that the clear password was incorrectly sent as a password hint via XPC.[…]
This is an example of a common category of bugs where code with a common structure is copied and pasted but the developer forgets to make every required modification and consequently there’s a fatal change in behavior.
That glaring error aside, Disk Utility version 17.0 does some quite strange things at times. My MacBook Air has a Transcend Flash drive inserted into its Secure Digital slot, which Disk Utility refuses to convert to APFS, reporting a StorageKit error 118. That apparently means that it became an unbootable system, which doesn’t seem to make much sense.
Sometimes you can coax Disk Utility 17.0 into doing tasks like that by selecting the drive in the list at the left, unmounting it using that command in the File menu, then trying the task again.
