Apple's SSL/TLS bug

Post by Agathos » Sat, Feb 22, 2014, 5:01 PM UTC

oneeyedpigeon wrote: post #72

throwaway_yy2Di wrote: post #62

Earlier quoted context omitted.

A quick test shows neither -Wall nor -Wextra report anything on either gcc or clang. However, clang's -Weverything does complain (it implies -Wunreachable-code). Confusingly, gcc accepts -Wunreachable-code as a valid option, but then proceeds not to warn anything. (edit): Which is a known bug apparently, http://gcc.gnu.org/ml/gcc-help/2011-05/msg00360.html

The real WTF is those Warn flags, then. In what sane world does "extra" mean more than "all", and "all" and "everything" mean different things?

Post by acdha » Sat, Feb 22, 2014, 5:05 PM UTC

voidlogic wrote: post #105

acdha wrote: post #95

Earlier quoted context omitted.

I would probably flag the code above in a security review because it hides the key part at the end of a complex line. Unless you're coding on VT100 terminal it's worth the extra line to make the test logic incredibly obvious: err = SSLHashSHA1.update(&hashCtx, &serverRandom); if (err != nil) { return err; }

In actual code things would not be named as they were above and it would be shorter, I was just trying to make it look reasonably like the C for HN.

Post by nikbackm » Sat, Feb 22, 2014, 5:08 PM UTC

laureny wrote: post #82

nikbackm wrote: post #28

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

Any language that lets you omit braces for single statements is prone to this bug, which includes C++.

Post by acdha » Sat, Feb 22, 2014, 5:12 PM UTC

atmosx wrote: post #96

modeless wrote: post #87

Earlier quoted context omitted.

MITM of any SSL connection in Safari and other system apps, and they couldn't even bother to have an OS X patch ready at the same time as the disclosure for iOS? I think anyone relying on the security of OS X is going to have to seriously rethink their OS choice after this.

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

Post by nikbackm » Sat, Feb 22, 2014, 5:15 PM UTC

eliasmacpherson wrote: post #98

nikbackm wrote: post #58

Earlier quoted context omitted.

I don't see the possibility for catching the wrong type (or not catching it) if you get one character wrong. Unless of course you have two valid type names that just differ in one character, but that is a general pitfall and not exception specific. If you always throw by value (and not by pointer) then it does not matter if you catch by value or by reference, the catch block will be activated either way. The only iss…

Ok for example: int e; int update() { throw &e; } the & is the one character - it's a typo - only catch(...) will catch it.