Following up on Security Advisory 953818, today we released MS09-014, rated as Moderate, which addresses aspects of the Safari Carpet Bomb vulnerability. On a Windows operating system this vulnerability allows an attacker, through Safari, to drop arbitrary files on a user’s desktop. As of Safari 3.1.2 Apple has removed this behavior from Safari.
Why is Microsoft releasing a Bulletin?
While Microsoft code may not have been involved in dropping files on the desktop, there are publicly available exploits that leveraged Microsoft code. Specifically, this was done through the use of Internet Explorer.
Internet Explorer uses the user’s desktop for its current working directory. Both the LoadLibrary and SearchPath APIs use the current working directory when searching for files. As a result of this Internet Explorer would attempt to load certain libraries directly from the desktop. The exploits took advantage of this by using Safari to place carefully crafted libraries on the user’s desktop, which then caused Internet Explorer to run arbitrary code.
Even though the ability to drop arbitrary files on the user’s desktop has been removed from Safari, we wanted to further protect users by preventing IE from using the libraries involved in the exploit. This was done by changing several calls to LoadLibrary and SearchPath in Internet Explorer.
Additional Defense in Depth Protections
In addition to making the code changes, we realize that IE is a highly extensible platform. It uses many different libraries and hosts a large number of different components, many of which are developed outside of Microsoft. To help protect these components from exploitation, we have put together some other defense in depth protections.
Part of these protections involves removing the current working directory from the LoadLibrary search path. In order to do this without impacting other processes, the SetDllDirectory API is used. In particular, IE calls SetDllDirectory with an empty string (“”). Another part of the protections involves changing the order in which SearchPath searches directories. A new API called SetSearchPathMode has been created and allows IE to force the current directory to be searched after the system locations. As with SetDllDirectory, SetSearchPathMode does not impact processes outside of IE.
Unfortunately, the application compatibility tests we perform with each update have indicated that these protections have the potential to break consumer applications. We cannot enable the protections by default without causing problems for some customers and have elected to ship the update with them turned off. For users and enterprises who wish to enable the protections, this can be done by setting the feature control key listed in the security bulletin under “Frequently Asked Questions (FAQ) Related to This Security Update” (http://www.microsoft.com/technet/security/bulletin/ms09-014.mspx#ERIAC). Before turning them on, you should test to ensure they do not prevent applications in you environment from working correctly.
As a final comment, you should be aware that even with these protections in place, it is possible, in certain circumstances, to load a library from the current directory. This can happen for code that uses SearchPath to locate libraries and later uses LoadLibrary to load what SearchPath found. In this situation a library can get loaded from the current directory if the library is not present at any location in the system path. This happens because SearchPath checks the current directory as a last resort when locating files. We were unable to address this with the additional defense in depth protections as the SearchPath API is intended to locate user documents and legitimately should search the current directory. Developers are advised not to use Search to locate libraries and instead should rely on LoadLibrary to find them. This is covered in more detail in the following section.
Notes for Developers
For developers who wish to avoid similar problems, there are two key things that can be done to help prevent libraries from being loaded form the desktop:
- Do not use SearchPath to locate libraries that you intend to load with LoadLibrary. SearchPath follows a different path search order than LoadLibrary when locating files. The search order it follows by default is intended for user documents and is insecure for locating libraries. This warning is reflected in the MSDN pages for both LoadLibrary and SearchPath. For developers that need to find that path where a library is loaded from, you can use GetModuleFileName after calling LoadLibrary.
- If the DLL you are loading does not always exist on the system, use a fully qualified path to prevent your code from inadvertently loading a malicious copy. To help generate fully qualified paths, you can use the ExpandEnvironmentStrings function in conjunction with strings such as %WINDIR% and %PROGRAMFILES%.
By following these two rules, it is possible to prevent your code from inadvertently loading a library from the current working directory.
As with all our updates, we recommend applying this update as soon as possible.
-SRD Bloggers
Update April 15th: URL corrected thanks to reader Frank Zieman for pointing this out.
*Postings are provided “AS IS” with no warranties, and confers no rights.*