Live data from Hacker News

Apple's SSL/TLS bug

imperialviolet.org

281–290 of 295 posts

Re: Apple's SSL/TLS bug

#281
post #8

It's interesting watching all the speculation about "was it a backdoor, or just a bug?" Lots of points in favor or against: 1) It's a huge compromise, and "open" to anyone to exploit, which would ultimately get caught and fixed faster. But it's also not targeting anything specific, so there's less of a signature of the attacker. 2) Incredibly simple, and thus a plausible mistake. 3) Hidden in plain sight I'd generall…

I believe the faulty function -- at line 574 -- is a copy/paste of another function located at line 328 in the same file.

I diff'ed both functions to try to understand the changes which may have been made.

The "goto fail;" is somewhat "drowned" into other changes around, so it stands out less using a diff tool because of these surrounding changes. The surrounding changes in question:

1) Moving a "SSLFreeBuffer(&hashCtx)" instruction at a higher position: Very strange since it accomplish absolutely nothing at its new position, as opposed to it's original position.

2) Renaming of two variables: "hash" became "hashOut" and "exchangeParams" became "signedParams".

3) Indentation of "goto"s

Without the above changes, the "goto fail;" stand out rather well when using a diff tool.

Re: Apple's SSL/TLS bug

#282
post #100

Earlier quoted context omitted.

Sure, this aligns with interests, but the bug's existence is predicated on the entire code base being written with substandard style rules and no static analysis or tests , which suggests to me that incompetence got here first.

> entire code base being written with substandard style rules and no static analysis or tests, which suggests to me that incompetence got here first. That and inadequate, bordering on zero, code review. Even a beginner C programmer looking at this code could see how fishy it looks. No code review while checking in code to libssl. That takes a lot of incompetence.

That takes a lot of incompetence.

"Any sufficiently advanced incompetence is indistinguishable from malice"

https://support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT...

We begin therefore where they are determined not to end, with the question whether any form of democratic self-government, anywhere, is consistent with the kind of massive, pervasive, surveillance into which the Unites States government has led not only us but the world.

This should not actually be a complicated inquiry.

http://snowdenandthefuture.info/events.html

Re: Apple's SSL/TLS bug

#284
post #96

Earlier quoted context omitted.

Indeed the only secure OS nowadays is Linux. Everything else should be considered compromised by default a priori.

"Indeed the only secure OS nowadays is Linux." You're kidding, right? http://www.debian.org/security/ Edit: There were multiple security issues in OpenSSL as recently as January. http://www.debian.org/security/2014/dsa-2833

We need to stop using OpenSSL. A new crypto stack coded in a provably secure language is sorely needed.

Re: Apple's SSL/TLS bug

#285
post #113

Earlier quoted context omitted.

True, but I've definitely noticed that particular style of writing if tests using a one-line assignment and obscured test condition seems to be pretty common in the Go community and it's a bad habit for understanding code.

>>it's a bad habit for understanding code. Is there objective evidence for this? As a Go programmer a semicolon in an if statement screams to me. I can see it possibly being in issue for new Go programmers- but I don't remember it being one for me.

I didn't do a survey but I remember that and frequently punting on error handling (`res, _ = something_which_could_error()`) showing up enough in the projects I saw on Github to stand out as a trend when I was writing a few first programs. I certainly hope that's just sampling error.

Re: Apple's SSL/TLS bug

#286
post #228

I wonder if this would have as much attention without the Snowden leaks. I guess yes. Not to be a conspiracy theorist, but history tells that computer technology was released to the public, so to me it still looks like there is no absolute objective, safe way to use a computer for a layman. It still looks more like a tool of surveillance than a tool of communication. You'd want my opinion, but I'd be apple (or Linux…

You cannot sue a programmer for writing a bug in software, or at least it would be thrown out immediately. It is the company's responsibility to ensure that the code is peer reviewed and tested before deploy. There are so many bugs in software, that this would be a terrible standard to set, and no developer would be safe. The best a company could do is fire them, but even that is unlikely.

Re: Apple's SSL/TLS bug

#287
post #228

I wonder if this would have as much attention without the Snowden leaks. I guess yes. Not to be a conspiracy theorist, but history tells that computer technology was released to the public, so to me it still looks like there is no absolute objective, safe way to use a computer for a layman. It still looks more like a tool of surveillance than a tool of communication. You'd want my opinion, but I'd be apple (or Linux…

You cannot sue a programmer for writing a bug in software, or at least it would be thrown out immediately. It is the company's responsibility to ensure that the code is peer reviewed and tested before deploy. There are so many bugs in software, that this would be a terrible standard to set, and no developer would be safe. The best a company could do is fire them, but even that is unlikely.

> You cannot sue a programmer for writing a bug in software ...

Of course you can.

> It is the company's responsibility ...

Not if the programmer was hired for his independent expertise rather than to be told what to do, and how to do it, by higher-ups. That's a a common arrangement in small companies.

> There are so many bugs in software, that this would be a terrible standard to set, and no developer would be safe.

All true, but surely you realize that lawyers and judges don't necessarily ask themselves, "Is this fair?"

Remember that a group of scientists were successfully convicted of manslaughter in Italy for not predicting an earthquake. It was a different country and legal system, but not that different.

http://abcnews.go.com/International/scientists-convicted-man...

The handwriting is on the wall.

Re: Apple's SSL/TLS bug

#288

Can't wait for Apple to patch this bug? Downgrade to 10.8.5 ... The answer here, folks, is don't update until all the bugs have been found and fixed. Apple's golden days of OS updates was back in 10.6, when they spent most of the time just fixing bugs rather than adding new features. Every OS update since has had as many bugs as it fixed, though overall things were getting better. It's the old Wait-until-SP1 advice.…

> The answer here, folks, is don't update until all the bugs have been found and fixed.

How can you ever be sure of this? And also I can almost guarantee that there is no non-trivial software that is bug free. As a programmer the only way you can guarantee bug-free code is to not program at all.

So if you follow this advice, you will never update at all, which in my opinion is bad because the benefits of an update outway the negatives.

Re: Apple's SSL/TLS bug

#289
post #287

Earlier quoted context omitted.

You cannot sue a programmer for writing a bug in software, or at least it would be thrown out immediately. It is the company's responsibility to ensure that the code is peer reviewed and tested before deploy. There are so many bugs in software, that this would be a terrible standard to set, and no developer would be safe. The best a company could do is fire them, but even that is unlikely.

> You cannot sue a programmer for writing a bug in software ... Of course you can. > It is the company's responsibility ... Not if the programmer was hired for his independent expertise rather than to be told what to do, and how to do it, by higher-ups. That's a a common arrangement in small companies. > There are so many bugs in software, that this would be a terrible standard to set, and no developer would be safe.…

> Not if the programmer was hired for his independent expertise rather than be told what to do, and how to do it, by higher-ups. That's a a common arrangement in small companies.

1. That does not excuse software from a proper code review process, in fact any reasonable software company would probably see this as even more of a reason to code review the code. If I knew that a software company doesn't properly review critical code, I would definitely think twice about using that company's software.

2. Apple is not a small company so that doesn't excuse them in this case.

>All true, but surely you realize that lawyers and judges don't necessarily ask themselves, "Is this fair?" Remember that a group of scientists were successfully convicted of manslaughter in Italy for not predicting an earthquake. It was a different country and legal system, but not that different. http://abcnews.go.com/International/scientists-convicted-man....

Come on this is the Italian legal system. No offense to Italy, I believe it to be a beautiful country, but they have had a shocking record in their legal system as of late. And I highly doubt that this would have stood up in many other western legal systems.

But even if I concede to all your points, someone on HN should be smart enough to realise that suing someone for a software bug would definitely not be a smart move. And we definitely shouldn't be recommending such a thing. Just like we shouldn't be recommending scientists to be convicted of manslaughter for not predicting an earthquake.

Re: Apple's SSL/TLS bug

#290

If blocks without curly braces ಠ_ಠ

Interesting that, if there was a source code formatting tool (like gofmt for go), it would've made the bug easier to spot because the 2nd goto would lose it's misleading indentation.

The `indent` tool has been part of the normal BSD distro for decades, I think.
Post reply on HN