Digg this story   Add to del.icio.us  
Patching a broken Windows
Robert Lemos, 2006-01-09

Robert Lemos interviews Datarescue's senior software developer Ilfak Guilfanov, the creator of the unofficial patch for the flaw in the Windows Meta File format that saw tens of thousands of downloads prior to the official patch release by Microsoft. Guilfanov explains why he decided to issue a patch for the vulnerability, how he created the patch, and his thoughts on whether third-party patches are generally a good thing.

Could you introduce yourself?

Ilfak Guilfanov: I'm 39 years old. I graduated from Moscow State University in 1987 as a mathematician. At that time information security was not taught as an academic discipline but we received a very good initiation in software development.

I have been developing software since 1987. I started working on IDA Pro in 1990. IDA Pro is probably one of the most widely used tools for hostile binaries analysis and vulnerability research. Over the years, I have frequently been in contact with the best people in that field. While my personal research interests may be a bit esoteric at times (decompilation for vulnerability research for example), I believe I have significant experience with real world problems.

As a software developer, I'm interested in the Windows API, not its internals. What matters for me are the published APIs and how to use them, but not the internal details. I can not claim that I'm an expert in Windows internals but I know enough to understand its operation well enough.

Why did you create the patch to the flaw? Did the WMF vulnerability affect you in particular, or was it more because you saw a need?

Guilfanov: As almost everyone else, I learned about the vulnerability in the news. The description how one can be infected frightened me. This is the main reason why I made the fix - to protect myself and my friends from the malware exploiting the breach in the system protection.

The biggest danger was a simple visit to a web site [that] could infect my computer. To verify it, I downloaded an exploit, neutered it and tried to open it using the standard methods. When I saw that the neutered exploit worked, I knew that the vulnerability could be exploited easily.

Analyses of the flaw in WMF have focused on it being a flaw in design. What's your take?

Guilfanov: A design flaw if judged by today's standards. Should we judge yesterday's design by today's standards? It seems that even open-source developers fell for it in their reimplementations.

Was the patch hard to create?

Guilfanov: It took around 6 hours to develop the fix starting from scratch. I downloaded and studied the WMF format description, found an exploit and understood how it works. The last step was to write the fix and test it on my computers.

I decided to revoke the SETABORTPROC code because I did not see any other practical solution to the problem. There were potential problems with it because the revoked code might be used by some applications. I (did) not see any other solution with an acceptable cost/benefit ratio.

The hardest part was to write a blog entry about it. While I do not write corrections like this routinely (this is the first time [I've done] it), developing software is my primary occupation, so it was not difficult to write the fix itself. Of course, IDA Pro was indispensable in the analysis of the exploit.

There was at least one reported problem with the patch in regards to network printing. Are some of the problems just issues with the types of applications that use WMF and not the fault of the patch?

Guilfanov: I do not know the details of the reported problem. Most likely it happened because the revoked code was used by the printing software.

You went through a number of revisions for the patch. Why?

Guilfanov: The new revisions were not correcting anything. They were, mostly, adding support for different operating systems. The initial revision worked on XP64 and XP SP2. Then support for Windows 2000 was added. The very last revision added the possibility of silent installation.

The initial and the final revisions were giving the same protection level and safety. The only difference was in the added functionality and [the] number of supported systems.

So was it lucky that your patch worked so well? Or did you just have the expertise to create a high-quality patch the first time out?

Guilfanov: It was not pure luck, I precisely knew what I was doing and took all precautions not to break anything. My fix carefully examines the operating system before doing any modifications. Acting otherwise would have been irresponsible.

Were you surprised by the demand for the patch?

Guilfanov: Yes, I'm surprised by it. I did not expect anything like that when I put the fix online.

Unfortunately I do not know how many downloads were made. My hosting solution was apparently not on par with the demand and the provider had to turn the site off due to the excessive load. Currently my site is up in a very reduced form (I added more hosts). The new site contains only links to other sites and I cannot tell how many downloads have been made.

Do you think that perception that Microsoft took longer to create a patch that is very similar to your own is a fair one?

Guilfanov: First of all they did not do exactly the same thing: they had the source code and they could filter the offending SETABORTPROC code earlier than I did without considering it as an error. There are not many different ways of solving the problem, so I'm not surprised that the patches are similar.

I'm (also) sure they created it faster than I did. They certainly did more testing as well. Maybe they had information about esoteric hardware, and then the decision of breaking some functionality is a tough one to take.

Did you ever hear directly from Microsoft?

Guilfanov: No, Microsoft did not contact me. Even if they tried, the mails could be lost because my site went down for a short period.

Do you think community-based code, or open-source code, has strengths in response at times like this?

Guilfanov: I see a big advantage of open source code: it is easily verifiable by the experts. This can lead to earlier adoption of [a] fix and better protection of our computers.

Do you think you would have had as great a response if you didn't show the source code?

Guilfanov: I had to publish the source code with the fix. I did not think about it twice. It was the only way of ensuring its quality. Peer review has fully showed its strengths: the experts at the SANS Institute could verify the fix in the most comfortable way and confirm its effectiveness and correctness.

Do you think that patches that are not created by the software's developer should be installed as a general rule?

Guilfanov: As a general rule, they should not be applied. Can third parties be trusted? Do they have the testing resources of the vendor?

The current situation was, in my perception, a bit different. First there was the danger, then I saw a relatively simple and clean, risk free fix. My intention was not to impose it on anyone, but I found this an interesting topic for my blog (that's why source code was immediately posted) and I felt this was important from a trust point of view. If I could help my knowledgeable audience - who could do their own testing, why not? People are postings exploits all the time, why not post a solution for a change?

Considering the response and your own thoughts, would you ever write a patch again? Under what circumstances?

Guilfanov: While the response is much more favorable than I expected, I prefer not to have any reasons to write a hotfix. Not this time, neither in the future. In the ideal world the vulnerabilities do not exist, second to ideal is to have patches created by the vendor as soon as possible. Given the impossibility of the first option, let's strive for the second one.

Robert Lemos is editor-at-large for SecurityFocus news.
    Digg this story   Add to del.icio.us  
Comments Mode:
Patching a broken Windows 2006-01-10
old interview? 2006-01-10
Anonymous (1 replies)
more in-depth 2006-01-10
Kelly Martin
Patching a broken Windows 2006-01-10
Patching a broken Windows 2006-01-17


Privacy Statement
Copyright 2010, SecurityFocus