Can you apply human-security thinking to digital forensics… and determine whether that critical security flaw was a bug or a malicious bug-door?
Nadim “Cats in Ur Crypto” Kobessi has an interesting take on the Apple SSL bug. The bug in question was a single, duplicated line of code with serious implications — anyone could execute “man in the middle” attacks on iOS and Mac OS despite an ostensibly secure connection.
This is ideal for agencies like, oh, the NSA.
Nadim points out that the psychology of coding means we can predict what’s a “reasonable” bug to expect. In this case, the bug in question was most certainly NOT reasonable.
This still leaves the question of a mechanical error (did someone paste something twice, and incompletely delete their mistake?), which Nadim doesn’t address. But a quick look at the offending line 631 of the code  suggests nobody changed any of the surrounding bits.
In other words, there’s no real reason for some copy paste magic either. As one commentator put it, the “bug” line “appears seemingly out of nowhere.” 
To further reinforce the case, none other than l0pht hacker extraordinare, former US Defence Advanced Research Projects Agency program manager, and now Googler Peter “Mudge” Zatko puts it this way.
“When I attacked systems (ahem, sanctioned of course), C control statements w/o braces were a favorite target.” 
“to clarify: [the Apple SSL bug is] similar to what I would leave in the source trees.” 
“Check line 631. Appears seemingly out of nowhere.”
.@andreasdotorg @frank_rieger when I attacked systems (ahem, sanctioned of course), C control statements w/o braces were a favorite target.
@andreasdotorg @frank_rieger to clarify: that’s similar to what I would leave in the source trees. #coincidence
” My blog post is much less ambitious and focuses on one question: if we evaluate the bug aesthetically, without any knowledge of the circumstances that led to it, does it appear more like a bug or more like a backdoor?[…]
Generally, when there is a security bug in a piece of code, it is the case that the programmer wrote the bug falsely thinking that they were contributing something positive to the code (this is what happens every time I am the source of a security vulnerability).
However, there is no reasonable practical reason that I can imagine for putting two goto statements, that point to the same method, right after each other. I simply can’t come up (and I don’t think anyone can) with a use case where this could be useful. This is because once the first goto is identified, execution jumps to (or goes to, so to speak) the referenced method and continues from there, end of story. The second goto statement is never needed and can’t possibly be construed as offering something useful, even innocently. So why was it added in this diff (line 631)? What was the reasoning? This is an unanswered question.