“Blended” attack : Safari « Carpet Bomb » and Internet Explorer vulnerability 

The goal of this article is to explain the combined attack which involved Apple Safari and Microsoft Internet Explorer browser security during the past month. In fact, we were able to read lots of polemic articles in the computers press shifting the blame to one or the other software. In particular, a definite confusion could have been generated when Microsoft Published a security advisory relative to the risks linked to the use of the Safari browser.

The attack discussed in the advisory actually covers two issues. If we consider those issues separately, they don’t represent a real security flaw. It’s only when there are considered in a “blended” attack context that the resulting impact raises to a remote arbitrary code execution:

• The first issue affects the way downloads are handled in Safari, which is commonly named “Carpet Bomb” in the computers security press,

• The second issue regards the way Internet Explorer loads DLLs (libraries) into memory, security articles often refer to this issue by the expression “DLL-load hijacking attack”.

The issue that has been named “Carpet Bomb” affects the Apple Safari browser and can be exploited either on Windows or MacOS X. This naming can easily be explained by the consequence of a successful exploit: in fact, browsing a specially crafted website can lead to the “bombing” of the download directory by multiple unwanted files resulting in a mess of this directory. Note that on Windows, the default downloads directory is the user’s desktop.

On 15th of May 2008, the security researcher Nitesh Dhanjani revealed this problem and warned the Safari user community about this vulnerability. Actually, the download of files that can not be interpreted directly by Safari itself (DLLs, programs, compressed archives …) is performed automatically by Safari. So, when a user clicks on such a file in order to download it, the file is downloaded and put straight onto the desktop without his consent, if of course the default download directory has not be changed: no confirmation dialog box is displayed contrary to the behaviour of other widely used browsers.

This behaviour isn’t a real security flaw and could be considered as a quite reasonable and convenient feature. But if this is combined with another vulnerability, it can expose the user’s system to a rather high risk of damage. At this point, we can also note that browsing to a Web page containing a large number of malicious Iframes (e. g. Iframes pointing to a file that can’t be interpreted by Safari) could cause the user’s desktop to be “bombed” by many nasty files without any specific action from the user.

On last 30^th of May, Microsoft released a security advisory (KB953818) which mentioned the possibility to use the “Carpet Bomb” vulnerability of Safari to perform a combined attack which may affect or involve Internet Explorer. No additional information is provided in this advisory relatively to the vulnerability that can be exploited in the Microsoft’s browser. We then have had to wait for a few more days to be able to find, through posts in security blogs, some relevant technical details about the combined attack that can be performed against people who use these two browsers.

This vulnerability, which can apparently be found on every versions of Internet Explorer, is due to the way Internet Explorer looks for the Dynamic Loadable Libraries (DLL files) needed for it to launch and run properly. In fact, security researchers have noticed that the Microsoft’s browser tries to search for DLLs first in the user’s desktop before trying to look for them in its own library directory (generally C:WINDOWSSYSTEM32). In order to successfully exploit this vulnerability, an attacker just needs to drop a DLL on the desktop having the same filename as a legitimate DLL file usually loaded by Internet Explorer (for example schannel.dll or imageres.dll). Then, at the next start of Internet Explorer, the dynamic library file located in the user’s desktop will be loaded instead of the one located in the system directory. So to exploit this vulnerability, a malicious person has to create its own DLL file and put the compromising code within to DLLMain function of this DLL (this function is the entry point defined by the operating system and so it is executed each time the library loads on Windows).

Actually, this vulnerability has been known for more than one year. At end of 2006 technical details and a Proof of Concept (PoC) related to this issue have been disclosed in the blog of the security researcher Aviv Raff within a post entitled “Internet Explorer 7 - Still Spyware Writers Heaven”. The name of this researcher is also mentioned in the Microsoft security advisory dealing with the Safari vulnerability published last month. Those two publications mentioning the same security researcher allowed us to make the connection between the Safari and the IE vulnerabilities and we were then able to imagine a “blended” attack combining both vulnerabilities.

The Cert-IST has investigated into the Internet Explorer vulnerability especially in order to find or identify workarounds. For example, some articles found on the Internet were mentioning that Internet Explorer was first looking for DLLs in the current directory, what could explain the fact that a library placed on the desktop is loaded when Internet Explorer is launched from the desktop.

Note: the investigations were performed with Internet Explorer 7 under Windows XP SP3. In addition, we noticed that the vulnerability could not be reproduced on a Windows Vista SP1 system.

So we carried out some experiments regarding the "SafeDllSearchMode" feature that can be enabled in the system registry in Windows versions 2000 SP4 and above. This feature allows modifying the DLL search order performed by the system. When this feature is enabled, the directories are searched in the following order:

• The directory from which the application loaded (for example c:Program FilesInternet Explorer in the present case),
• The system directories (WINDOWSSYSTEM32 and WINDOWSSYSTEM),
• The Windows directory (generally C:WINDOWS),
• The current directory,
• The directories listed in the "PATH" environment variable.

When the "SafeDllSearchMode" is disabled, the search order is the same excepted for the current directory which is browsed just after the directory from which the application loads. So the search order in a "non-secure" configuration is the following:

• The directory from which the application loaded,
• The current directory,
• The system directories,
• The Windows directory,
• The directories listed in the "PATH" environment variable.

We have been rather surprised to read in the Microsoft documentation that the "SafeDllSearchMode" is enabled by default starting from Windows XP SP1. However our practical experience has shown that the vulnerability is still exploitable on Windows XP SP3 updated with the last security patches. So it seems that independently from the settings regarding library search, Internet Explorer systematically looks for its libraries in the desktop directory instead of looking for them in the system directories.

From our tests, we think that:

• There is no countermeasure to prevent the Internet Explorer dangerous behaviour.
• The Internet Explorer behaviour regarding the search of needed libraries is: either hard-coded in Internet Explorer, or results from an issue in the Windows API.

However we can notice that, if we exclude the scenario that combines the IE and the Safari vulnerabilities, the IE flaw on its own doesn't represent a very high risk. In fact, somebody who is able to put a file on the Windows desktop has probably already broken into the system or has a physical access to this system, and so is able to run arbitrary code (using other methods than the IE vulnerability).

To summarize, on one hand Safari for Windows downloads files by default onto the desktop without the user's consent, on the other hand Internet Explorer loads dynamic libraries from the desktop if these ones have a specific filename. When those two vulnerabilities are considered in a "blended" attack context, IE can mistakenly load and execute code from a file downloaded by Safari.

The typical scenario of such an attack could be as follow:

• A user runs Safari and browses by accident to a malicious website. Thanks to the vulnerability existing in this browser, this website can put a malicious DLL file onto the user's desktop.
• Later, this same user launches Internet Explorer. At this point, we can notice that the user doesn't need to run IE from the desktop to trigger the vulnerability. Clicking on a link within an e-mail can also cause the execution of the malicious code, if however Internet Explorer is set as the default browser in Windows.

Whereas the impact associated to this combined attack is a remote code execution, some information lead us to think that the risk should be put into perspective:

• Safari for Windows not much used,
• The vulnerability can not be triggered on Windows Vista,
• The version 3.1.2 of Safari published on the 19^th of June 2008 asks the user's permission before downloading files. In addition, the default download directory is not the desktop anymore.

Even if the risk is not as critical as some articles in the computer security press related it to be, we do think that the Internet Explorer vulnerability could also exist in other software. If it appears that the issue is due to a vulnerability in the DLL search mechanism in Windows XP, each application that doesn't specify a full path when calling the "LoadLibrary()" function of the Windows API could be vulnerable to those kind of hijackings.

• LIUDIEYU's blog: several posts giving a comprehensive summary, all the references and links related to this attack
• Microsoft Documentation regarding the "SafeDllSearchMode" feature
• Microsoft security advisory (KB953818) reporting this combined attack