Date: Sun, 28 Feb 2010 20:28:50 -0600
From: Marsh Ray <marsh@...endedsubset.com>
To: Pavel Kankovsky <peak@...o.troja.mff.cuni.cz>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Two MSIE 6.0/7.0 NULL pointer crashes

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/

Powered by blists - more mailing lists