Apple SSL/TLS bug is possibly a deliberate job(gist.github.com)
gist.github.com
Apple SSL/TLS bug is possibly a deliberate job
https://gist.github.com/alexyakoubian/9151610/revisions
22 comments
Did you look at the diff? Did you see that it is the only diff in that hunk? Do you not agree that that is - at the very least - suspicious?
Yes, I looked at the diff. A diff like the author probably had been looking through all day. You've never missed a line? They probably thought it was just whitespace changes or, you know, just missed it entirely.
If we're going to claim this is deliberate, then the same accusation can be levelled at every security bug ever introduce in an edit. This is not evidence, it's just trolling.
If we're going to claim this is deliberate, then the same accusation can be levelled at every security bug ever introduce in an edit. This is not evidence, it's just trolling.
Not really, most editors support the ability to duplicate a line using CMD+D, including AppCode by JetBrains. In my case, using Colemak, S is mapped to D, and so if I'm in the wrong keyboard layout, I'll go to save and end up duplicating a line, then saving by hitting the right key. If I'm not careful, I'll have saved a duplicate line without noticing.
Similarly, given how the rest of the changes seemed to be attempts to rename and clean up the API, I expect that it was a junior intern cleaning up code as a whole. It would be more interesting to see the history of the commits, but that's not public (that I know of). It does highlight how we get that data with Google's Android, even though the development and release process is basically the same.
Similarly, given how the rest of the changes seemed to be attempts to rename and clean up the API, I expect that it was a junior intern cleaning up code as a whole. It would be more interesting to see the history of the commits, but that's not public (that I know of). It does highlight how we get that data with Google's Android, even though the development and release process is basically the same.
[deleted]
Why does the fact that it's the only change in that hunk make it suspicious?
"Bug is possibly an inside job"
And the author of that headline is possibly beating his wife.
And the author of that headline is possibly beating his wife.
Maybe but let's not assume that the author is male.
... let's not assume being the point of the comment. :)
Do we also have to rename the "wife-beater" shirts to "significant-other-beater" shirts?
I admire your sentiment but the phrase is a historical reference. http://en.wikipedia.org/wiki/Loaded_question
[deleted]
If I understand correctly this is the diff between two releases of this code, and we have no way of knowing what each checkin, including the culprit, actually looked like.
So even though at the two end points we see the addition of only one line in a block (which is being touted as the justification for this accusation), the intermediate steps could have included the addition and subtraction of other lines in that block.
(A plausible example might be the addition of another hash updating if statement + goto fail, then the removal of only the if statement.)
So even though at the two end points we see the addition of only one line in a block (which is being touted as the justification for this accusation), the intermediate steps could have included the addition and subtraction of other lines in that block.
(A plausible example might be the addition of another hash updating if statement + goto fail, then the removal of only the if statement.)
As a security person I enjoy blaming the NSA and conspiracies as much as anyone.
That said sorry but I don't buy this. Just seeing a diff with that one + makes me more inclined to believe there was an if(...) goto fail that someone removed without removing the statement as well.
There is more than enough incompetence in our industry that a deliberate job is completely unnecessary, why bother when engineers break security all the time anyways?
That said sorry but I don't buy this. Just seeing a diff with that one + makes me more inclined to believe there was an if(...) goto fail that someone removed without removing the statement as well.
There is more than enough incompetence in our industry that a deliberate job is completely unnecessary, why bother when engineers break security all the time anyways?
For the lazy: the interesting part is on line 630.
when was that change made?
The diff is between the two relevant releases of this code - 10.8.5 [1] and 10.9 [2].
[1] - http://opensource.apple.com/source/Security/Security-55179.1...
[2] - http://opensource.apple.com/source/Security/Security-55471/l...
[1] - http://opensource.apple.com/source/Security/Security-55179.1...
[2] - http://opensource.apple.com/source/Security/Security-55471/l...
thanks!
And this is why I can't understand why people don't use matching braces in my control structures. Not using them is asking for this kind of error.
There is a phrase that I really like - Never attribtue to malice that which can be adequately explained by stupidity.
Even if its Apple and really tempting to target I don't buy it.
Even if its Apple and really tempting to target I don't buy it.
Aren't all bugs inside jobs?
If we're going to entertain conspiracy theories, I favour "A rogue Google agent snuck in to Apple headquarters and edited the file whilst the user was out for lunch". Or perhaps Zergloids. Come on people, we're getting as bad as Slashdot over here!