By Secunia Research
For the past week, there has been quite a stir about a new class of vulnerabilities or rather a new, remote vector for exploiting an old class of vulnerabilities: Insecure library loading.
This vulnerability class has been known for many years, but hasn't been taken that seriously in the past as it was believed to require an attacker to plant a malicious file in a directory within the search path on a user's system. However, the discovery of the remote vector just made this serious.
The vulnerability is not in the Windows OS itself, but is caused by bad (insecure) programming practises in applications when loading libraries combined with how the library search order works in Windows. Ideally, when loading a library (or running an executable), a fully qualified path should be passed to the APIs used (e.g. LoadLibrary()). In case a programmer refrains from doing so and only supplies the library name, Windows searches for the file in a number of directories in a particular order.
These directories may include the current working directory, which leads to the core of the problem related to the new, remote attack vector as Windows eventually searches for the file on e.g. a remote SMB or WebDAV share if that happens to be the current directory. This is the case if a user e.g. is tricked into opening a file located on a remote share. By placing a malicious library, which a vulnerable application searches for, on the share it is loaded into the application and code is executed with the privileges of the user running it.
As the core problem is not in Windows, but rather caused by applications loading libraries insecurely (i.e. not supplying a fully qualified path or not initially calling SetDllDirectory() with a blank path), Secunia will not be issuing a general advisory for Windows. Instead, (likely, quite a lot of) advisories will be issued as affected applications are identified.
Currently, we are seeing reports from various researchers having identified everywhere between 40 to 200 vulnerable applications, but the actual number may be a lot higher as many programmers do not follow Microsoft's recommendation for secure library loading (this includes Microsoft's own programmers as, according to HD Moore, at least four affected Microsoft applications have been identified).
ACROS Security has already reported this vulnerability for Apple iTunes and it was fixed in version 9.1. HD Moore has also identified a large number of affected applications, but has not disclosed the list; instead, he has made an audit kit available to determine affected applications.
To protect against attacks, Microsoft has released a tool that helps system administrators and users to configure the search path order either on a per application basis or system-wide.
Companies can also mitigate remote exploitation by ensuring that SMB traffic is disabled on perimeter firewalls (TCP ports 139 and 445) and disable the WebClient service on all systems.
As this vulnerability is related to a general design problem, Windows security mechanisms like ASLR etc. provide no protection. It's simply a matter of opening a file located on e.g. a remote share using a vulnerable application and you're owned.