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

231–240 of 295 posts

Re: Apple's SSL/TLS bug

#231

Post by [deleted] »

lisper wrote: post #142
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.

Since the source code is available, might it be possible to produce a hot patch to the binary so that those of us running Mavericks won't have to go through the next few days or weeks with our pants down? It would be a simple matter of finding the JMP instruction generated by the second GOTO and replacing it with no-ops. How hard could it be,at least for someone who actually knows their way around OS X binary file fo…

[deleted]

Re: Apple's SSL/TLS bug

#232

Post by tlrobinson »

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…

Has the author of the buggy code been identified?

Re: Apple's SSL/TLS bug

#233

Post by emmelaich »

lmm wrote: post #176
Jayschwa wrote: post #153

Earlier quoted context omitted.

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.

Indeed, but I wonder if indenting would have helped here.

Two gotos immediately after one another at the same indentation level is obviously wrong by visual inspection.

Proper indentation might have led the casual viewer to think that the code was actually ok!

Re: Apple's SSL/TLS bug

#234

Post by corresation »

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…

3) Hidden in plain sight

I'm baffled that this wasn't caught long, long ago. Most of us have worked with internal systems where certs, for whatever reason, don't match the site, and it's surprising many people haven't noted that such doesn't raise any errors on iOS/OSX.

Though thinking back....I actually remember encountering exactly that on the iPad once, surprised that it didn't raise a flag. Like probably most I just shrugged and continued on.

Re: Apple's SSL/TLS bug

#235

Post by mehrdada »

corresation wrote: post #234
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…

3) Hidden in plain sight I'm baffled that this wasn't caught long, long ago. Most of us have worked with internal systems where certs, for whatever reason, don't match the site, and it's surprising many people haven't noted that such doesn't raise any errors on iOS/OSX. Though thinking back....I actually remember encountering exactly that on the iPad once, surprised that it didn't raise a flag. Like probably most I j…

Because it does not work like that. SecureTransport actually verifies the validity of the TLS certificate. If you hand it an invalid certificate in the first place, it will complain.

The issue is one level deeper. When you connect to a server that supports ephemeral key exchange, the parties involved will generate new key pairs on the fly to use for that connection. In order to make sure that the server has the key published in its certificate, the ephemeral public key shown to the client must be signed by the static private key of the certificate and the client MUST verify it. It is the ephemeral key signature that is not validated, not the signature on the certificate itself.

What happens here is that the server gives the client a _valid_ certificate for which it does not own the private key, and in the ephemeral step, it simply generates a key pair without a valid signature. At no point in the handshake the server is asked to verify its ownership of the private key associated to the certificate it is presenting

To summarize, TLS certificate should be valid, but you are never asked to verify you have its private key when the connection used DHE or ECDHE.

Re: Apple's SSL/TLS bug

#236

Post by terminus »

pjene wrote: post #100
brudgers wrote: post #19

Earlier quoted context omitted.

My gut says the probability of a random typo executing without raising an error or exception is rather low. The probability of it doing so in a way that well aligns with the interests of nation states, large corporations, and/or criminal enterprise is even lower. This might explain DROPOUTJEEP particularly considering how much more efficient it is than breaking messages after they are encrypted. http://mobile.eweek.c…

Sure, this aligns with interests, but the bug's existence is predicated on the entire code base being written with substandard style rules and no static analysis or tests , which suggests to me that incompetence got here first.

> entire code base being written with substandard style rules and no static analysis or tests, which suggests to me that incompetence got here first.

That and inadequate, bordering on zero, code review. Even a beginner C programmer looking at this code could see how fishy it looks.

No code review while checking in code to libssl. That takes a lot of incompetence.

Re: Apple's SSL/TLS bug

#237

Post by sneak »

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 :/

Negligence or malice.

My theory is that Apple is spread too thin. Kayak.com reproducibly crashed MobileSafari the day iOS7 shipped, and brand new iPad minis regularly kernel panic and reboot.

It wasn't always like this.

Re: Apple's SSL/TLS bug

#238

Post by sneak »

rdl wrote: post #73
outside1234 wrote: post #68

I think what this really shows is that Apple has no unit tests to cover the security of their products. And that is pretty scary.

I don't think you necessarily need unit tests to catch this; code review would work (even I probably would have caught this if I'd actually read it; "fucking gotos" would have drawn my attention to begin with, and if it was a single line commit, even more so.) The problem is Apple (intentionally) understaffs and overworks, so I doubt they have the spare people to look at most commits.

If only they had the money to devote to quality engineers to ensure good processes surrounding their most critical, security-sensitive code.

You can't really blame them for doing the best they can with limited resources. Startup life is hard.

Re: Apple's SSL/TLS bug

#239

Post by sneak »

lstamour wrote: post #222
hueving wrote: post #187

Earlier quoted context omitted.

How is what I said not true? If the same thing as the Deb prng bug happened in a closed source system, it could sit for a couple of years exposing thousands/millions of systems and then be patched quietly to avoid embarrassment, leaving everyone vulnerable.

FYI -- the source code here is public. Didn't help :D

It helped us realize how easy it would be to test for this, and that Apple isn't.

Re: Apple's SSL/TLS bug

#240

Post by AYBABTME »

voidlogic wrote: post #74
jenandre wrote: post #11

Earlier quoted context omitted.

the gotos actually make sense in this case. unless you'd prefer some insane tree of if/else?

I agree, I was thinking about what this situation would look like in other langs and when I turned to Go, I realized: While Go has goto for tricky situations like this, because it has defer you don't have to use it often, assuming the free calls were needed (and the vars were not going to be GC'd): defer SSLFreeBuffer(&hashCtx) defer SSLFreeBuffer(&signedHashes) if err = SSLHashSHA1.update(&hashCtx, &serverRandom); e…

The `else if` is useless here, since you return anyway. It only adds noise.

I rarely use the one-line `if err := ...; err !=nil ` idiom because its quite a mouthful. However when I do, I try to make sure it's not too much to grasp at once. Here the extra `else` goes against that.

Alright, I know this is just a quick snippet on HN and all, I just thought I'd mention it anyways. Maybe next time you actually write that in code you'll think about my point. ;)

Post reply on HN