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

211–220 of 295 posts

Re: Apple's SSL/TLS bug

#211

Post by knweiss »

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…

(Caveat: I haven't tried this myself!) Here's the analysis and an experimental patch from @i0n1c for the 64bit version of Mavericks' Security.framework (32-bit remains unpatched): http://sektioneins.de/blog/14-02-22-Apple-SSL-BUG.html

Re: Apple's SSL/TLS bug

#215

Post by bunderbunder »

lunixbochs wrote: post #202
Silhouette wrote: post #196

Earlier quoted context omitted.

I understand that there are sequence points at those || divisions, and I appreciate that you've been careful with your layout. Even so, my spider sense is tingling horribly at having not just one assign-and-test in the condition for an if statement but a whole series of them that each reassign to the same variable. If there were a language feature available to do this more elegantly, whether exceptions or something e…

Should the variable reuse matter? Is there a case where the compiler won't short-circuit the || statement on the first failure? If not, `|| (err = check())` is equivalent to separate checks which also also `goto fail` immediately.

>> Is there a case where the compiler won't short-circuit the || statement on the first failure?

Left-to-right, short-circuit evaluation of the logical operators is so deeply rooted in C idiom that a mainstream compiler that doesn't respect it would be practically unusable. But perhaps it wouldn't work in a hobbyist compiler, or a non-standard dialect of C.

Re: Apple's SSL/TLS bug

#216

Post by SideburnsOfDoom »

ams6110 wrote: post #143
Pacabel wrote: 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.

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 does the incorrect code from apple.

I don't understand the need to omit braces; it doesn't make the compiled program any smaller. And denser source code is not always more readable, or we'd prefer "? :" to "if" every time.

Re: Apple's SSL/TLS bug

#217

Post by patricjansson »

blazespin wrote: post #205
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…

It was likely someone subverting the process for reasons of urgency, for good intentions or malice. Simple static analysis or unit tests would have caught this.

Exactly! So strange apple didnt have a testcase for this.

Re: Apple's SSL/TLS bug

#218

Post by valleyer »

huhtenberg wrote: post #171
Varcht wrote: post #88

Earlier quoted context omitted.

Regarding hidden in plain sight, would a semicolon at the end of the if statement throw a warning? Would be a little more hidden.

Yeah, that'd trigger a warning in most compilers - "Empty statement found. Was it an intent?" or something similar.

Not true, try for (;;) ; in gcc / clang

Re: Apple's SSL/TLS bug

#219

Post by MBCook »

javajosh wrote: post #207

Something that concerned me was things like software update daemons connecting with SSL. Can they be compromised? Or is this something that requires connecting to a black-hat server?

If all methods of updating need SSL, and SSL is broken, then there's no real way to securely ship a patch.
Post reply on HN