Live data from Hacker News

Apple's SSL/TLS bug

imperialviolet.org

171–180 of 295 posts

Re: Apple's SSL/TLS bug

#171
post #88
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…

Regarding hidden in plain sight, would a semicolon at the end of the if statement throw a warning? Would be a little more hidden.

Yeah, that'd trigger a warning in most compilers - "Empty statement found. Was it an intent?" or something similar.

Re: Apple's SSL/TLS bug

#172

Worth noting that static analysis finds bugs like this immediately. TLS code seems like the perfect candidate to run through static analysis on every checkin. There are products such as Coverity and PVS-Studio that would have immediately flagged this and probably some open-source ones built around LLVM as well (unsure about this one, though). I personally use Coverity and have it hooked up in the same way everyone co…

5 lines of a unit test also verify this:

https://github.com/landonf/Testability-CVE-2014-1266/blob/ma...

Re: Apple's SSL/TLS bug

#173
post #136

Earlier quoted context omitted.

There is no patch for Mavericks out yet. :-(

I thought Apple's policy was to not release these sort of security notices until a fix was in place?

That's partially why people are so upset. Mavericks is still very much vulnerable to a publicly acknowledge bug with many PoCs out.

Re: Apple's SSL/TLS bug

#174

The code is crap and while I can understand why a single person might have written it this way, I think any organization of full-time professional software developers should be collectively embarrassed to have accepted it. The only reason to use the "goto fail;" idiom is to free two buffers before returning. But the buffers in question are just sslBuffer structs that live on the local stack. Their destructors will be…

Nope, it's actually pretty decent C. With a bug.

Re: Apple's SSL/TLS bug

#175
post #45

Worth noting that static analysis finds bugs like this immediately. TLS code seems like the perfect candidate to run through static analysis on every checkin. There are products such as Coverity and PVS-Studio that would have immediately flagged this and probably some open-source ones built around LLVM as well (unsure about this one, though). I personally use Coverity and have it hooked up in the same way everyone co…

There is no excuse to bypass static analysis nowadays. At very least should be part of the continuous integration build. The problem are the many developers that still think they are perfect and know the full C standard, including undefined parts.

Unfortunately the decision to use static analysis tools would have to come from developers who are comfortable admitting they make mistakes sometimes.

It takes a special kind of ego to write an SSL library with no unit tests, not turn on compiler warnings, and not use static analysis tools.

Re: Apple's SSL/TLS bug

#176
post #76

Earlier quoted context omitted.

Funny thing is, I was finally looking at Rust the other day and thought, hey, that's nice that if statements are forced to have braces, I never liked one-liner if statements in C. And here we have a perfect example of what can happen with the brace-less if statements.

Yeah, it seems like this is something many newer languages are requiring, which is good. Go requires braces as well.

Requiring braces is the wrong solution to the problem. It's the indentation that misleads here; indentation is what people look at to see what's part of which if, so have the language look at the same thing, like Python does.

Re: Apple's SSL/TLS bug

#177

This could not have happened with C++ exceptions and RAII instead of manual error checking and goto for cleanup ;)

No, you're worse off in C++, where the semantics of exceptions (especially in the area of resource allocation and deletion) are complex and hard to reason about.

I've done a bunch of kernel and other systems work in C and in C++, and my experience is that the C is a lot clearer. This type of code is all about not having magic side effects; everything needs to be in the open and very plain, or bugs start to get pretty subtle and hairy.

I'm not saying "Don't do systems programming in C++", because clearly you can. But it takes discipline to succeed, probably more discipline than you need to apply than if you're writing C.

Re: Apple's SSL/TLS bug

#178
post #13

Earlier quoted context omitted.

I cringe whenever I hear people advocating that it's okay to avoid braces with single-statement conditionals/loops/etc. This is a perfect example of just how bad that suggestion is, and just how disastrous it can be. It's totally worth typing a few extra characters here and there to basically avoid these kind of situations completely.

I do write single statement conditionals without braces, but I write them on one line, which emphasizes the single-statement nature: if (something) do_something(); Instead of: if (something) do_something(); So it's much less likely that I'll confuse indentation with a block scope.

your first example is okay, but for me, I'll do this;

if(something) {do_something();}

Many code editors will easily insert curly brace pairs, so it's really just a single extra key stroke you're saving.

Re: Apple's SSL/TLS bug

#179
post #39

Earlier quoted context omitted.

In general, NSA is not my most serious threat (in terms of actual harm; they are the most powerful by far though) -- I agree they overreach, and for some people are a serious threat, but for me my primary concerns are Chinese/other foreign intel (who are documented as going after industrial/economic material much more than NSA) and independent/criminal/etc. types. The scary thing is the bar is so low; even I could tu…

> NSA is not my most serious threat I wish more people understood this. Not to let NSA off the hook (what they are doing is awful), but the threat posed by the NSA is a higher-level down the road/slippery slope threat. There are other more immediate and real dangers out there that are actively trying to steal whatever they can find.

It also very much depends on which side of the Atlantic you are living on.

Re: Apple's SSL/TLS bug

#180

Earlier quoted context omitted.

Exactly this This also applies to the "JS without ;" crowd. You may think you're too good to know all the rules of ; or you can just don't think about it, and worry about other things instead, like your code.

I hate omitting braces, but Javascript semicolon omission is a totally different argument. It's easy to show simple cases where omitting braces causes problems. It's actually quite difficult and artificial to find cases where (especially with "use strict") semicolons confer any benefit at all, and in some cases they make things worse (e.g. multi-line variable declarations). Also, "correct" use of semicolons in Javasc…

"It's actually quite difficult and artificial to find cases where (especially with "use strict") semicolons confer any benefit at all,"

Hence these are the cases where more time and resources will be wasted because of it.

"I certainly see far more bugs caused by an improperly inserted semicolon"

What would be an example of this? Because I've seen exactly zero bugs of this type (not counting typos, of course)

Post reply on HN