full-disclosure-uk January 2010 archive
Main Archive Page > Month Archives  > full-disclosure-uk archives
full-disclosure-uk: Re: [Full-disclosure] Two MSIE 6.0/7.0 NULL

Re: [Full-disclosure] Two MSIE 6.0/7.0 NULL pointer crashes

From: Dan Kaminsky <dan_at_nospam>
Date: Sun Jan 24 2010 - 00:46:30 GMT
To: Pavel Kankovsky <peak@argo.troja.mff.cuni.cz>

On Sun, Jan 24, 2010 at 1:05 AM, Pavel Kankovsky <peak@argo.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/