Hacker News Reader

Comment by wallnuss | Hacker News Reader

how??! In what context does a clear-text password end up anywhere, except as the input for a hash function.

I would guess that the bug was in the front-end code for the password form. At that point the code obviously has access to the plain text password. I’m imagining a copy-paste bug like this:

   storePassword(form[“password”])
   storeHint(form[“password”])

Yes, I was first flabbergasted too but as miserably tested the APFS encryption interface needs to have been (if at all?!), this seems to be basically what is going on.

What makes that theory even more plausible is that the bug doesn't appear in the command line diskutil.

It appears as an NSSecureTextField pointer which could be confused with another NSTextField. One drag-drop away in Interface Builder.

Hooray for Dynamic Typing!

Good point, if secure/private/whatever you want to call it were encoded in the type system, that would most likely have been caught by the compiler.

It's actually not a very good point because NSSecureTextField inherits from NSTextField and it's specifically designed not to protect from programmatic access to the text.

Of course, you can argue about the design but it's still not a dynamic vs. static type issue.

even then:

FooWidget(string s)

and

SecureFooWidget(string s)

could just as easily been confused..

I didn't have Objective-C in mind, more Haskell or so. My understanding is that you could design things such that it is quite a bit harder to make such an error. I might well be mistaken on that, but at any rate, Cocoa/Obj-C/Swift specifics don't defeat the argument I had in mind (though not written down :-)

How?

1. Lack of automated unit tests covering the code in question. 2. Lack of automated functional tests running through scenarios of setting up an encrypted volume with or without a hint. 3. Lack of strict review process for the disk utility's codebase.

This assumes automated tests are also peer-reviewed.

1 - 3 won't guarantee a bug-free project, but I doubt this bug would've made it into production.

Completely agree that adequate automated testing would have caught this but still ...

You'd think the developer/QA that worked on that particular feature would have manually tested it at least once.

>You'd think the developer/QA that worked on that particular feature would have manually tested it at least once.

Or anyone else, it is seemingly not a hidden, elusive bug that can only be caught when a number of particular conditions concurrently happen.

According to Matheus Mariano (that seemingly was the first to find it and report to Apple):

https://news.ycombinator.com/item?id=15408258

https://medium.com/@matheusmariano/new-macos-high-sierra-vul...

The only needed condition is that the Mac has a SSD, and in his words:

"I really don’t know how this went unnoticed by Apple (and anyone else). "

1-2 kind of require having a proper UI testing framework in place. And when you have that for your platform that you want people to develop for, surely you would release it. I haven't seen any of that.

You need to fetch the value to use as hint from the input somewhere.

Doing a typo of writing passwordInput instead of passwordHintInput is not that unlikely, even though it is unfortunate.

Unless you visually connect the fields like the NeXT Interface Builder does.

Well, then it's just an unfortunate drag and drop away. Still same principle :)

Sorry I totally misread your comment the first time. Apologies.

It doesn't. The bug is Disk Utility was setting the password as the password hint.

well, strictly speaking storing the password itself is a good hint, no?

One might say it's too good.

Reply on news.ycombinator.com