Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse Engineering MacOS High Sierra Supplemental Update

cocoaengineering.com

Post reply on HN
Print view View original

21–30 of 135 posts

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#21

Post by maccard »

nicolasd wrote: post #17
bsaul wrote: post #13

Seems like Unit testing really is NOT popular at all at Apple. I mean, they release a framework for storage, and they don’t even unit test security related functions ? Tdd introduced the wrong idea that unit tests should be all or nothing. I think it’s not. I unit test only the most critical parts of my programs (and only if there are), and i see value in it.

Serious question: How would you suggest to write a test that prevents this? You wouldn't make an assertion on clearTextPassword !== passwordHint. While developing I would think "Who will ever do that? That would be insane". But yes, even if there is no test, this should have been caught in code review or latest when testing the OS.

I noticed when I upgraded that they block you from setting your account password to the same as your iCloud password, so they've obviously considered that people will do stupid things.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#22

Post by chaosite »

colinzoy wrote: post #15

1. to me the most important question is: why on earth can the disk password be retrieved in clear text in the first place ?! 2. also: the buggy version will be able to show disk passwords forever, until the encryption scheme is changed. macOS native encryption is useless until then (but given 1., it might already have been for some time).

If I understand the blog post correctly, the bug was in the software that creates (or maybe mounts? Not too clear about that) the encrypted volume. It needs to have the clear-text password in order to function.

Then it proceeded to set the clear-text password as a password hint due to the bug.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#23

Post by bsaul »

nicolasd wrote: post #17
bsaul wrote: post #13

Seems like Unit testing really is NOT popular at all at Apple. I mean, they release a framework for storage, and they don’t even unit test security related functions ? Tdd introduced the wrong idea that unit tests should be all or nothing. I think it’s not. I unit test only the most critical parts of my programs (and only if there are), and i see value in it.

Serious question: How would you suggest to write a test that prevents this? You wouldn't make an assertion on clearTextPassword !== passwordHint. While developing I would think "Who will ever do that? That would be insane". But yes, even if there is no test, this should have been caught in code review or latest when testing the OS.

It seems like the error was in the creation of an intermediate data structure ( minimal dictionary something) in a storageKit framework. I’m not talking about the disk util app ( which doesn’t contain any bug in itself apparently)

To give a better answer : I’m not knowledgeable of the whole source for the framework, but there are only two cases :

- either the outputs of your critical function are testable and then just test it.

- or they’re not ( most often because of side effects), in which case you should extract the critical part in purer function, and test that.

It’s a great benefit of unit test : they force you to isolate side effects from business logic, to be able to test the latter.

In that case, if the function isn’t testable, then maybe the creation of this intermediate minimal dictionary should belong in its own function that just does the data mapping.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#24

Post by rusk »

danra wrote: post #16

It's pretty insane this sort of bug either passed or didn't even go through code review and testing at Apple, a company which has approximately infinite resources and whose marketing pitch is making high-quality products. I loved Apple products and still do, but as both a user of and a developer for their systems, I feel the quality has been steadily going downhill the last few years.

> whose marketing pitch is making high-quality products

"It just works" was retired some time ago. "Think different" is the modern day mantra. It's less of an open-ended commitment.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#25

Post by javabean22 »

tempodox wrote: post #20

Installing a new Mac OS on a machine you care for has become an absolute no-go area. I wait for at least half a year and then only install in a place that I can trash in case I still see problems.

> at least half a year

oh yeah half a year, really? oh shut the fuck up. fuck off.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#26

Post by rjzzleep »

tempodox wrote: post #20

Installing a new Mac OS on a machine you care for has become an absolute no-go area. I wait for at least half a year and then only install in a place that I can trash in case I still see problems.

I'm not sure why you say "has become".

In the circles I've been it has been common practice to wait for the .2(but minimum .1) release before it goes onto real work machines. The early Mac OS X releases were even worse.

Even if for some reason the OS itself was fine by itself, they almost always broke compat with a bunch of 3rd party applications.

EDIT: typo

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#27

Post by sitharus »

colinzoy wrote: post #15

1. to me the most important question is: why on earth can the disk password be retrieved in clear text in the first place ?! 2. also: the buggy version will be able to show disk passwords forever, until the encryption scheme is changed. macOS native encryption is useless until then (but given 1., it might already have been for some time).

1. The disk password cannot be retrieved. The bug occurred when creating a new encrypted volume - the password was copied in to the hint field as well as the password field.

2. Changing your password with the updated disk utility will fix the issue.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#28

Post by devdoomari »

does this mean that all passwords for osx-encrypted-drives have been 'recoverable'? e.g. if I created an encrypted drive using El Capitan, someone else can crack my drive's password without even cracking a password-hash?

Or is there a bug also in high-sierra's 'create-encrypted-disk' functionality? (but not in lower-versions)

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#29

Post by [deleted] »

chaosite wrote: post #22
colinzoy wrote: post #15

1. to me the most important question is: why on earth can the disk password be retrieved in clear text in the first place ?! 2. also: the buggy version will be able to show disk passwords forever, until the encryption scheme is changed. macOS native encryption is useless until then (but given 1., it might already have been for some time).

If I understand the blog post correctly, the bug was in the software that creates (or maybe mounts? Not too clear about that) the encrypted volume. It needs to have the clear-text password in order to function. Then it proceeded to set the clear-text password as a password hint due to the bug.

[deleted]

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#30

Post by sschueller »

danielsamuels wrote: post #14

> did the QA engineer test setting a password and a password hint?, easily forgettable on a tight deadline Or they used 'asd' as both the password and the password hint and therefore it looked ok.

What kind of amateur uses the same entry for two different fields? In the early days of coding your entries going into the wrong place is something that will happen to you.
Post reply on HN