Re:On the Timing of iOS’s SSL Vulnerability and Apple’s ‘Add...
by terminus on Sunday February 23, 2014 @12:03AM
(#7285002)
> But there is no guarantee of anything unless the reviewer is incapable of making mistakes, in which case you could just ask him to write the code in the first place.
Did you look at the bug? I'll quote it here:
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
Even somebody with basic programming skills can see that's wrong. And, remember this is libssl. Any checkins to that warrant thoroughness if not paranoia.
Re:On the Timing of iOS’s SSL Vulnerability and Apple’s ‘Add...
by stormbrew on Sunday February 23, 2014 @02:20AM
(#7285221)
In the CR tool I assume it may have looked more like this:
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
- if ((err = SSLHashSHA1.update(&hashCtx, &somethingElse)) != 0)
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
Which is a little harder to see. Obviously you should always look at it in a side-by-side view (god I wish github would implement this) or at the resulting code, but people are imperfect.
Re:On the Timing of iOS’s SSL Vulnerability and Apple’s ‘Add...
by nickls on Sunday February 23, 2014 @04:56AM
(#7285436)
Doesn't look like any (major) modification to surrounding lines.
if ((err = ReadyHash(&SSLHashSHA1, &hashCtx, ctx)) != 0)
goto fail;
changes to: if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
goto fail;
See:
http://www.diffnow.com/?report=ob51kDiff35
Re:On the Timing of iOS’s SSL Vulnerability and Apple’s ‘Add...
by pmjordan on Sunday February 23, 2014 @11:05AM
(#7286255)
We only see the diff between released versions, not intermediate commits. For all we know, Apple developers use a single-pane diff tool, where such bugs are easy to miss.
Re:On the Timing of iOS’s SSL Vulnerability and Apple’s ‘Add...
by oneeyedpigeon on Sunday February 23, 2014 @04:50AM
(#7285426)
Damn fine point. I really don't think we can conclude this is malice; do all of our own bugs always turn out to be really tricky to spot? Do we never make utterly ridiculous mistakes along these lines?
Re:On the Timing of iOS’s SSL Vulnerability and Apple’s ‘Add...
by wreegab on Sunday February 23, 2014 @04:59PM
(#7287797)
Except that I don't think this was the original code considering it appears to be cut and paste of same code in same file. I commented on this: https://news.ycombinator.com/item?id=7286582
Re:On the Timing of iOS’s SSL Vulnerability and Apple’s ‘Add...
by temujin on Sunday February 23, 2014 @08:58AM
(#7285896)
I seriously don't understand why so many people don't habitually use braces there...
if (...) {
goto fail;
}
if (...) {
goto fail;
goto fail;
}
if (...) {
goto fail;
}
tada, not actually a bug!
Re:On the Timing of iOS’s SSL Vulnerability and Apple’s ‘Add...
by rsfinn on Sunday February 23, 2014 @11:39AM
(#7286430)
Which is fine, but in my experience flaws like this are often introduced via automated merges that could as easily have resulted in:
if (...) {
goto fail;
}
if (...) {
goto fail;
}
goto fail;
if (...) {
goto fail;
}
which produces the same bug. (Everyone's been shouting about "braces in single statement if clauses" as though they're an absolute fix; they're not, although they're a good idea in general. And yes, code review, better merge tools, yada yada.)
Code reviews only mean your code is going through two sieves instead of one.
Of course it helps. But there is no guarantee of anything unless the reviewer is incapable of making mistakes, in which case you could just ask him to write the code in the first place.