Live data from Hacker News

Apple's SSL/TLS bug

imperialviolet.org

161–170 of 295 posts

Re: Apple's SSL/TLS bug

#161
From looking at the code it seems like there should be a way to change the instructions to "fix" the issue, but in a round-about way. This code:

    if (sslVersionIsLikeTls12(ctx)) {
        /* Parse the algorithm field added in TLS1.2 */
        if((charPtr + 2) > endCp) {
            sslErrorLog("signedServerKeyExchange: msg len error 499\n");
            return errSSLProtocol;
        }
        sigAlg.hash = *charPtr++;
        sigAlg.signature = *charPtr++;
    }
is only executed in the TLS 1.2 case, but the sigAlg structure is always on the stack. So if this code remains "skipped" in the non-TLS 1.2 case, then later on:

    if (sslVersionIsLikeTls12(ctx))
    {
        err = SSLVerifySignedServerKeyExchangeTls12(ctx, sigAlg, signedParams,
                                                    signature, signatureLen);
    } else {
        err = SSLVerifySignedServerKeyExchange(ctx, isRsa, signedParams,
                                               signature, signatureLen);
    }
the broken "else" case can be replaced with instructions to poke the proper values into sigAlg and then relative jmp to the code offset where the inlined SSLVerifySignedServerKeyExchangeTls12 begins (0x86cb9), as that version of the function does not have the bug.

I checked inside the SSLVerifySignedServerKeyExchange disassembly and the compiler expectedly omitted the remainder of the function, so it isn't as simple as sticking a few nops in.

Re: Apple's SSL/TLS bug

#162
This seems to be the current thread on the topic, so I'll mention here in case anyone cares that iOS 5.1.1 does not contain the vulnerability, according to gotofail.com's test for it.

Re: Apple's SSL/TLS bug

#163
post #59

I just made this - it'll tell you if you're vulnerable. https://gotofail.com/ Not very well tested, please let me know if it works for you. If you're on OS X Mavericks or on iOS 7 and haven't patched you should get big scary red text. Edit: posted here https://news.ycombinator.com/item?id=7282164

Your checker doesn't work well with curl, btw -- you end up seeing both the not vulnerable AND the vulnerable (alt text) messages.

curl https://gotofail.com:1266/

Client's that aren't vulnerable should flip out when trying to load that.

Re: Apple's SSL/TLS bug

#164
post #146
post #133

Earlier quoted context omitted.

> I think anyone relying on the security of OS X is going to have to seriously rethink their OS choice after this. 10.7.3 logging FileFault (that was a typo, but I think I'll keep it) passwords in plain text might have been a subtle hint in that direction.

They've honestly done a pretty great job on iOS security (at least since iPad 2/iPhone 3GS). OSX, not as much.

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

Re: Apple's SSL/TLS bug

#165

Earlier quoted context omitted.

This also impacts iOS 6; there's an update available.

Is it possible to get the iOS 6 update if your device supports iOS 7? iTunes only offers the 7.0.6 update.

Yes, I did it this morning. Look for the update from your phone, so it's a smaller download anyway. It takes more room than they ask for, maybe 750 meg. I just temporarily deleted some podcasts to make room.

Re: Apple's SSL/TLS bug

#166
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...

The code in question is open source.

Re: Apple's SSL/TLS bug

#167
post #117
post #96

Earlier quoted context omitted.

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 Tell that to the people who generated keys on Debian. Programmers are simply not good enough at writing secure code. Full stop. If you say anything else, you're just flaunting your own unreliability as a source of security advice.

At least that was public and fixed. I think the point is that keys could be completely deterministic on closed source systems and there is no way to know. It's very easy to have deterministic "random" sources that pass statistical tests for randomness.

Re: Apple's SSL/TLS bug

#168
post #96

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.

ChromeOS is by far the safest thing out of the box, IMO.

Re: Apple's SSL/TLS bug

#169

Earlier quoted context omitted.

Well, as the article says: A test case could have caught this, but it's difficult because it's so deep into the handshake. One needs to write a completely separate TLS stack, with lots of options for sending invalid handshakes.

So you need a mock peer, whoop-de-fuckin-do. Seems like one of these security weenies could sit down and write a test for once. By the way the test coverage in OpenSSL is piss-poor as well.

The kind of abusive comments you've been leaving on this thread are not really welcome on HN. Please stop.

Re: Apple's SSL/TLS bug

#170
post #133

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.

> I think anyone relying on the security of OS X is going to have to seriously rethink their OS choice after this. 10.7.3 logging FileFault (that was a typo, but I think I'll keep it) passwords in plain text might have been a subtle hint in that direction.

Is there a radar number for that?
Post reply on HN