Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple's SSL/TLS bug

imperialviolet.org

Post reply on HN
Print view View original

81–90 of 295 posts

Re: Apple's SSL/TLS bug

#81

Post by laureny »

taylodl wrote: post #26

Dijkstra always contended GOTOs were harmful! In all seriousness it's unfortunate the C family of languages even allow this kind of bug - we've all been bitten by it at one time or another.

> Dijkstra always contended GOTOs were harmful!

- The bug here has nothing to do with GOTO.

- Dijkstra said a lot of stupid things, this is one of them. Parsimonious use of GOTO is fine and sometimes leads to clearer code (exiting deeply nested conditions for example).

- Another stupid thing that Dijkstra said is that anyone who started by learning BASIC has their brain corrupted forever, which is total nonsense (I bet most people reading this started with BASIC and turned out just fine).

Re: Apple's SSL/TLS bug

#82

Post by laureny »

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

Re: Apple's SSL/TLS bug

#83

Post by praseodym »

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?

Apple introduced -Weverything because suddenly changing the scope of gcc's -Wall (which indeed does not include everything) would break a lot of builds.

Re: Apple's SSL/TLS bug

#85

Post by acdha »

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?

Excessive fear of backwards compatibility: you make -Wall. People use it. You add a new check which will reject some shoddy code. “What if people complain that their project no longer builds with -Wall? Let's add a new setting…”. Repeat…

I've been wondering how hard it would be to get to the point where the defaults are rigorous and developers have to opt out with specific -Wno-… options.

Re: Apple's SSL/TLS bug

#86

Post by hub_ »

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

Suggestion to clang and gcc developer: implement -Wmandatory-curly-braces

At least, short of making it mandatory it would at least signal bad style.

Re: Apple's SSL/TLS bug

#87

Post by modeless »

rdl wrote: post #54

Unfortunately OSX does not appear patched even in the latest developer center 10.9.2 build (13C62). Tested in both Safari and OS-distributed curl. Chrome/Firefox of course is still fine since it uses the NSS stuff, but plenty of OS services use the OS crypto. (I'm violating NDA by commenting on pre-release Apple stuff, of course.) Windows or ubuntu bootcamp until they fix this, I think.

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.

Re: Apple's SSL/TLS bug

#88

Post by Varcht »

rdl wrote: 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.

Re: Apple's SSL/TLS bug

#89

Post by Schlaefer »

[deleted] wrote: post #80
jdsnape wrote: post #15

This shows another of the benefits for the community of open sourcing code - because we can see exactly where and what the bug was steps can be taken in other projects to stop it happening there (I think Adam mentioned he was going to check for a test case in Chrome). If the code was closed all we would have is Apple's release note which just says validation steps were skipped...

[deleted]

He didn't say it isn't OSS. He just pointed out that it is educational to see the actual code as we do in this OSS case.

Re: Apple's SSL/TLS bug

#90

Post by pjmlp »

laureny wrote: post #78
pjmlp wrote: post #45

Earlier quoted context omitted.

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.

That's a rare problem among developers. The more common problem is that developers make mistakes. All of them. Static analysis, regression tests and turning on all the warnings you possibly can should be mandatory, especially for such critical pieces of code.

> That's a rare problem among developers.

Many of the C guys I met along my career thought otherwise.

> Static analysis, regression tests and turning on all the warnings you possibly can should be mandatory, especially for such critical pieces of code.

+1

Post reply on HN