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

41–50 of 135 posts

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#41

Post by jsjohnst »

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

The answer to your question was shown in code and also explicitly stated in English in the article.

Edit: removed the “did you read the article?” part

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#42

Post by jmnicolas »

arghwhat wrote: post #32
rjzzleep wrote: post #26

Earlier quoted context omitted.

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

Nobody ever mentions the 2nd party either !

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#43

Post by eru »

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.

Apart from the time it takes to restore from backups, should every place fall under "only install in a place that I can trash in case I still see problems?

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#44

Post by eru »

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.

Yes, with 'example based testing' this is hard to come up with. With property based testing, it's not so hard to test this kind of UI things:

You test a UI by basically throwing sequences of interactions at it. Some of the properties you'd want to assert:

* Given two interaction sequences that only differ in what they do to the password hint field in the UI, the result should only differ differ in the returned password hint. (Or alternatively neither should finish the UI dialogue.)

* As a dual: two interaction sequences that share the same interaction with the password hint field should yield the same password hint field. (In this case it is acceptable for them to differ in whether they actually finish the dialogue.)

Those two are fairly generic, so you can imagine setting that up as a general framework for all your data input fields in your UIs. It should work backwards as well, eg to assert that eg the UI should look the same no matter what password (/ password hash) is stored, to make sure you are not leaking any information.

See eg https://fsharpforfunandprofit.com/posts/property-based-testi... for more background, and http://hypothesis.works/articles/incremental-property-based-... for a real world example.

As for 'should have been caught in code review': yes, but humans are fallible and they should get all the help we can give them. To see for yourself, have a look at the example (a simple runlength encoding) at the top of http://hypothesis.readthedocs.io/en/latest/quickstart.html and see whether you can spot the obvious error just by reviewing the code.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#45

Post by eru »

emsy wrote: post #12
IncRnd wrote: 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.

You don't even need static analysis (which they should use too) but just a strict coding style check that enforces curly braces. Should've happened after the first incident!

A coding style check _is_ static analysis.

(But that's beating a straw man, of course: with that expanded definition your comment just because "you don't even need anything more than the most primitive forms of static analysis".)

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#46

Post by blinkingled »

> Apparently, Disk Utility and command line diskutil use different code paths. StorageKit does not appear as a direct dependency of diskutil. [snip] This duplication in what’s more or less the same functionality, while sometimes justified, certainly increases the opportunity for bugs.

To me this is the more problematic part - good design would use same code paths as much as possible for the GUI app and the command line one - the UI code in this case will differ but there should really be no need for diskutil and Disk Utility to use duplicate code for storage functions.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#47

Post by eru »

tempodox wrote: post #19
emsy wrote: post #12

Earlier quoted context omitted.

You don't even need static analysis (which they should use too) but just a strict coding style check that enforces curly braces. Should've happened after the first incident!

I find it jaw-dropping how fashionable cowboy coding still is, especially in C family languages.

C-family languages are cowboy languages.

The whole point of eg C (and C++)'s undefined behaviour is to allow the compiler to make cowboy assumptions like "this array access will never be out of bounds" or "this signed int will never overflow" without having to prove or even justify them. All in the name of 'efficiency'.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#48

Post by eru »

devdoomari wrote: post #31
IncRnd wrote: 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 :(

Or even just QuickCheck? (Hypothesis is an excellent implementation of the concept in Python, so you don't even need Haskell to get the goodness.)

Contracts, like they have in Racket, might also be interesting. They only fail at runtime, but it's easy for mere mortals to express interesting invariants and get good 'blame'.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#49

Post by eru »

blowski wrote: post #5
atas wrote: post #2

Simple technique for preventing bugs like this: don't copy-paste code. If you find yourself copy-pasting code think twice why you even have to do it (DRY principle) and be aware of the potential consequences. Even if some code has to be duplicate, I am forcing myself to just write it from scratch, exactly for this reason: do you really know that you have updated all your data? And yeah, unit tests would help in spott…

Just to play devil's advocate: sometimes DRY code is harder to understand, which makes it harder to see bugs. Whenever you introduce an abstraction to make your code DRYer, you have to remember the law of leaky abstractions. DRY code is a good principle to follow, but not an absolute law.

Some languages are leakier than others..

As for terse code: a line that's five times as hard to understand might be worth it, if it saves ten. (But I usually code in languages that are famously terse and have watertight abstractions---at least in the correctness sense, even if not in the performance sense.)

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#50

Post by eru »

atas wrote: post #2

Simple technique for preventing bugs like this: don't copy-paste code. If you find yourself copy-pasting code think twice why you even have to do it (DRY principle) and be aware of the potential consequences. Even if some code has to be duplicate, I am forcing myself to just write it from scratch, exactly for this reason: do you really know that you have updated all your data? And yeah, unit tests would help in spott…

> But aren't unit tests a duplication of your code, already? > UPDATE: > Maybe I should have stated my last question differently. I meant that in the context of checking that the data is correct, it would be the same as writing the duplicate code from scratch.

Good units tests, especially for UI entry are difficult to envision. Have a look at https://news.ycombinator.com/item?id=15432567 where I tried to sketch a general way to address this class of problems.

Post reply on HN