Summary
Microsoft released a security advisory on Aug 23 that discusses a remote attack vector that allows an attacker to remotely take control of user's machine. The security advisory was in response to a report released by a security researcher the previous week that described how more than 40 Windows applications could be compromised due to the way Windows applications load DLLs. Palo Alto Network's Next-Generation Firewalls can help thwart/mitigate such attacks by using App-ID and Content-ID technology (details below).
What customers should do
The attack is best controlled by introducing firewall security policies that block SMB (Server Message Block) or WebDAV (Web-based Distributed Authoring and Versioning) traffic from traversing the trust to untrust zones (see scenarios below). A recent US CERT advisory advised similarly. Security best practices indicate that most enterprises should have such policies in place on the perimeter firewall unless there is a need to allow Internet-based SMB or WebDAV traffic.
Scenario 1: Internet-based SMB and WebDAV is not allowed/needed
Fix: Introduce a firewall rule to block traffic for following applications (webdav, msrpc, ms-ds-smb, netbios-ss) from trust to untrust zone.
Scenario 2: Internet-based SMB is not allowed/not-needed but WebDAV is allowed/needed
Fix: Introduce a firewall rule to block SMB traffic (applications: msrpc, ms-ds-smb, netbios-ss) from trust to untrust. Introduce another firewall rule to allow WebDAV traffic (application: webdav) from trust to untrust and add a file blocking profile that blocks DLL file-type.
An additional layer of protection can be implemented by implementing a threat prevention (Antivirus) policy to detect and block any known malicious DLL files. Customers can choose to apply an antivirus profile on firewall rules (default action for any virus detected over HTTP or SMB is block so the default antivirus settings would work).
Customers are also recommended to check Mitigating Factors and Workarounds posted in Microsoft's Security Advisory.
Attack Details
The DLL attack is in fact a classic attack and is OS-agnostic -- if an application needs to find any library (DLL in case of Windows), it looks in the each of the directory (in order) mentioned in the PATH shell variable. If an attacker places the malicious library in a directory that appears in the PATH variable "before" the directory containing the genuine library, then the attacker can have his/her malicious code executed by the application. For such an attack to happen, two things are required:
1. Application loading the library uses relative library name instead of full path (this will cause the library to be searched in directories mentioned in PATH variable)
2. The malicious library that needs to be installed is present on the local machine.
The new research finding relaxed the second requirement. This causes the threat surface to increase dramatically in the sense that the attacker can now create a data file that the vulnerable application can open, create a malicious library that the vulnerable application would invoke and host both files on an Internet-based network share that the user can access. If somehow the user can be lured into accessing the specially crafted data file then the vulnerable application would execute the malicious library that will cause the attacker's code to run the local machine.
It is to be noted that the threat applies to only those windows applications that load DLLs by using the DLL name only and not using the absolute path name of the DLL. If IT personnel are interested in finding what vulnerable applications exist on a given machine, they can use a public program available from metasploit (For obvious reasons, Palo Alto Networks does not guarantee the correctness of this program).
http://blog.metasploit.com/2010/08/better-faster-stronger.html
This attack is also described in a Microsoft blog and US CERT Technical Alert TA10-238A.