That's no bug, it's a feature, what better hint could you ever devise to help you remember your password than the actual password.
It's genius.
Apple on Thursday released a security patch for macOS High Sierra 10.13 to address vulnerabilities in Apple File System (APFS) volumes and its Keychain software. Matheus Mariano, a developer with Brazil-based Leet Tech, documented the APFS flaw in a blog post a week ago, and it has since been reproduced by another programmer, …
I think you have a typo there. It's possibly an upDATE, but I haven't gotten an upGRADE from Apple in years. Sideways occasionally,. Downwards way too often. But _UP_? Not so much.
(Not to be ungrateful for the bug-fixes, but I really wish they wouldn't bundle them with even more bugs)
How do they even _have_ the plaintext password to display there?
They have it in plaintext at the time you enter it to create the volume. The root of the issue is that they've done something like
diskval.hint = null
diskval.pass = buildKey(password)
if (hint)
set diskval.hint = password
createVolume(diskval)
The root cause is probably a copy/paste of a block that checked for and set the password, and then they changed the conditional but forgot to change the name of the variable they were taking data from
As they said, it's a bug, they intended to store the hint but stored the password. The real password is not in free text.
This has to go down in history as one of the silliest bugs I have ever seen, if it wasn't so serious.
Bug of the week - I think not - maybe bug of the year.
Absolutely.
There is no way I'll go near 10.13 for at least half a year. I may do after I get a dev machine so nuking it would not be a catastrophe, but for my main work machine it ain't happening just yet.
The Apple page on this is shocking, though - in a nutshell, it suggest a full backup, reformat and restore. It appears it is not exactly a *trivial* fix.
Given the spate of non-overtly positive articles recently (EFI, High Sierra, iOS11, Apple Watch LTE, Beats Headphones, iPhone X notch, iPhone general gripes), I thought that Team Vulture had given up and gone full scavenger.
The fact that they got something from an 'Apple spokesperson' is odd; I can only surmise this was an off-day and they caught an intern who was trying to be helpful. Why Apple's email system hasn't yet got a domain rule set to put these requests in a 'pending' folder aka 'Deleted Items' or auto respond with 'No Comment' is also strange.
This post has been deleted by its author
This post has been deleted by its author
It's more worrying than that.
Plain-text copies of your password are being used and stored. That's just not how you do it. You take the password, hash it like mad - including salting it - and then encrypt using the hash.
If you have half-a-brain, you then use that only to encrypt the REAL key that unlocks the drive, rather than the data itself.
In this way, the password is not stored anywhere. You have to match the salt and hash (which can only come from the password the user types in), to unlock the real encryption key (which can be many times stronger). Nowhere on the disk is stored "My Key Is: ...", only users who know the password can log in, anyone can steal the drive and NOT be able to unlock the key, because the drive isn't unlocked until you've typed in the password, there's no chance of there being remnants of the key stored on that same drive, and you can back up the critical headers which store the real key (and the initial password they were created with) and so recover the drive later if something goes drastically wrong or the user forgets the password they changed it to.
There's a reason that TrueCrypt and all its descendents work like that, as well as any sensible commercial encryption software. Because anything else is snakeoil.
The Disk Manager app should have PRECISELY zero access to the actual password, it should be hashed and salted immediately on entry and only THAT passed to the processes that need it. That fact that there's even a bit of code that resembles "put plain-text password into this structure" means that they did not design the encryption properly, whether or not they slipped up between "password box" and "password hint" box.
The password isn't being stored anywhere. The hint is being stored. Unfortunately the hint was being set to the password (and the actual hint lost). This happens when the drive is created, not when it is accessed. The code that fetches and displays the hint doesn't know it is the password.
AND THE HINT IS COPY/PASTE OF A PASSWORD FIELD THAT SHOULDN'T BE ANYWHERE IN PLAIN TEXT.
Literally, they have two variables;
Password
Password Hint.
They have taken plain text from the user, put it into password and that's ended up in password hint by mistake.
But EVEN PASSWORD shouldn't be like that. It should be opening keychain, or it should be hashed and stored and the original immediately disposed of, and it certainly shouldn't be accessible to the disk encryption program. That the password and the hint are handled anywhere near the same way tells you that they're doing it wrong.
The entire PROCESS is wrong, such that a simple error reveals the password. That password shouldn't be sitting in a plain-text field to begin with, such that it can be confused and accidentally written somewhere else.
(Hell, I'd argue the password shouldn't be in memory as a string anywhere... I would code it so that the password box was really just a keyboard-event receiver and for each key hit I would throw the received key straight into the hash function and store only that in RAM. Store the last 50 hash functions to let people backspace (and, yes, stop, them clicking into the middle of the password and typing extra chars, etc.) - show it as a password box with X amount of *'s in it, but only store it as a hash)
You take the password, hash it like mad - including salting it - and then encrypt using the hash.
Here is another perfect example of why getting security right is hard.
What you would actually want to do is hash the password, with a random salt (to prevent rainbow attacks against the hash), and then store the hash and salt in order to verify the password. In turn, you would use the password (not the hash) to protect a decent length encryption key, ideally alongside something that also uniquely identifies the hardware (in order to prevent brute force attacks on stolen drives slotted into custom hardware) that cannot be spoofed, such as a master machine encryption key. You then use that key that you have protected with your password to encrypt the contents of the drive. You certainly wouldn't use the hash, which will be stored and accessible and used to validate the password when the user enters it.
Just another example of Apple copying Microsoft... anyone else remember bob? https://books.google.co.uk/books?id=HCQdypbpZXgC&pg=PA17&lpg=PA17&dq=microsoft+bob+looks+like+you+have+forgotten+your+password+change+it?&source=bl&ots=nqK3Qo1EBY&sig=EcFV4ZbCMJIKfU7Dv4u2AetdND4&hl=en&sa=X&ved=0ahUKEwiDx_uMqdrWAhUJBsAKHZhbBi8Q6AEIJDAA#v=onepage&q&f=false
Um? Your link is dead.
Also Microsoft was not the first to have disk encryption at all. Windows didn't get built in encryption until bitlocker - which wasn't introduced until either Vista or Windows 7 - Prior to that built in disk encryption has already been added to Linux with LUKS in 2004. No doubt other operating systems had it by that point too.
Of course, there's been third party software also for years which could do it, but it was never "built in" by default.
I suspect you are correct. And they also gave them a box of crayons. Usefulness of an iTunes like multicoloured swap space line bar diagram ... ... versus the usefulness of being able to prepare a disk image for restore and re-image a volume from a .dmg, or set up / modify a RAID configuration?
Question, why is the password stored at all, anywhere? Shouldn't it be immediately hashed?
This was addressed by clearing hint storage if the hint was the password, and by improving the logic for storing hints.
Improving "logic" for storing hints. I suppose it used to be
if (True) {
Store_Hint(Password.To_Plain_Text());
}
and now its
if (False) {
Store_Hint(Password.To_Plain_Text());
}
else {
Store_Hint(Hint.To_Plain_Text());
}
There was no logic to store the password but there was logic to store the hint, obviously. Unfortunately the UI (the app, not the underlying filesystem) stored the contents of the password input into the hint field.
The solution that Apple is now applying in the fix will be to test if the volume can be decrypted using the password hint. If it can, this user has suffered from the error and the fix will delete the contents of the hint field. If it can't, this user hasn't suffered and nothing needs to change. Quite a neat approach in the fix tbh.
That was my first thought but then I realised that now those people no longer have their hint accessible - if they forget the password they are bu99ered?
Wouldn't it have been better to prompt for a new hint next time they used the machine as it was wiping the old one - at the point the user has just successfully entered the password?
Presumably/hopefully when they blank the hint they'll ask the user to set the hint properly.
This is exactly the sort of bug you'd expect to miss testing. Apple employees doing alpha testing and power users doing beta testing don't need hints, they remember their passwords. The kind of people who forget their password and make use of the hint aren't the type to be testing pre-release software, at least not voluntarily!
Even if the code had a constraint that the hint can't contain the password, if they tested the hint you typed in first (to give an error message "the hint cannot contain your password") it would have passed the test. The bug was storing the password in the hint field instead of storing the hint in the hint field, that's something you'd generally do AFTER you've tested the hint because you don't store it until it passes all the test - just like you wouldn't store the password until the user enters one that meets the length/complexity/etc. requirements.
Those people never had their hint accessible anyway as the field where it was supposed to be stored was used to store the password instead. Emptying the hint field if it can be used to decrypt the drive still makes perfect sense as nothing is lost while a vulnerability is solved.
But yes, the fix must be accompanied by a suggestion to change your password and add the hint to be on the safe side.
There was no logic to store the password but there was logic to store the hint, obviously. Unfortunately the UI (the app, not the underlying filesystem) stored the contents of the password input into the hint field.
In a proper security design, both the UI layer and the storage layer would be explicitly checking that they hadn't been passed anything in the hint field that could be hashed down to the same as the password hash and; in the UI layer given a message that the password and hash cannot be the same; in the storage layer throw an exception.
In a proper n-layer architecture, as any fule kno, you do not trust the input from the layer above you.
Probably no-one at Apple noticed because they're all still using the command line instead of Disk Utility for everyday volume maintenance, and the bug isn't present in the command line version. Everyone uses command line diskutil because several versions ago (I think in El Capitan) Disk Utility lost essential functionality. If, for example, you wanted to set up software RAID (e.g. mirrorring) you suddenly had to use the command line. If you've been routinely doing that for two years or more and you're a developer, of course you're going to continue instead of learning High Sierra's new Disk Utility.
The real disgrace is that El Capitan ever got out the door with that neutered Disk Utility. Lots of people in the creative industries - photographers, video editors, animators etc. - had a need for and used RAID, especially with the popular cheesegrater towers. To expect those kinds of people to use the command line was absurd.
So this isn't just a matter of poor QA on High Sierra - although it is that - but poor software development plans as set out by senior management. It was a conscious decision that power users, including Apple's own developers, would not be "eating their own dog food".
I knew I couldn't be the only one mad at this change. I actually held off upgrading to El Capitan because of it. Ended up jumping from Yosemite to Sierra on April because APFS was actually piquing my interest. I didn't really expect it to be released with these kind of bugs, though.
I used to enjoy new updates - they brought great new pro features - I remember putting snow leopard on and getting so much better performance on CPU tasks, GPU tasks, etc. It was what you EXPECT from mac os upgrades - making everything better by taking advantage of the tight HW integration and leveraging real time GPU encoding/decoding, etc, etc.
Since then it's been downhill - adding useless shite every year that I have to disable (launchpad, game centre, notifications, flat icon bollocks, daemon services for facebook, icloud and various other crap I have no intention of every using)
My approach is now to not upgrade the OS version AT ALL (security patches aside) , until one of my key program's updates has some killer features that I need - and is tied to a more recent OSX version. Even then it pains me to have to, as 9x out of 10 there's no technical reason for the restriction.
So I only moved to El Capitan late this year when FCPX and a few other apps wouldn't install updates on Yosemite, and I decided it was worth the hassle. Sierra was out, but I saw no point in moving more than I needed to.
Queue 1/2 a day of updating all the low level utils that then break once El Capitan on, and disabling various pieces of crap I have no interest in (social media shite up the wazoo for example), disabling SIP cause like... I'm a big boy... if I want to use XtraFinder because after 17 years your shite Finder still doesn't allow proper cut and paste,and right click to create a text file where I want to, I'll fecking well do it.
Sierra continued this approach by offering nothing new other than trying to make my mac look and work like an iphone. And having never had any issues at all with AFS, I've no desire for high sierra either frankly.
This is how I feel about pretty much all mainstream OS nowadays.
I don't want 'more stuff' I have all that or can add it later as I need it. I just want the OS to be faster, leaner and more secure.
I have no need for dozens of apps and features I have no use for, cannot properly uninstall and just add to the attack surface and are the reason for masses of more unnecessary updates.
What feature would I like the most? Thanks for asking, I'd like a modern robust file system that can transfer thousands of small 10Kb files at the same rate as it can a 10GB video file instead of crawling to a near halt over my 3500MBps NVME storage hardware. That will be a start. I'll never get it though, I guess I'll have to make do with some 3D kids party planner app instead.
Fair play Apple, making sure it "just works" for everyone. Including those who want your encrypted data when you're not around.
Here, have a pint. Yes it's warm. Yes there's no head. Yes there is faint wiff of piss from it. Yes we're aware of the issue, but we'll sort it out after you drink this pint first.
This smacks of a developer deliberately storing the password in the hint field on purpose, so that he (or she) can test it as she (or he) goes along and not worry have to worry about remembering the password.
The intention would have been to remove that bit before committing it, but (s)he forgot, and nobody noticed it in the pull request.
2017 in review:
Microsoft: Hey, we didn't validate our update before rolling it out - top that!
Google: That's nothing - we released the latest version of our mobile OS with a bug that eats all your data - top that!
Apple: Hold my beer...
And... because High Sierra is now available, you can no longer upgrade to regular old Sierra, unless you previously installed it, because, oh right there's no reason.
Since a lot of my apps now (finally) work with Sierra but are officially listed as not working with High Sierra, I'm kinda stuck where I am.
An alternative suggestion as to the source however: when one uses Apple's interface builder, one task is to connect outlets to graphical elements, e.g. you know there's an NSTextField that the user will type a password into so you declare an NSTextField property and then you switch to the interface builder where you have laid out the dialogue and you wire the property to the control — literally drag a connection from the one to the other. Then in code you access the text field's contents via the outlet.
A drag and drop error that connected both the 'hint' and 'password' outlets to the password text field would then result in the password being recorded as both, even though the code says 'self.password' for one and 'self.hint' for the other. And the wiring is all within the undocumented XML format used for interface layouts, so good luck getting a meaningful code review on that.
Given the whole purpose and importance of a password hint, it's mind boggling that nobody tested the feature.