Software Testing Blog

Pardon my American “gun-loving” nature while I start this blog post with an analogy about guns. Let’s say that I’m interested in learning how to shoot a gun, so I go visit my local shooting range for instruction. The people who run the shooting range (which is fully licensed and very reputable) give me extensive safety training before finally issuing me a gun with some ammunition. While standing in front of the target, I carefully load the gun, point the barrel at my foot, and pull the trigger.

So whose fault is it that I just shot myself in the foot? Is it the shooting range’s for not issuing me special bullet proof boots or for not training me even more thoroughly about the dangers of shooting my extremities? Or is it mine, for shooting myself in the foot?

A recent Windows “bug” has put Microsoft in the position of the shooting range. I put “bug” in quotes because it’s hardly the shooting range’s fault that I shot myself in the foot, but it’s still their problem in the end. Same with Microsoft who must now deal with an annoying flaw in their DLL loading behavior that isn’t their fault but has become their problem. Ars Technica explains the problem very well, but here’s a quick summary of the issue:

For the uninitiated, Windows applications may have their functionality spread across dozens or even hundreds of files called DLLs. When you tell your application to perform a task, the instructions for performing that task might be contained in a DLL file somewhere with the application or even as part of Windows itself.

Now there are two places an application can look for a DLL file. The first place is simple – wherever the developer explicitly says to look. That’s the way Microsoft says to do things (and has for 12 years), and it’s the safest approach to use. But Windows supports another approach which is to look for the DLL file wherever the application happens to be looking for other files. In other words, if your application is an MP3 player, and it’s loading an MP3 file from your media directory, then it can also look for necessary DLL files in that same directory.

This is legacy Windows behavior – a lot of old applications expect Windows to work this way. But it’s also incredibly dangerous. All I need to do to break your application is to put a hacked DLL file in the same location as another file I want to open. Microsoft realized this was a problem a long time ago, so way back when they released Windows XP SP1, they made it possible for a developer to turn off this behavior entirely within their software. So it was a huge surprise when security researchers recently announced that 40 different applications (including iTunes for Windows) were still vulnerable to DLL loading bugs because the app developers forgot to do disable the legacy DLL loading behavior.

This puts Microsoft in a bind. On one hand, they have to support a legacy behavior for older applications that a few people still use. On the other hand, developers are still writing buggy code that doesn’t take advantage of the security features that Microsoft has offered for years. This issue is plainly the fault of the developers, but in the end it has become Microsoft’s problem.

So what’s the solution? Microsoft has released a hotfix that lets you turn off the DLL loading behavior entirely, but you should be careful using this as it may break some poorly written applications. Then again, anything that doesn’t work after you install this is broken anyway, right?

In the long term, what should Microsoft do? They’ve long maintained a strategy of maximizing backwards compatibility, but sometimes it backfires with problems like this. Should developers be responsible for writing their code securely, just like they should avoid other bugs such as buffer overflows and race conditions? Or should Microsoft break support for some older applications to better safeguard new ones? Of course, breaking that support may require you to upgrade your software, or even buy entirely new software if the original developer is no longer in business.

What do you think?