Full Disclosure mailing list archives
Re: Two MSIE 6.0/7.0 NULL pointer crashes
From: Marsh Ray <marsh () extendedsubset com>
Date: Sun, 28 Feb 2010 20:28:50 -0600
On 2/28/2010 2:22 PM, Pavel Kankovsky wrote:
On Sun, 24 Jan 2010, Dan Kaminsky wrote:Nah, it's actually a lot worse. You have to start thinking in terms of state explosion -- having turing complete access to even some of the state of a remote system creates all sorts of new states that, even if *reachable* otherwise, would never be *predictably reachable*.
Perhaps it would be more proper to say that those states really did exist beforehand but were unrecognized? We could refer to them as "latent states"! Even the simplest static analysis should uncover the explosion caused by scanf("%s"). The problem is that there are so many other ways that a combinatorial explosion of states can exceed the capacity of static analysis it can't tell the valid ones from the exploitable ones. If you make a static analysis product, I suspect your customers will want it to somehow run in bounded time and memory.
I do not want to downplay the ingenuity of Marsh Ray and Steve Dispensa (and Martin Rex) but...
Oh man. We should downplay those guys whenever we get the chance. :-) Pavel and Dan, truly it is you who instruct us by your example! Did you guys catch our talk at Shmoo 2010 yet? We've got to get that online somehow.
Any attempt to formalize integrity properties SSL/TLS is supposed to guarantee would inevitably lead to something along the lines of "all data sent/received by a server within the context of a certain session must have been received/sent by the same client".
You know, I would have thought the same thing before I tried explaining it to various people in the industry. The weird thing is that the speed (and likelihood) of a person accepting the problem in TLS was (with notable exceptions) inversely proportional to the amount they knew about TLS and crypto in general. For example, a credentialed cryptographer we explained it to maintained that there was no problem with the crypto, just how we were using it. Many felt the bug was in https for retroactively authenticating in the first place. Check out the first comment at http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html And Ben Laurie's post at http://www.links.org/?p=789 The killer point for me in the debate is the part of the spec that says that app data can be interleaved in the handshake messages of the renegotiation. Without the assumption of continuity-of-identity, that creates a whole range of ambiguous states which are not properly defined. Thus the TLS spec is, in fact, internally inconsistent. But this is reeely subtle unless you've read the spec many times (even most implementers seem to ignore it). The world was previously divided into two camps: A. (The great majority) People who didn't realize SSLv3+TLS could renegotiate at all. It hadn't occurred to these people to question if it offered the same continuity-of-identity that we had with SSLv2. B. People who were intimately familiar with TLS and knew it could theoretically reneogtiate but hadn't looked at that minor footnote of the spec hard enough (after all, it was thought to be rarely used and already encrypted).
And I find it rather unplausible the problem with renegotiations would avoid detection if those properties were checked thoroughly.
But the need for stating explicitly and double-checking such an obvious requirement might not have even come up. After all, it had not been explicitly checked for in various other security reviews over the years. Certainly some of those reviewers had been familiar with http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.8510 Man-in-the-Middle in Tunnelled Authentication Protocols (2002) N. Asokan, Valtteri Niemi, Kaisa Nyberg where a similar attack was described. What would have done it (I think) is if they had looked at how the APIs were defined and used by applications. Then they would have seen that the APIs remained the same from SSLv2 even as SSLv3 added a whole nother layer of abstraction through this renegotiation facility. - Marsh _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: Two MSIE 6.0/7.0 NULL pointer crashes Pavel Kankovsky (Feb 28)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes Christian Sciberras (Feb 28)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes Marsh Ray (Feb 28)