Thursday, October 5, 2017 [Tweets] [Favorites]

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

See also: Felix Schwarz.

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 kSKAPFSDiskPasswordOption and kSKAPFSDiskPasswordHintOption, 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.

Howard Oakley:

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.


Why is the password stored in cleartext at all? Seems very insecure and makes it possible for someone to write a malicious tool to extract the password for the volume even if apple fixes Disk Utility.

More details we found out since then:

@Kevin: The entered password is stored as the hint text (which, of course, needs to be stored as plain text). And what you entered as the hint is not stored. Obviously a mixup of what DU stores into the Hint field.

If you do not enter a hint, then your password does not end up in the hint field.

Apparently only happens when you *add* a new APFS volume to an existing APFS volume, i.e. in the same container (partition). Does not happen when you reformat ("erase") an existing APFS volume.

Which means: To avoid this bug, either do not enter a hint or first format the volume without encryption, and only then reformat it with encryption.

@Kevin I don’t think the password is actually stored as cleartext. I think Disk Utility is doing the equivalent of createVolume(name: name, password: password, hint: password)—but only if the hint text field is not empty.

You can also clear this issue by changing the password: when you do so, any hint provided for the new password is correctly stored as the hint.

This isn't really a failure of engineering so much as yet another example of failed QA.

These are obvious test cases. Though I love TDD myself, if you were testing Disk Utility, testing the, what, two dynamic parts of a UI seems like a no-brainer. And if Disk Utility wasn't regression tested as part of the move to AFPS, well, that's idiotic.

It's to the point I can now safely say I've been whining publicly about Apple QA for years (though this is still my favorite.

Gosh. So much fail.

Wes Campaigne

> I don’t understand why the underlying encryption keys need to be changed.

Because from a security response standpoint they need to assume, on principle, that your volume _has_ been compromised and someone has already accessed and stored you encryption keys.

(Whether this is a practical concern for most people is open to debate, but Apple is obligated to recommend the safest course of action for a situation like this.)

@Wes I think that’s likely the reason. But if that’s what they’re worried about, they really should have also said that you should not reuse the same password after erasing or for any other drives that you have.

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment