A day after Microsoft released information on the remotely exploitable DLL-hijacking vulnerability that affects dozens of Windows applications, researchers are starting to discover exactly which pieces of software are vulnerable. The list so far includes PowerPoint, Wireshark and some applications that are included by default with Windows Vista, and possibly Windows 7.
The class of vulnerabilities that is being described as DLL hijacking or DLL preloading enables an attacker to hide a malicious DLL in a directory on a network or WebDAV share and convincing a user to open a file that will silently load the DLL. The vulnerability itself has been known for at least 10 years, but Microsoft officials had considered it a low-impact flaw because it was thought that an attacker would only be able to exploit it locally. However, researchers such as Aviv Raff and others have shown in recent years that it could be exploited remotely under some circumstances.
And late last week HD Moore of the Metasploit Project and Rapid7 said that he’d found other reliable ways to remotely exploit the flaw and had identified 40 or so Windows applications that are vulnerable. Moore detailed his findings in a blog post Tuesday. Now, information is beginning to filter out about exactly which applications are vulnerable, along with exploit code for some of them.
Early Tuesday, exploit code for the DLL hijacking flaw was posted for both Microsoft PowerPoint and Wireshark, a network protocol analyzer. Raff also said in a message on Twitter Tuesday that some software included with Windows Vista, and possibly Windows 7, is vulnerable to the attack. Microsoft has not released a list of which applications are known to be vulnerable to the DLL-hijacking flaw, nor has Moore.
While Microsoft is in the process of continuing its investigation into the class of flaws, the company has published a description of the problem, along with a tool that can help mitigate the DLL-hijacking vulnerability. Moore also has released an audit tool that can identify vulnerable applications on a local system.
[See: HD Moore on the Windows DLL Vulnerability podcast]
“When an application loads a DLL without specifying a fully qualified
path name, Windows will attempt to locate the DLL by searching a defined
set of directories. We have discussed the DLL search path on this blog and it has also been explained well on David LeBlanc’s blog.
For the sake of this issue, its sufficient to say that if an attacker
can cause an application to LoadLibrary() while the application’s
current directory is set to an attacker-controlled directory, the
application will run the attacker’s code. Development best practices state
that applications should call SetDllDirectory with a blank path before
calling LoadLibrary(“foo.dll”) to ensure that foo.dll is not loaded from
the current directory. We are investigating whether any of our own
applications are affected by this class of vulnerability so that we can
take appropriate action to protect customers,” Microsoft’s Jonathan Ness said in a blog post.
The first public mention of this class of vulnerabilities appears to have been an advisory posted to BugTraq by researcher Georgi Guninski in 2000, in which Guninski details the problem and lists dozens of versions of Windows that are susceptible to the attack. Raff also discussed the DLL problem publicly back in 2006.
