Replies

This looks like a dilemma for Microsoft: fix the problem and they break a lot of programs.

visiting malicious Web sites or opening malformed documents because of the way the software loads code libraries

...which is why we strictly control surfing and file downloads on our networks. Its all you can do until MS has a fix for it.

And better the exploit code is in metasploit than laying low in a black hat forum somewhere. This way at least you can test your systems for this vulnerability.

Gives whole new meaning to the term: DLL Hell

Run Deep Freeze. Doesn't matter what's loaded, just reboot and you're back to normal.

We used it in a middle school computer lab of about 40 Windows XP Pro PCs. The only calls we got after installing Deep Freeze were for hardware issues, not a single software or OS issue.

It also eliminated the need for antivirus, spyware, and malware programs.

http://www.faronics.com/en/Products/DeepFreeze/DeepFreezeCorporate.aspx

So if I understand right, if the hacker can get the victim to download and save a copy of a file, then the computer can be compromised because that file might be loaded by another application already on the machine.

And this is different from a trojan - how?

Sorry, but the last line of defense is ALWAYS the user, and if you can get them to download and install your application, I don’t care WHAT kind of OS or virus protection they run - you own them.

Programs load DLLs for functionality. Some programs use the full path to the DLL, and that isn't vulnerable unless the file can't be found. Others state only the file name, and the system then searches in a pre-configured list of directories for that file to load. This exploit requires the placement of a malicious DLL somewhere in that list of directories before the real one.

The developer has to do some really stupid programming in order for this to work. Normally programs look for DLLs in their own program folder, a known shared DLL folder, or in the system32 folder. Normally browsers can be made to save on the desktop, my documents, or a download folder. The guy was able to exploit IE on this because IE actually looked in the desktop for DLL files. Huh? Some developer at Microsoft needs to be slapped, same for the developers of any of these other apps who did similiar things.

I though you might like to know about this security hole in Windows operating systems.

I hope this helps to clarify the process in question....From MSDN
Text...

Dynamic-Link Library Security
When an application dynamically loads a dynamic-link library without specifying a fully qualified path name, Windows attempts to locate the DLL by searching a well-defined set of directories in a particular order, as described in Dynamic-Link Library Search Order. If an attacker gains control of one of the directories on the DLL search path, it can place a malicious copy of the DLL in that directory. This is sometimes called a DLL preloading attack or a binary planting attack. If the system does not find a legitimate copy of the DLL before it searches the compromised directory, it loads the malicious DLL. If the application is running with administrator privileges, the attacker may succeed in local privilege elevation.

For example, suppose an application is designed to load a DLL from the user's current directory and fail gracefully if the DLL is not found. The application calls LoadLibrary with just the name of the DLL, which causes the system to search for the DLL. Assuming safe DLL search mode is enabled and the application is not using an alternate search order, the system searches directories in the following order:

1.The directory from which the application loaded.
2.The system directory.
3.The 16-bit system directory.
4.The Windows directory.
5.The current directory.
6.The directories that are listed in the PATH environment variable.
Continuing the example, an attacker with knowledge of the application gains control of the current directory and places a malicious copy of the DLL in that directory. When the application issues the LoadLibrary call, the system searches for the DLL, finds the malicious copy of the DLL in the current directory, and loads it. The malicious copy of the DLL then runs within the application and gains the privileges of the user.

Developers can help safeguard their applications against DLL preloading attacks by following these guidelines:

•Wherever possible, specify a fully qualified path when using the LoadLibrary, LoadLibraryEx, CreateProcess, or ShellExecute functions.
•Consider using DLL redirection or a manifest to ensure that your application uses the correct DLL.
•Make sure that safe DLL search mode is enabled. This places the user's current directory later in the search order, increasing the chances that Windows will find a legitimate copy of the DLL before a malicious copy. Safe DLL search mode is enabled by default starting with Windows XP with SP2 and is controlled by the HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode registry value. For more information, see Dynamic-Link Library Search Order.
•Consider removing the current directory from the DLL search path by calling SetDllDirectory with an empty string (""). This should be done once early in process initialization, not before and after calls to LoadLibrary. Be aware that SetDllDirectory affects the entire process and that multiple threads calling SetDllDirectory with different values can cause undefined behavior. If your application loads third-party DLLs, test carefully to identify any incompatibilities.
•Do not use the SearchPath function to retrieve a path to a DLL for a subsequent LoadLibrary call unless safe process search mode is enabled. When safe process search mode is not enabled, the SearchPath function uses a different search order than LoadLibrary and is likely to first search the user's current directory for the specified DLL. To enable safe process search mode for the SearchPath function, use the SetSearchPathMode function with BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE. This moves the current directory to the end of the SearchPath search list for the life of the process. Note that the current directory is not removed from the search path, so if the system does not find a legitimate copy of the DLL before it reaches the current directory, the application is still vulnerable. As with SetDllDirectory, calling SetSearchPathMode should be done early in process initialization and it affects the entire process. If your application loads third-party DLLs, test carefully to identify any incompatibilities.
•Do not make assumptions about the operating system version based on a LoadLibrary call that searches for a DLL. If the application is running in an environment where the DLL is legitimately not present but a malicious copy of the DLL is in the search path, the malicious copy of the DLL may be loaded. Instead, use the recommended techniques described in Getting the System Version.
The Process Monitor tool can be used to help identify DLL load operations that might be vulnerable. The Process Monitor tool can be downloaded from http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx.

The following procedure describes how to use Process Monitor to examine DLL load operations in your application.

To use Process Monitor to examine DLL load operations in your application

1.Attempt to start your application with the current directory set to a specific directory. For example, double-click a file with an extension whose file handler is assigned to your application.
2.Start Process Monitor.
3.In Process Monitor, include the following filters:
◦Operation is CreateFile
◦Operation is LoadImage
◦Path contains .dll
◦Path contains .DLL
◦Path contains .sys
◦Path contains .SYS
4.Exclude the following filters:
◦Process Name is procmon.exe
◦Process Name is Procmon64.exe
◦Process Name is System
◦Operation begins with IRP_MJ_
◦Operation begins with FASTIO_
◦Result is SUCCESS
◦Path ends with pagefile.sys
5.Check Process Monitor output for paths that look suspicious, such as a call to the current directory to load a DLL. This kind of call might indicate a vulnerability in your application.

Send comments about this topic to Microsoft

Build date: 8/19/2010