Date: Sun, 24 Jan 2010 01:46:30 +0100
From: Dan Kaminsky <dan@...para.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 Sun, Jan 24, 2010 at 1:05 AM, Pavel Kankovsky
<peak@...o.troja.mff.cuni.cz> wrote:
> On Thu, 21 Jan 2010, Dan Kaminsky wrote:
>
>> But imagine an oldschool application drenched in strcpy, where you've
>> lost context of the length of that buffer five functions ago.
>
> When you discover you are riding a dead horse, the best strategy is to
> dismount. When you discover the program is designed too badly to be
> maintained, the best strategy is to rewrite it.

No question.  And how long do you think that takes?

Remember when Netscape decided to throw away the Navigator 4.5
codebase, in favor of Mozilla/Seamonkey?  Remember how they had to do
that *again* with Mozilla/Gecko?

>> Or imagine the modern browser bug, where you're going up against an
>> attacker who *by design* has a Turing complete capability to manipulate
>> your object tree, complete with control over time.
>
> Such an attacker must be assumed to possess hyperturing computing power
> because an exploit can communicate with an oracle.

"Hyperturing computing power" Not really sure what that means, but
yes, oracles are pretty damn useful.  As Dino just pointed me to @
BHDC:

==
Dionysus Blazakis
Interpreter Exploitation: Pointer Inference and JIT Spraying

As remote exploits have dwindled and perimeter defenses have become
the standard, remote client-side attacks are the next best choice for
an attacker. Modern Windows operating systems have quelled the
explosion of client-side vulnerabilities using mitigation techniques
such as data execution prevention (DEP) and address space layout
randomization (ASLR). This work will illustrate two novel techniques
to bypass DEP and ASLR mitigations. These techniques leverage the
attack surface exposed by the advanced script interpreters or virtual
machines commonly accessible within the browser. The first technique,
pointer inference, is used to find the memory address of a string of
shellcode within the ActionScript interpreter despite ASLR. The second
technique, JIT spraying, is used to write shellcode to executable
memory by leveraging predictable behaviors of the ActionScript JIT
compiler bypassing DEP. Future research directions and countermeasures
for interpreter implementers are discussed.
===

> But I do not think this case is much different from the previous one:
> most, if not all, of those bugs are elementary integrity violations (not
> prevented because the boundary between trusted and untrusted data is not
> clear enough) and race conditions (multithreading with locks is an
> idea on the same level as strcpy).

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*.  I
mean, use-after-free becomes ludicrously easier when you can grab a
handle and cause a free.

>> Or, worst of all, take a design flaw like Marsh Ray's TLS
>> renegotiation bug.
>
> One needs to pay utmost attention to the design and its correctness.
> This has been known for decades, hasn't it?

Sure.  But we're not talking about what should be done before you
write.  We're talking about what happens when you screw up.

> (An interesting finding regarding the renegotiation issue: People
> analyzing the protocol in the past had spent a lot of energy on its
> individual parts, esp. the handshake, and very little work had been done
> on the protocol as a whole.)

Eh.  This was a subtle one, based more on not realizing the semantics
from one layer happened to match the semantics of another, and also
not recognizing possible faults in the multi-session case.  It's a
pretty beautiful bug.

>> c) The system needs to work entirely the same after.
>
> Not entirely. You want to get rid of the vulnerability.

I wouldn't consider being vulnerable "working" :)  But point taken.
The system needs to meet its functional requirements entirely the same
after.  Yes, there are bugs that make this *enormously* difficult,
where you need to force a major migration to make customers safe.
Adobe pushed something like this through for the DNS Rebinding socket
fixes, phasing the fix across multiple releases at pretty enormous
expense.

> --
> Pavel Kankovsky aka Peak                          / Jeremiah 9:21        \
> "For death is come up into our MS Windows(tm)..." \ 21st century edition /
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

_______________________________________________
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