Live data from Hacker News

Apple's SSL/TLS bug

imperialviolet.org

41–50 of 295 posts

Re: Apple's SSL/TLS bug

#41
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.

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 Javascript makes code less consistent (e.g. some function declarations end with a semicolon, others do not) whereas consistent use of braces is consistent.

I certainly see far more bugs caused by an improperly inserted semicolon than an improperly omitted semicolon, but then I'm looking at jshinted code most of the time.

Re: Apple's SSL/TLS bug

#42

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

It could actually. Exceptions and RAII are not resilient against typos and programmer error. If the exception handler caught the wrong type, for example catching by value instead of reference, instead of having a catch(...) it would have the same problem as the above. It's harder to spot this sort of error than a double goto and incorrect parentheses - because you have to check the code that throws and the code that catches.

Admittedly in the scenario I lay out - what happens is an error is thrown and not caught, rather than a check being skipped, but the net effect is equivalent - and it takes 1 character out of place to invoke.

Re: Apple's SSL/TLS bug

#43

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.

There is such a tool, clang-format in 3.4 does as you expect.

This is what happens if you try the same thing in it http://imgur.com/syt6LuU.

I have emacs setup to auto run clang-format on each save of cc-mode files. I can't NOT notice this stuff now.

Re: Apple's SSL/TLS bug

#44

I just made this - it'll tell you if you're vulnerable. https://gotofail.com/ Not very well tested, please let me know if it works for you. If you're on OS X Mavericks or on iOS 7 and haven't patched you should get big scary red text. Edit: posted here https://news.ycombinator.com/item?id=7282164

Safari/iOS 4.3.3: not vulnerable Safari/i0S 7.0.4: VULNERABLE Chrome/iOS 7.0.4: not vulnerable Looks like using Chrome instead of Safari may help; I'd say it would be more interesting if standard mail client can be fooled.

I would be shocked if this doesn't apply to the email client as well.

Re: Apple's SSL/TLS bug

#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.

Re: Apple's SSL/TLS bug

#47

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

Sadly it could, because of the C compatibility you can never be sure if a developer wouldn't write something like this.

The same applies to any other language that allows for copy-paste of C code.

Re: Apple's SSL/TLS bug

#48
post #4
post #2

If only it was open source this never would have happened.

Once eyeballs are thinly spread over enough projects, all bugs are deep again.

In what possible reality was this not the inevitable outcome? The "enough eyeballs" aphorism makes for a nice soundbite but in practice was always a red herring.

Re: Apple's SSL/TLS bug

#49

I just made this - it'll tell you if you're vulnerable. https://gotofail.com/ Not very well tested, please let me know if it works for you. If you're on OS X Mavericks or on iOS 7 and haven't patched you should get big scary red text. Edit: posted here https://news.ycombinator.com/item?id=7282164

"If you're on OS X Mavericks or on iOS 7 and haven't patched"

how do I patch on OS X Mavericks? Software update shows nothing to update

Re: Apple's SSL/TLS bug

#50
post #24

Emerging tools such as gofmt and clang-format are able to automatically re-format your code based on the language rules rather than the human behind the monitor. Using those tools this specific category of issues should at least be visible in the formating diff. Interesting. Never thought about it that way before.

Those kinds of tools aren't new or emerging. The "indent" utility for C has been around for decades. I first remember using it on 4.3BSD, but it may have been around before that.

Sure, the idea is not new. Using the compilers libraries and internal representation to re-format your code is new, though.

You want the compilers knowledge of the code for this, e.g. while formating C++ template mess.

There's a tight integration into the actual toolchains, which is a good thing.

Post reply on HN