Re: Dangling pointers exploitation

[Alexander Sotirov <asotirov () determina com>]

The articles defines dangling pointers as pointers that refer to an invalid
object, often because the referenced object was deleted without changing the
value of the pointer. This type of bugs is also known as "use-after-free"

I think these bugs belong to a class best described as "uninitialized data
vulnerabilities". In practice there is little difference between data that was
never initialized and data that was freed and then reused. The exploitation
methods are similar in both cases.

Halvar has done some work on exploiting uninitialized data on the stack [1]. My
Heap Feng Shui presentation [2] describes heap manipulation techniques for
exploiting uninitialized data on the heap. The sample exploit code released my
presentation shows how to exploit an ActiveX control that uses random data as an
object pointer. I am sure that there are other exploits that use similar techniques.

The article mentions that the Watchfire technique was originally developed for
the IIS 5.1 bug (CVE-2005-4360), which was publicly reported as a DoS in 2005
and remained unpatched until MS07-041. I did some analysis of it back when it
was disclosed.

This bug is triggered by sending an HTTP request for /_vti_bin/.dll/:~0 exactly
four times. The problem is caused by an incorrectly decremented reference
counter for a CWamInfo object. If the request URL is malformed, the counter is
decremented by one, but the reference to the object is not invalidated.

The counter starts at 3. After three invalid request the counter reaches 0 and
the CWamInfo object is freed. Since the number of real references to the object
is still 3, the next request will dereference the pointer to the old data.

To exploit this vulnerability we need to do the following:

1. Cause a few allocations for 560 bytes to empty the lookaside.
2. Send two invalid requests. This will decrement the CWamInfo refcounter to 1
3. Send a request that allocates and frees 560 bytes. We need to put a pointer
to our shellcode at offset 0xC in this block. Freeing the block will put it on
the lookaside.
4. Send the third invalid request. This will free the 560 byte CWamInfo object
and put it on the lookaside. The vtable pointer of the object will be
overwritten with the address of the block freed in step 3.
5. Send a fourth invalid request. IIS will call the virtual function at offset
0xC in the vtable of the freed CWamInfo object. Since we control the pointer
there, we get shellcode execution.

Figuring out how to do steps 1 and 3 reliably is the main difficulty in
exploiting this vulnerability.

I don't know of a good generic way to exploit these types of bugs. There are
common patterns in uninitialized data exploits, but the way you do heap
allocations is different for each application. If Watchfire has discovered a
better exploitation method for these bugs, it would be great and I'll be eager
to hear about it.

If their technique is something similar to the one above, then it's nothing new.

The fear mongering in the article is great though. We definitely need more of
that in the security industry: "Afek and Sharabani's discovery is a major step
forward and a scary one at that, given the ubiquity of this kind of coding error."


Take care,
Alex


[1] http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Flake.pdf
[2] http://www.determina.com/security.research/presentations/bh-eu07/
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave