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

251–260 of 295 posts

Re: Apple's SSL/TLS bug

#251

Post by cwzwarich »

_pmf_ wrote: post #159
apaprocki wrote: post #23

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…

> Worth noting that static analysis finds bugs like this immediately. I'd like to point out the case where Debian maintainers "fixed" a "bug" discovered by static analysis; https://blog.isotoma.com/2008/05/debians-openssl-disaster/ .

Valgrind is dynamic analysis, not static analysis.

Re: Apple's SSL/TLS bug

#252

Post by joe_bleau »

emmelaich wrote: post #221
joe_bleau wrote: post #125

Earlier quoted context omitted.

Yep, PC-lint from Gimpel catches it: Error -> Warning 527 Unreachable code at token 'ret' (col 12)

Nice. Does PC-lint give a lot of false negatives and positives as well?

If the code hasn't been linted, expect lots of false positives. I usually have to disable entire classes of less serious warnings to notice the errors, then slowly work through to the less serious stuff.

Re: Apple's SSL/TLS bug

#253

Post by gsnedders »

llimllib wrote: post #57
arielweisberg wrote: post #56

How is this code not covered by a unit test? I'll admit I don't think of myself as great at unit testing, but the first thing I do when writing one for a new tool or class is use a code coverage tool to look for uncovered lines and once I have written a few basic behavioral tests I write tests to exercise and validate the output of the uncovered lines. This ensures that the tests I write to cover the public API don't…

> How is this code not covered by a unit test? ...or an integration test. or a functional test. When you write an SSL lib, I suspect that at some point you ought to test that it checks f%^&ing certificates :/

The standard of testing for all SSL/TLS libraries is atrocious, it's not even like SecureTransport is notably worse than most others… :'(

Someone badly needs to sit down and write — preferably a black-box, so it can be used for all — testsuite for SSL/TLS.

Re: Apple's SSL/TLS bug

#254

Post by lunixbochs »

lstamour wrote: post #225
lunixbochs wrote: post #208

Earlier quoted context omitted.

If the code to Security.framework is complete and builds, we might not need to patch the binary directly.

It appears to be in a cursory glance. Loaded for me in Xcode. That said, signing the security framework would be another issue ;-) I can't imagine apple would let malware replace security binaries that easily.

It's almost buildable for me: https://news.ycombinator.com/item?id=7283601

I think it'd break one of the binaries, but I could replace that with the real one.

Re: Apple's SSL/TLS bug

#255

Post by brymaster »

dippyskoodlez wrote: post #241
brymaster wrote: post #164

Earlier quoted context omitted.

Disagree. They can't even keep the lock screen secure. Any major or point release there's been a bypass exploit.

Android has a flawless record, though. http://www.androidcentral.com/samsung-lock-screen-bypassed-e...

Who said anything about Android?

You might find this article a good read: http://www.theverge.com/2014/1/21/5307992/inside-the-mind-of...

Re: Apple's SSL/TLS bug

#256

Post by beachstartup »

kabdib wrote: post #244
beachstartup wrote: post #193

Earlier quoted context omitted.

this pattern is structured to avoid the use of an additional stack (local) variable to track a condition, and to skip superfluous execution of code once that condition is detected. i've used it myself to optimize inner loops of very simple un-accelerated graphics rendering code (which sped it up considerably, since it is potentially skipping many levels of unnecessary execution on the cpu, millions of times), but i a…

The code already has that condition variable ('err'), the goto is to avoid execution of code that should not be executed. It's not about avoiding additional stack -- that was probably the last thing on the programmer's mind. The idiom is about error handling.

i didn't see that. that makes it even worse. this design is supposed to avoid that extra var.

Re: Apple's SSL/TLS bug

#257

Post by grogenaut »

peteretep wrote: post #242
MatthiasP wrote: post #179

Earlier quoted context omitted.

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

More likely Pacific

Asia is technically on the other side of the atlantic as well, just further that way. Just to out pedantic you.

Re: Apple's SSL/TLS bug

#258

Post by grogenaut »

SideburnsOfDoom wrote: post #216
ams6110 wrote: post #143

Earlier quoted context omitted.

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.

> I do write single statement conditionals without braces, but I write them on one line That's fine until you write if (something) do_something(); do_something(); or worse: if (something); do_something(); I've actually seen something very similar to that one. You haven't really changed the dimensions of the problem by putting it all one one line. Only the whitespace is different. Sure it looks wrong to you; but so do…

well you can also write:

if (something); { do_something(); }

So..

Re: Apple's SSL/TLS bug

#259

Post by gsg »

SideburnsOfDoom wrote: post #216
ams6110 wrote: post #143

Earlier quoted context omitted.

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.

> I do write single statement conditionals without braces, but I write them on one line That's fine until you write if (something) do_something(); do_something(); or worse: if (something); do_something(); I've actually seen something very similar to that one. You haven't really changed the dimensions of the problem by putting it all one one line. Only the whitespace is different. Sure it looks wrong to you; but so do…

Note that braces won't save you from

    if (something); { do_something(); }
(Personally, I configure my editor to highlight if (...); in bright red.)

Re: Apple's SSL/TLS bug

#260

Post by Turing_Machine »

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.

"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

Post reply on HN