Live data from Hacker News

Reverse Engineering MacOS High Sierra Supplemental Update

cocoaengineering.com

31–40 of 135 posts

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#31
post #4

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; /* MISTAKE! THIS LINE SHOULD NOT BE HERE */ if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; History repeats itself in ever stranger ways. While the effects are different, the original mistake can be quite similar.

um... use dependent types? sorry but I'm from different language background :(

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#32

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

"4rd party"...

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#33

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)

Only in the passwords created using GUI version of the new Disk Utility (command line is safe).

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#34
post #33

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)

Only in the passwords created using GUI version of the new Disk Utility (command line is safe).

thank you! thought I was screwed...

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#35

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.

It always has been, at least in a professional environment. I used to work at a Apple reseller. We would have to advise customers to keep running old versions (sometimes up to 2-3) because of 3rd party compatibility lag. From my point of view it has been improving over time with earlier dev. versions of the Os. But must agree I'm also still hesitant to run it on my workhorse.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#36

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).

[deleted]

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#37

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)

The bug would be that for encrypted APFS volumes made using Disk Utility and similar applications, the password hint was accidentally set as the password itself.

High Sierra is the first OS X release with APFS.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#38

> 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.

what kind of amateur does manual testing of basic functionality?

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#39
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 have developed a UI test automation software years ago, it should be getHintFromUI() == passwordHint.Here getHintFromUI is a function which get string from User Interface directly.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#40
post #4

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; /* MISTAKE! THIS LINE SHOULD NOT BE HERE */ if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; History repeats itself in ever stranger ways. While the effects are different, the original mistake can be quite similar.

um... use dependent types? sorry but I'm from different language background :(

Provable code would solve the root cause, yes. :) However, even with provable code, the proof actually has to be both correct and performed. There are too many competing factors that won't allow idris, for example, to actually work.

The result is that, as an industry, the Internet and the world's business are held together by twine, twist ties, and spaghetti code. Even this very webpage is just enough to work for most people a lot of the time.

Post reply on HN