Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

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

MacRumors

MacRumors

macrumors bot
Original poster
Apr 12, 2001
68,540
39,384



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.

disk-utility-password-prompt-800x367.jpg
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]
 
Article Link
https://www.macrumors.com/2017/10/05/macos-high-sierra-disk-utility-vulnerability/
  • Like
Reactions: butterburger cookybutter and Michaelgtrusa
Interesting thing is that if there is no password hint this will not happen? (Based off the article)
 
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.
 
  • Like
Reactions: kazmac, Regime2008, outsidethebox and 10 others
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
 
  • Like
Reactions: jb-net, Cameroncafe10a, Orlandoech and 2 others
First the macOS keychain hack, now this. Whatever next ? Please sort it out sharpish.
 
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).
 
  • Like
Reactions: LinusR, cyanite, jpn and 14 others
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.
 
  • Like
Reactions: jb-net, Cameroncafe10a, bernuli and 1 other person
masotime said:
Apple seriously needs to start hiring better QA engineers....
Click to expand...

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.
 
  • Like
Reactions: kazmac, motulist, CrickettGrrrl and 15 others
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
RMo said:
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).
Click to expand...
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.
thobie said:
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.
Click to expand...
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
 
  • Like
Reactions: kazmac, cyanite, You are the One and 4 others
smaffei said:
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.
Click to expand...
I'm not seeing beta report actually getting addressed.
 
RMo said:
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).
Click to expand...

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.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back