Right now, all I see is the PR company that PhoneFactor has hired literally blackening the skies with press releases that are borderline-false. Maybe I should realize how my bread is buttered and get on-point here with the hyperbole, but I just can’t help but feel like we’re taking ourselves too seriously.

It’s great to hear that you’ve done a lot of research into this; it’s reassuring that a pass over the relevant RFCs hasn’t thrown up any major warning flags. I’m more concerned about the non-RFC’ed protocols that use SSL; it’s pretty common to see a layer of SSL added to proprietary protocols in order to hide the underlying flaws. It’ll be interesting to see where this flaw gets realised, for sure.

@samhooker:

That thought had occurred to me. I’d love to hear if anyone has done any testing.

@Moxie:

You’re right that there’s a difference of scale between this auth gap and the other flaws I mention, and that this flaw does not immediately present an exploitable vector without significant work on the part of the attacker. That said, when it does present an exploitable circumstance it would likely be quite severe. That’s why I made the statement about not getting it – this bug is a lot more subtle than just client-certificates or bizarre IIS configurations, and anyone who dismisses it based on the rarity of that vector hasn’t seen the wider implications. I’m not saying it’s huge but people certainly should not dismiss it out of hand – there’s some significant potential for harm here.

You’re also right that anyone who thinks the sky is falling also doesn’t get it – that’s simply not the case, but people do need to take it seriously until they’ve quantified the effect that it will have in *their* environments. The sky isn’t falling but it’s certainly cracked; I’m expecting to see some creative applications of this flaw in the coming weeks.

Chris

So I agree with you that this is not very useful in the context of HTTP, but all of the examples that were provided in the disclosure were portrayed in the context of HTTP, and they all seem to suggest that the sky is falling. Personally, I don’t find that kind of disclosure very helpful. So yes, if anywhere, it’s likely that this might actually be more useful in the context of other protocols, but my feeling is that the reason most of the discussion on this has been limited to HTTP is because that’s where particular configuration issues actually make this “exploitable.” How many other protocols do you know of that accept a request, then decide to ask for authentication through their transport layer, then act on the request that they received before the authentication was complete?

They might exist, but they’re edge cases. That’s what this vulnerability is, a very nice edge case. Clever, yes, but not the same as a whole-scale network-wide attack like DNS cache poisoning.

Finally, I’ll say that it’s a little difficult to respond to this post because of the way that you’ve employed tautology here. By saying that “anyone who doesn’t think this is huge doesn’t get it,” you’ve automatically cut off any discussion, because to question your assessment immediately pegs you as someone who “doesn’t get it.”

So the best I can do is say: “Anyone who thinks this is huge REALLY doesn’t get it.” There. =)

Thanks for taking the time to allow me to brief you on this today. You were clearly one of the few folks that instantly got it and that, in of itself was, really quite refreshing.

Many of the folks I had to explain this too quickly got lost in the mechanics of the bug or went off on wild tangents of possible but unlikely scenarios.

Having said that.

I think that most if not all of the protocols currently protected via STARTTLS extensions are likely to remain safe. A careful reading of the hundreds (literally) of RFC’s on this topic shows some consistency of thought around channel binding and state clearance that should, (should mind you) protect us.

This is really quite a win! Your concerns about “(what could you do with IMAP/S or POP3/S?)]…” are probably not as bad as they could be. I’m not calling them baseless, they deserve examination, however only experimentation will prove that for sure. Right now, as far as Leviathan’s research shows, there are no credibility attacks against the two protocols you mentioned. Again, however, only time will tell.

“RFC2595 – Using TLS with IMAP, POP3 and ACAP

” A TLS negotiation begins immediately after the CRLF at the end of
the tagged OK response from the server. Once a client issues a
STARTTLS command, it MUST NOT issue further commands until a
server response is seen and the TLS negotiation is complete.

The STARTTLS command is only valid in non-authenticated state.
The server remains in non-authenticated state, even if client
credentials are supplied during the TLS negotiation. The SASL
[SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
client credentials are successfully exchanged, but servers
supporting the STARTTLS command are not required to support the
EXTERNAL mechanism.

Once TLS has been started, the client MUST discard cached
information about server capabilities and SHOULD re-issue the
CAPABILITY command. This is necessary to protect against
man-in-the-middle attacks which alter the capabilities list prior
to STARTTLS. The server MAY advertise different capabilities
after STARTTLS.

Read more: http://www.faqs.org/rfcs/rfc2595.html#ixzz0Vyq56WNY
“

Thanks for the info, and good job on finding a very subtle bug. I’ve been comparing it to the bug that forced SSLv2 to become SSLv3, I’m looking forward to reading the RFC that fixes this.

You’re right that XSRF bugs are very serious, but they’re also very easy to mitigate. This bug doesn’t directly reveal credentials (phew) but what worries me is how this is going to be widened once more eyeballs see it, and how many deployments think they’re extra-secure because they’ve enabled protections like client certificates and per-directory ciphering requirements. It’s one of those open-ended bugs that worry me in that I’ll never believe we’ve seen the last of it.

You’ll certainly have my peer review when the draft is posted; do you know when any of the patches are planned?

Cheers!

I remember staying up too late watching a video of your Shmoocon RFID presentation. That is awesome stuff!

I think your comparison with XSRF is very apt, as there are a lot of similarities. Remember however, that XSRF bugs are pretty darn serious bugs and a lot of work has been done to close those holes down (same origin policy and whatnot). This TLS problem in a sense un-does most of that. It can bypass same-origin because the attacker can change the client’s GET to a POST.

Re: “The only ways to even trigger it require any of”, those are the cases we wrote up for the paper, and we and the industry continue to learn more. For example, the first version of the paper speculated on the possibility of a client (i.e. MITM)-initiated renegotiation being accepted by the server. It seems that there are many HTTPS servers that accept it, and many which do not.

Client-cert auth may seem to be an obscure deployment scenario, but it seems to be used in places where security is most important. E.g. smart card systems. If MitM can take your smart card credentials to any server on the net that will accept them and use them to authorize his arbitrary request, that’s a big problem.

Re: “a hurried fix that isn’t-quite-thought-through by a lot of folks (and will have lots of implementation problems even if the protocol itself is secure)” You may be right on that, but I hope not, and probably only time will tell. I hope to get the word out early though that I think we did get the right people in a room together and I think we did come up with the right fix, and I expect the Internet Draft doc to hit the public IETF process tomorrow. Some evidence that it probably doesn’t totally suck (as far as protocol fixes go anyway) is that several people came up with the same idea more or less independently after getting a real understanding of the issue. Since then, it’s had a few weeks of scrutiny and I’m not aware of any shortcomings being pointed out.

Of course, all patches could always use more testing, and that goes 10x for protocol changes. At the end of the day we weren’t able to give the vendors as much time as any of us had wanted, but we (as security researchers) think we gave the industry the best possible chance to succeed.

So I’d like to see the proposed fix get a fair shake, since I think it represents the best way to get the whole net patched quickly.

- Marsh