Become a MacRumors Supporter for $25/year with no ads, private forums, and more!

Disk Utility Bug in macOS High Sierra Exposes Passwords of Encrypted APFS Volumes in Plain Text [Updated]

MacRumors

macrumors bot
Original poster
Apr 12, 2001
50,443
11,833



Brazilian software developer Matheus Mariano appears to have discovered a significant Disk Utility bug that exposes the passwords of encrypted Apple File System volumes in plain text on macOS High Sierra.

MacRumors confirmed our test password "dontdisplaythis" appeared as the hint

Mariano added a new encrypted APFS volume to a container, set a password and hint, and unmounted and remounted the container in order to force a password prompt for demonstration purposes. Then, he clicked the "Show Hint" button, which revealed the full password in plain text rather than the hint.

A second video with English system language is embedded below

MacRumors reproduced this behavior on a 2016 MacBook Pro running macOS High Sierra, including versions 10.13 and 10.13.1 beta. German software developer Felix Schwarz also shared a video of the issue on Twitter today.
Tried myself & it's true: #HighSierra shows the #APFS volume password as hint. Persists reboots, not stored in keychain. Wow. Just wow. pic.twitter.com/FkcHI9KHl9— Felix Schwarz (@felix_schwarz) October 5, 2017
The issue currently only affects Macs with SSD storage due to Apple File System compatibility, but APFS will eventually support machines with Fusion Drives as well. Schwarz believes users who haven't specified a password hint, or haven't used Disk Utility whatsoever, are probably not affected.

For clarity, this appears to be a bug within Disk Utility itself. When creating an encrypted APFS volume in Terminal with the diskutil command line utility, the actual hint is shown, rather than the password.

Mariano said he has reported the vulnerability to Apple. The company did not immediately respond to our request for a comment on the matter, but we'll update this article if we hear back.

Update: Apple has addressed this bug by releasing a macOS High Sierra 10.13 Supplemental Update, available from the Updates tab in the Mac App Store. Apple has also shared a support document outlining steps to back up, erase, and restore the encrypted APFS volume upon updating.

The bug has also been fixed in the base version of macOS High Sierra for those who have yet to install the full software update.

Article Link: Disk Utility Bug in macOS High Sierra Exposes Passwords of Encrypted APFS Volumes in Plain Text [Updated]
 

0003939

Suspended
Jun 2, 2017
160
222
Interesting thing is that if there is no password hint this will not happen? (Based off the article)
 
Comment

dwsolberg

macrumors 6502a
Dec 17, 2003
736
553
Easy developer mistake, but seems like it should have been very easy to test, too.

I realize that running a huge company must be difficult, but it's really surprising that Apple doesn't have the resources to test these things, especially because they are trying to stake a claim on privacy, and security is an essential ingredient.

---

For some things, I think I trust Google more because they seem more likely to share marketing information about me, but a lot less likely to accidentally divulge all my saved information.
 
Comment

thadoggfather

macrumors G5
Oct 1, 2007
12,581
10,223
First fusion drives have problems with high Sierra, a cheap hybrid drive that shoulda never been made standard for retina iMacs considering their price tag, NOW this!

So glad I dual boot Sierra and high Sierra (on a smaller partition) on my 13" nTB

I simply don't trust apple thoroughly tests stuff and/or cares
 
Comment

madmin

macrumors 6502
Jun 14, 2012
256
679
First the macOS keychain hack, now this. Whatever next ? Please sort it out sharpish.
 
Comment

RMo

macrumors 65816
Aug 7, 2007
1,220
215
Iowa, USA
To be clear, the linked Twitter thread suggests that this is a Disk Utility bug, where if you create a password-protected volume in Disk Utility it inadvertently sets the hint to the password itself. It's not a bug that allows the password itself to be uncovered via other means, which is what I originally thought this meant and which was surprising to me since the only way to do that should be computationally expensive brute-force methods (the data itself is encrypted with the password; it's not just artificially protected by one, and it shouldn't be possible to "reverse lookup" the password by any true means).
 
Comment

thobie

macrumors member
Oct 21, 2009
37
20
How the **** can the password be stored as a plain text without encryption? Or is the problem the AFS volume generator storing the password string also as a hint string? Otherwise if you can decrypt the password string without even entering the password itself is... interesting safety politics.
 
Comment

smaffei

macrumors 6502
Jun 5, 2003
365
1,398
Apple seriously needs to start hiring better QA engineers....

Yes, there some HUGE problems with Apple QA these days.

iOS 11 is riddled with obvious bugs. I just got one about 10 minutes ago. Was just deleting a few voicemails (swipe delete) and the Phone App crashed. Then there is a very reproducible Messages bug where the keyboard obscures the last few messages and you can't get to them. Real rinky-dink stuff that should be caught.

I'm starting to think that Apple is relying too much on the Beta process to collect bugs instead of having robust internal QA.
 
Comment

guitarman777

macrumors regular
Sep 15, 2005
213
34
Orlando, FL
This is why having the user community helping beta test software & OS releases is so important. Also glad to see people using their skills to help improve systems rather than exploitation and wreaking havoc.
 
  • Like
Reactions: 0003939 and bwintx
Comment

belvdr

macrumors 603
Aug 15, 2005
5,657
1,024
No longer logging into MR
To be clear, the linked Twitter thread suggests that this is a Disk Utility bug, where if you create a password-protected volume in Disk Utility it inadvertently sets the hint to the password itself. It's not a bug that allows the password itself to be uncovered via other means, which is what I originally thought this meant and which was surprising to me since the only way to do that should be computationally expensive brute-force methods (the data itself is encrypted with the password; it's not just artificially protected by one, and it shouldn't be possible to "reverse lookup" the password by any true means).
That's a very good point, although I don't know many people using Terminal to create volumes on macOS, so the impact can be large.
How the **** can the password be stored as a plain text without encryption? Or is the problem the AFS volume generator storing the password string also as a hint string? Otherwise if you can decrypt the password string without even entering the password itself is... interesting safety politics.
The problem is Disk Utility is setting the hint to the password itself. It's a bug in Disk Utility, not APFS.

@840quadra : It would be wise to update the article. Here's a link to a tweet showing that creating the APFS-encrypted volume via Terminal is not susceptible to this bug in Disk Utility:

https://twitter.com/felix_schwarz/status/915857500330700801
 
Comment

uhaas

macrumors 6502
Aug 31, 2012
270
58
Boston, MA
Yes, there some HUGE problems with Apple QA these days.

iOS 11 is riddled with obvious bugs. I just got one about 10 minutes ago. Was just deleting a few voicemails (swipe delete) and the Phone App crashed. Then there is a very reproducible Messages bug where the keyboard obscures the last few messages and you can't get to them. Real rinky-dink stuff that should be caught.

I'm starting to think that Apple is relying too much on the Beta process to collect bugs instead of having robust internal QA.
I'm not seeing beta report actually getting addressed.
 
Comment

cult hero

macrumors 65816
Jun 6, 2005
1,052
817
To be clear, the linked Twitter thread suggests that this is a Disk Utility bug, where if you create a password-protected volume in Disk Utility it inadvertently sets the hint to the password itself. It's not a bug that allows the password itself to be uncovered via other means, which is what I originally thought this meant and which was surprising to me since the only way to do that should be computationally expensive brute-force methods (the data itself is encrypted with the password; it's not just artificially protected by one, and it shouldn't be possible to "reverse lookup" the password by any true means).

I’m gonna have to confirm that. I’ll feel a lot better if that’s the case.

Pretty big oops either way. Better get patched yesterday.
 
Comment
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.