IIS 5.1 Patched (Dangling Pointer)

Yesterday was Microsoft's patch Tuesday - a very exciting day for all of us. One of the vulnerabilities that was fixed is the IIS 5.1 dangling pointer vulnerability that Adi Sharabani and I revealed.

This vulnerability was fixed a long time after its original public disclosure date (it was known since December 2005). At first, it was considered a DoS vulnerability and therefore Microsoft decided that it wasn't important enough to fix in a security update and deferred it to a service pack instead.

While the importance of a DoS issue is debatable (as a previous reply to our blog suggests), it is not the subject of this post. But I will just say that I personally think that DoS is a very severe issue.

Anyway, as our research proved, this Dangling Pointer bug could be exploited for arbitrary remote code execution and therefore, it was quickly and efficiently patched by Microsoft (kudos to Microsoft's Response Team who was very responsive and co-operative during the disclosure process)

An interesting thing to note about yesterday is the old debate about managed code (like .NET and Java) vs. unmanaged code (like C and C++).

This debate has many aspects and viewpoints to it and can be discussed for long hours.

Before I dive into the point I'm trying to make, I want to say that in my opinion, security problems lie on the shoulders of developers and nobody else is to blame. Secure code provides good security. Obviously, secure frameworks can help, but it is never the complete solution.

The first point yesterday's patch Tuesday made in this debate is that managed code provides better security for dangling pointer problems. This means that if the IIS web server was developed using a managed code framework, it was not vulnerable to this kind of a remote code execution exploit. This doesn't mean that remote execution vulnerabilities cease to exist when using managed code, but rather that their impact usually becomes a DoS instead.

On the other hand, yesterday's patch included a fix for another two .NET vulnerabilities. This is amusing because the impact of these two  vulnerabilities was that even if the best developer in the world developed the most secure .NET-based software, it was still vulnerable to a remote execution exploit because of the framework it used. This is a big minus for managed code.

We will reveal more specific details about our research into the exploitation of dangling pointer bugs for remote code execution and about this specific vulnerability at the BlackHat conference -

http://www.blackhat.com/html/bh-usa-07/bh-usa-07-speakers.html#Afek

Here's Microsoft's official  advisory -

 http://www.microsoft.com/technet/security/Bulletin/MS07-041.mspx

Comments

[forever.b0rked]

I wish I was going to make it to blackhat this year, this presentation looks like its going to be very promising. I look forward to at least being able to drool over the slides ;)

I actually discovered a flaw of this nature in libkhtml a few months ago, but the nature of the bug didn't make sense until I started hearing about the research you guys are putting together.

Thanks for your research and I look forward to reading it.