The Windows DLL library loading vulnerability is gaining hacker attention. Although no one can accurately predict the next "big one," malicious cyber fiends are likely to use this exploit method against innocent computer users.
The threat is unlikely to go as big as, say, Code Red or the SQL Slammer worm because fully remote worm attacks are always more likely to spread than something that requires human interaction. Still, it has plenty of long-term potential. I -- and every other security expert -- recommend taking a few basic precautions to help diminish risk within your companies and at home.
For those of you not already intimately familiar with the details of the vulnerability, several months ago a Slovenian computer security company, ACROS Security, (re)discovered a code problem within many popular programs, one that is exacerbated by the way Windows handles executing code. ACROS is to be commended for reporting its finding to Microsoft on March 24 and working with Microsoft (my employer) to try and come up with a best solution. By the way, there isn't a single, best fix.
The core issue is in how Windows looks for external binary files when a calling program needs them. Most Windows programs call other supporting binary files (often in the form of DLLs, Dynamic Linking Libraries) after they initially execute.
They use this process for a variety of reasons. Often it is to save programming time and storage space by simply calling snippets of code written by others -- typically Microsoft or a third party. Calling external code allows common functionality, such as screen draws or window handling, to be a part of the larger program with minimal effort. It can also allow easier upgrades because the separate components can be upgraded, only when needed, instead of having to recode a larger binary every time a fix is implemented.
If the calling program doesn't explicitly define the path to the externally called binary, Windows and any modern operating system will begin to look for the "missing" file in a particular predefined order. Windows starts by looking in the application's directory, followed by the current working directory; if the file is not found, Windows will then use the system directory, followed by a few other predefined methods. (See more information on the search options.)