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]

What's troubling is that Apple stores your passwords unencrypted or has a way to decrypt them. And didn't tell us.

That's inexcusable.

Normally when you key in a password on any sane operating system, it encrypts what you keyed in with an one-way encryption algorithm. Then it compares the encrypted string vs. what's stored encrypted. That's the way it's supposed to work.

What this says is that Apple either chooses to ignore that, or doesn't care. Either way, the cat's out of the bag, there's a way for Apple to see or recover your password easily.
 
  • Like
Reactions: jb-net and simonmet
I wonder if the NSA and such have a bootable usb of this image and are massively upgrading all the confiscated disks to that one build, and clicking 'show hint' ..

And I wonder if they already have a newer version in the future, if they could downgrade to that build, mount and use that ..

I kinda wonder if FV has become obsolete now due to this bug.

I know before I upgraded that I dumped the installer to a usb stick because you know there's always that one family member that forgot their password.
 
Deleted.
[doublepost=1507249750][/doublepost]
ArtOfWarfare said:
I'm going to guess this is because there's a function that takes positional arguments instead of named arguments that look something like this:

Code: 
encrypt(String volume, String hint, String password)
encrypt(String volume, String password)

And someone instead called it with

Code: 
if (hint) {
    encrypt(volume, password, hint);  // The bug is here, should have been hint then password
else {
    encrypt(volume, password);
}

Although... in that case, I'd think you'd have to actually enter your hint to decrypt instead of your password...
Click to expand...
Good call and possibly there is no password set. Arguments ordering probably screwed this one up.
 
Well, this definitely isn't the case for me with 10.13. I double checked a drive I did through the Disk Utility, and it absolutely did not store the password. Only what I initially put in there. Just triple checked with a fresh disk, and it only has my hint that I typed. Not sure what the circumstances are to make this happen but it's definitely not 100%
 
Last edited:
thadoggfather said:
...
Although... in that case, I'd think you'd have to actually enter your hint to decrypt instead of your password...
Click to expand...
Yeah, it would encrypt with the hint. Maybe they had bad variable names and set the hint to the password by accident. Or there's a super crazy buffer overrun bug due to some asm-level hacks that puts the psw into the hint. Given how many times the "new" Disk Utility has crapped out on me, I'd believe either story.
 
fairuz said:
Yeah, it would encrypt with the hint. Maybe they had bad variable names and set the hint to the password by accident. Or there's a super crazy buffer overrun bug due to some asm-level hacks that puts the psw into the hint. Given how many times the "new" Disk Utility has crapped out on me, I'd believe either story.
Click to expand...

I didn't say that but :)
 
Floris said:
I wonder if the NSA and such have a bootable usb of this image and are massively upgrading all the confiscated disks to that one build, and clicking 'show hint' ..

And I wonder if they already have a newer version in the future, if they could downgrade to that build, mount and use that ..

I kinda wonder if FV has become obsolete now due to this bug.

I know before I upgraded that I dumped the installer to a usb stick because you know there's always that one family member that forgot their password.
Click to expand...
Apparently what was happening was that only during initial drive encryption setup using the affected build, the password itself would be set as the plain text hint. It won't work to recover existing passwords for disks encrypted on versions of MacOS without the bug, because those would have already set the hint to the correct value and encrypted the password.

Still a very embarrassing bug, especially when it's Apple that is typically trusted more from a security/privacy standpoint. At least they put out a security update instead of waiting for 10.12.1 to fix, but honestly, both MacOS High Sierra and iOS 11 seem to be more rushed and buggy this year - not good. At least my experience with the release build of High Sierra has been positive for the most part.
 
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...

to be clear, if the robber comes through the front door he gains access.
but if the robber tries get in by the back way, he cant.
 
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...

Williesleg said:
What's troubling is that Apple stores your passwords unencrypted or has a way to decrypt them. And didn't tell us.

That's inexcusable.

Normally when you key in a password on any sane operating system, it encrypts what you keyed in with an one-way encryption algorithm. Then it compares the encrypted string vs. what's stored encrypted. That's the way it's supposed to work.

What this says is that Apple either chooses to ignore that, or doesn't care. Either way, the cat's out of the bag, there's a way for Apple to see or recover your password easily.
Click to expand...

Exactly! This is way more scary than actually displaying the password because this leads to the assumption that there is something fundamentally wrong with the implementation of the security concept of AFS in macOS.
 
Is this only an issue in High Sierra if you set a password.. so, if you already had an encrypted drive then you were ok as long as you didn't use disk utility to change the password for the encrypted partition/drive?
 
ruchern said:
Not many people will add an APFS container at some random time, and that is how it can be missed. This is not the most common usage by consumers.
Click to expand...
If someone made a code change to a security component that handles passwords you bet a code review and QA still has to happen regardless, this is basic software development.
 
A little confused, a few questions for clarification:

1. I'm on Sierra (and while the vulnerability only applies to High Sierra/APFS), I noticed there is no "Volume" button when I right-click a disk or volume, and there is no button in the Disk Utility menu (as we see in the videos). Is this a feature that is only available in High Sierra?

2. I often create Disk Images via Disk Utility to act as password protected folders; I also format external drives as encrypted via Disk Utility before using them for other purposes (Time Machine, extra space, etc.)

What is the difference between these methods (Disk Image, formatting, and partitioning external/internal drives) vs creating volumes? I wasn't sure if the volume behavior was the same as creating an image, since they both seem to make files you (virtually) mount in Disk Utility.

Thanks!
 
Orlandoech said:
LOL @ Apple lately. I was a die hard Apple user... not I cant help but hate them more and more; and the unfortunate thing, they are still better than Google/Android.

Sad.
Click to expand...

And you know what else is unfortunate, what you stated it is not fact in bold. That's an opinion. So you can't pass something as concrete evidence based off an anecdotal opinion over your dismay for this Company, contrary to what you believe.
 
This is great, they won't help you recover your iCloud password even if it locked a phone and you are the owner. BUT they give complete access to your hard drive to anyone. Typical of CRAPPLE.



MacRumors said:



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]
Click to expand...
 
  • Like
Reactions: jblagden
ArtOfWarfare said:
I'm going to guess this is because there's a function that takes positional arguments instead of named arguments that look something like this:

Code: 
encrypt(String volume, String hint, String password)
encrypt(String volume, String password)

And someone instead called it with

Code: 
if (hint) {
    encrypt(volume, password, hint);  // The bug is here, should have been hint then password
else {
    encrypt(volume, password);
}

Although... in that case, I'd think you'd have to actually enter your hint to decrypt instead of your password...
Click to expand...
You might find this of interest.
 
  • Like
Reactions: ArtOfWarfare
thadoggfather said:
Yeah that was a much more sound approach too back when I had a non retina 13" and gutted the SuperDrive for a SSD in its place

OS+apps for SSD
Cold data for spinning drive

Don't leave it up to fusion tech to intelligently learn what's most accessed
Click to expand...
This is one of the reasons why I'm getting into Linux - repairable and upgradable hardware.
 
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