Adobe Reader X (10.1.2) msiexec.exe Planting

Outside The Sandbox, But Not Terribly Critical

Adobe today issued an update for Adobe Reader X (new version is 10.1.3), which, among other issues, fixes the outside-the-sandbox msiexec.exe EXE planting vulnerability (CVE-2012-0776) I roughly demonstrated during my RSA Conference US talk last month titled "Advanced (Persistent) Binary Planting."

This article explains the vulnerability and how it could have been exploited. It builds upon our research already published here, which I recommend you read before proceeding if you haven't already.


The Bug

It is a typical EXE planting: Under certain conditions, Reader (specifically, the AcroRd32.exe process) launches msiexec.exe using the CreateProcess function without providing a full path to the executable. This triggers a search for msiexec.exe through the CreateProcess search path as explained here; consequently, if the current working directory of AcroRd32.exe  happens to point to a location under attacker's control and said attacker planted a malicious msiexec.exe there, that msiexec.exe would get executed instead of the intended one.

Furthermore, attackers would appreciate the malicious msiexec.exe getting executed outside the Reader's sandbox, i.e. with unlimited permissions of the user running it.

So how does one get the Reader to point its current working directory to a location of a malicious executable? The easiest way is to place a PDF document and msiexec.exe in the same folder and either double-click the PDF or have the PDF opened by some application. Since the double-clicking scenario has been discussed extensively in the past and it is believed to be frustratingly difficult to get a security expert to double-click an unknown document in an Internet-based shared folder, we shall investigate the other vector: application-based document opening.


The Exploit - Stage One

As already mentioned in "Downloads Folder: A Binary Planting Minefield," the Downloads folder - a folder where most leading web browsers store user's downloads - can be a highly suitable location for what could aptly be called side-by-side payload. While most browsers will require user confirmation when a web site tries to download an executable to user's computer, Google Chrome was, and still is, willing to do so without any question - and such process of downloading can be highly unnoticeable. Let's see how this could look like for a user under attack.

The above video demonstrates how a web site can silently get msiexec.exe downloaded to user's Downloads folder by having the user click on a link - in this case, the link took the user to Google search page, but it could as well take him anywhere else, or nowhere, for that matter. A keen observer may have noticed that, around the 19th second of the video, a small Chrome pop-up window appears in the bottom right corner: this is where the download actually occurs in order to prevent the main Chrome window from displaying the button of the downloaded file. Some extra work could make this pop-up entirely invisible.

Now that we have a malicious msiexec.exe in our Downloads folder - possibly sitting there for weeks or months -, it's time for stage 2.


The Exploit - Stage Two

The second stage of the exploit requires a malicious web page to get some PDF document to the Downloads folder (where msiexec.exe is already waiting) and have the browser open it. This sounds easy - but there's a trick: the browser must open the PDF externally, in a separate Reader process, and not in browser's integrated PDF viewer. There is a way to achieve this in Chrome (and other browsers too). In the following video, we use Gmail to deliver an e-mail with a PDF document attached to the targeted user, and use Gmail's download functionality to actually download the PDF to the Downloads folder instead of rendering it directly in Chrome. Let's see what happens.

The video demonstrates one way to get a PDF downloaded (instead of rendered) to user's Downloads folder. Any malicious web site could do the same and not even offer a way for users to see the PDF directly in the browser (which Gmail does offer, by the way).

Also, the video shows what the user has to do in Reader to get the malicious msiexec.exe executed: he has to manually select Help -> Repair Adobe Reader Installation and confirm in by clicking Yes. Hardly what users go about doing on their own all the time, or even occasionally. The attack, therefore, requires social engineering; I'll leave it to others to continue the "How much social engineering is too much?" debate and shall merely point out a possibility that training users to avoid opening e-mail attachments from unknown sources or downloading executables from the Internet may not do much to prevent the same users from trying to repair their Reader in order to reach some strongly desired content.


Administrators Only

An important mitigating factor limits the exploitability of this issue: The Repair Adobe Reader Installation menu item is only available to administrative users. Therefore, if you're logged in to your desktop as a non-admin user, you now know of one more way in which your computer didn't get owned. On the other hand, if you're logged in to Windows 7 as a "protected administrator," you will have this menu item and if you chose to repair the Reader installation, you would probably not hesitate too much when the malicious msiexec.exe asked you to elevate its privileges.


Conclusion

All in all, this was not a terribly critical vulnerability as its exploit scenario includes non-trivial social engineering and it only applies to users working as administrators, but it serves as a nice reminder that EXE planting issues may continue to expose an application - and its users - even after the more commonly understood DLL planting bugs have been eradicated or mitigated. Meanwhile, attackers are probably happy to know that, with Chrome, it is much easier to silently plant an EXE to the Downloads folder than it is to do the same with a DLL.


Take care,
@mkolsek
@acrossecurity

Downloads Folder: A Binary Planting Minefield

Browser-Aided Remote Binary Planting, Part Deux

This article reveals a bit of our research and provides an advance notification of a largely unknown remote exploit technique on Windows. More importantly, it provides instructions for protecting your computers from this technique while waiting for the affected software to correct its behavior.

Two weeks from now I'll be holding a presentation at RSA Conference US called "Advanced (Persistent) Binary Planting" (Thursday, March 1, 9:30 AM Room 104). The presentation will include demonstrations of "two-step" binary planting exploits where in the first step the attacker silently deploys a malicious executable to user's computer, and the second step gets this executable launched. For those familiar with our past research on binary planting, this removes the need for remote shared folders as well as the need to get the user to double-click on a document in Windows Explorer.

Obviously, the idea is not new: If the attacker manages to somehow get her executable onto user's computer, getting it executed may be just a step away. But in order to deploy the file without heavy-duty social engineering (which invariably works in practice but is frowned upon among security folks) or physical access (which may include an overseas round trip), what is she left with? One ally she may find is the web browser - which lets the user download all sorts of files from all sorts of web sites. Directly to the Downloads folder.


What's In Your Downloads Folder, Anyway?

If you have ever downloaded anything from the Internet, you know that you can always find it in the browser's "Downloads" or "Downloaded files" window. This window also provides a way to delete any downloaded file, or all of them, with just a few clicks. Or so one would think.

Actually, browsers don't delete files from the Downloads folder: they only delete them from the browser's list so that they're no longer visible to the user. In fact, between the latest versions of top web browsers (Chrome, Firefox, Internet Explorer, Safari and Opera), only Internet Explorer 9 (not 8) and Opera provide a way to actually delete a downloaded file from the Downloads folder through their user interface, and even then you have to do it through a right-click menu - in Opera even a sub-menu. Only Opera allows you to delete all files at once.

As a result, your average Downloads folder is a growing repository of files, new, old and borderline ancient. If anything malicious sneaks by your browsers' warnings or your mental safeguards, it is bound to stay there for a long time. Waiting for someone or something to launch it.


Do You Really Want To Download This?

But, you may say, all major web browsers will warn the user if he tries to download an executable file, and the user will have to confirm the download. Right?

Not entirely. One major web browser will, under certain conditions (to be explained at the presentation), download an executable to the Downloads folder without asking or notifying the user. For sure, it will then not execute this file, but the file will remain in the Downloads folder. Possibly until the user re-installs Windows. Furthermore, the same web browser allows a malicious web page to trick the user into confirming a download attempt using clickjacking (an old trick), which is another way to get the executable to the Downloads folder.

And finally - applying to all web browsers -, if some extremely (perhaps even obscenely) interesting web site persistently tries to initiate a download of an executable, how many attempts will it take before an average web user tells it to shut up already and accepts the download, knowing that it will not be automatically executed?


Downloaded But Not Executed? Give It Time.

So the Downloads folder tends to host various not-so-friendly executables. Big deal; it's not like the user is going to double-click those EXEs and have them executed. No, not the user directly, but other executables that he downloads and executes - for instance, installers.

We found that a significant percentage of installers we looked at (especially those created by one leading installer framework) make a call to CreateProcess("msiexec.exe") [simplified for illustration] without specifying the full path to msiexec.exe. This results in the installer first trying to find msiexec.exe in the directory where it itself resides - i.e., in the Downloads folder (unless it was saved elsewhere) - and launching it if it finds it there.

And this is just one single executable. If you launch Process Monitor and observe activities in the Downloads folder when any installer is launched, you will find a long series of attempts to load various DLLs. Not surprising: this is how library loading works (first trying to find DLLs in the same folder as EXE), and in most cases it would not be a security problem as most folders hosting your EXEs are not attacker-writable. However, the Downloads folder is - to some extent, anyway.

So what do we have here? An ability to get malicious EXEs and DLLs to the Downloads folder, where they will in all likelihood remain for a very long time, and at least occasional activities on user's computer that load EXEs and DLLs from the Downloads folder. This can't be good.

But that's it for now. My presentation will also feature data files (non-installers) launching executables from the Downloads folder in a "classic" binary planting manner, instructions for finding binary planting bugs, recommendations for administrators, developers and pentesters, and more.


What You Should Do Right Now

For those of you who think we might be the first people in the world to have thought of this - we sincerely appreciate your compliments! The rest of you should do the following:

1. Open your browser's Downloads folder in Windows Explorer or any other file manager.
2. Look for the presence of msiexec.exe. If you find it there and you don't think you intentionally downloaded it at some point in the past, send it to your favorite malware research (anti-virus) company and delete it from your Downloads folder.
3. Look for the presence of any *.dll files in the Downloads folder and do the same as in the previous step.
4. Delete all files from the Downloads folder.
5. Locate msiexec.exe in your %SystemRoot%\System32 folder and copy it to the Downloads folder. (Note: this will prevent Windows to update the msiexec.exe that will be used when installing files from the Downloads folder, but won't affect installers launched from other locations. On the upside, it will also block installer-based attacks described above.)

Hope to see you at RSA Conference,
@mkolsek
@acrossecurity

More Misconceptions About Binary Planting

Last year, soon after revealing our binary planting research project, we published a blog post clearing up five frequently-appearing misconceptions at that time. Over a year (and about a hundred publicly fixed binary planting bugs in all sorts of software products) later, we're noticing a different set of misconceptions in public forums and on mailing lists. While we made our best effort to present binary planting in as comprehensible and clear way as we could, we accept responsibility for our undoubtedly imperfect rendition and hope this post will help interested readers to better understand our arguments.


Misconception #6: "This is a local attack."

We still occasionally come across this misconception that in a binary planting attack, the user has to willfully download a DLL or EXE and place it in some particular location on his computer, from where it will subsequently be launched. If this were true, binary planting would certainly be a ridiculous concept.

Actually though, in a typical binary planting attack the user doesn't have to download anything to his computer. He opens a file from a remote (attacker-controlled) shared folder and the vulnerable application on his computer automatically, silently executes a DLL or EXE from that same remote folder. Moreover, advanced attacks don't even require the user to do anything more than, for example, visiting a web page and clicking on two links - now who isn't doing that on a daily basis?

Misconception #7: "It doesn't work remotely on a default Windows machine."

We've heard objections that perimeter firewalls in typical networks won't allow internal Windows computers to access shared folders on an Internet-based server due to their default blocking of outbound SMB connections.

Windows 2003 Server introduced a Web Client service, which is an automatic WebDAV redirector for Windows networking connections. In short, this service makes it possible for Windows users to connect to remote network shared folders via the HTTP protocol, and this happens automatically when such connections via the SMB protocol fail. This means that even if a perimeter firewall blocks SMB network traffic towards the Internet, Windows will automatically try to connect to a remote shared folder via WebDAV (which is an extension of HTTP). We believe very few perimeter firewalls block outbound HTTP traffic as this would mean that internal users wouldn't be able to use their web browsers. WebDAV-only outbound blocking can be done by various firewalls, but this doesn't seem to be their default behavior in general *.

Anyone wishing to test whether their firewall allows outbound WebDAV connections can try to visit \\www.binaryplanting.com\demo with Windows Explorer on a reasonably default non-server Windows machine (with the Web Client service running or at least not disabled on a Windows 7 system).


Misconception #8: "Attacker could just as well get the user to open an executable."

We've heard this objection more than once and it goes like this: If in a typical binary planting attack scenario, the attacker has to trick the user to double-click a data file from a remote shared folder (which results in a vulnerable application loading a malicious DLL from the same folder), why couldn't the attacker simply get the user to double-click a malicious EXE with an icon of a data file?

It is entirely true that one can give an EXE an arbitrary icon and make it look exactly like any chosen data file such as Microsoft Word DOC or Adobe Reader PDF document. Furthermore, one can even disguise the way the file extension is displayed to the user using the UNICODE "right to left" trick. This makes it impossible for a user to visually distinguish an executable from a document file without manually inspecting their properties.

However, the difference comes after double-clicking the file, as long as this file is on a network share (as opposed to on a local drive): in case of a data file, the application associated with this file type gets launched and opens the data file; but in case of an executable, Windows display a security warning to the user saying that he is about to launch an executable from a network location and asking the user's permission to do so (see image below). While we have no field data on how effective such warning would be in stopping a "disguised executable" remote attack, it enables organizations to educate their users and increase their odds.

Moreover, double-clicking a file is not the only way to successfully trigger binary planting. The role of double-clicking in the attack is to set the current working directory to the location of the data file, so that the vulnerable application subsequently loads the malicious DLL from there. But the current working directory can also be set by opening the same data file by first launching the application and then using the File Open dialog to browse to the file and open it. (Very few applications don't change the current working directory this way.) Now, the file browse dialog will not show the disguised executable as it has an unsupported extension not matching the file type filter, and will not launch the disguised executable even if the user selects the "All files" filter, selects the executable and presses the "Open" button.

We hope this adequately describes the significant difference between a remote data file and a remote disguised executable in the context of a binary planting attack.


Credits

We'd like to end this post by thanking everyone contributing in public or private debates about binary planting vulnerabilities. We may not always all agree on everything, but such exchange of views, opinions and facts is exactly where new and better knowledge comes from. Thank you!


(* The amount of successfully received WebDAV requests from large and small organizations to our testing WebDAV server confirms that many perimeter firewalls are not blocking outbound WebDAV.)

Binary Planting Goes "Any File Type"

File Planting: A Sample From Our Security Research


It's been almost a year since we revealed our Binary Planting research project which identified 520+ remote execution vulnerabilities in almost all Windows applications. During this period, hundreds of binary planting vulnerabilities have been publicly reported and some have actually been fixed.

While some in the security community still seem to have a hard time understanding that binary planting doesn't only affect the loading of libraries but also stand-alone executables, we went further and "extended" the problem to all file types. This blog post reveals an interesting sample from our current research on what we call File Planting.


Java Hotspot VM Configuration Files

The current Oracle's Java Runtime Environment (version 6, update 26) - just like its previous versions - supports so-called Hotspot configuration files .hotspotrc and .hotspot_compiler. These files are loaded when Java virtual machine is initialized and can specify (or override) the VM settings that are usually provided as command-line parameters for java.exe or exclude chosen methods from compilation, respectively.

Now this would be just fine... if JRE didn't try to load these configuration files from - you guessed it - the current working directory. So if the current working directory (which we now all know can point to various locations, including a remote share on attacker's server) contains these configuration files, they will be loaded and will influence the way Java virtual machine behaves.

We focused our analysis on the .hotspotrc file since fiddling with VM settings seemed more promising from the security point of view. And indeed, we quickly located a VM setting that can be exploited for launching arbitrary executable: OnOutOfMemoryError. This setting allows one to specify user-defined commands that get ran in case JRE runs out of memory, or more specifically when the OutOfMemoryError error is thrown for the first time. Therefore:


OnOutOfMemoryError="malicious.exe"

 plus

Java code that exhausts all available memory

 equals

launching of malicious.exe.


Now, how does one set the current working directory for JRE to an attacker-controlled location? Normally, when Java applications are launched either manually or as a service, this is rather difficult if possible at all: in the former case, the current working directory is set to the location of user's command-line window and in the latter case, the current working directory is inherited from the parent process and can not be influenced by a low-privileged - much less remote - attacker.

The game changes, as it often does, in web browsers. All major web browsers support Java, and can load and execute a remote Java applet inside a web page.


Exploiting The Bug

For this experiment we need four files, which you can find neatly packed on our web page:

1. .hotspotrc : a Java configuration file with a single line OnOutOfMemoryError="malicious.exe"
2. Test.class : a Java applet that consumes all available memory (ours simply concatenates a string to itself many many times)
3. Test.html :  an HTML document that loads the applet
4. malicious.exe : the executable to get executed

Suppose the current version of Apple Safari (5.0.5) is our default web browser. If we put the above files in the same directory (on a local drive or a remote share) and double-click Test.html, what happens is the following:

1. Safari gets launched and sets its current working directory to the location of Test.html. (Not intentionally - Windows Explorer sets the CWD this way for all launched applications.)
2. Safari loads and renders Test.html from our directory.
3. Test.html invokes a Java applet called Test.class, triggering the initialization of the Java virtual machine. 
4. jvm.dll, the Java Hotspot Client virtual machine running inside the Safari process, loads .hotspotrc from our directory, parses it and employs the OnOutOfMemoryError setting found inside.
5. jvm.dll loads the Java applet Test.class from our directory and executes it inside the Safari process, causing an OutOfMemoryError error within seconds.
6. jvm.dll responds to the OutOfMemoryError error according to the OnOutOfMemoryError setting and launches malicious.exe from our directory using a CreateProcess call.

The attack can be mounted in the same way through Mozilla Firefox (any version), with the slight difference that Firefox actually launches an external java.exe process, which then runs malicious.exe. Furthermore, this attack can also be mounted through Internet Explorer or Google Chrome, although these set their current working directory to some safe location, meaning extra work for the attacker. (More on this some other time.)

Similarly to binary planting attacks, this file planting attack can also be mounted from a remote share, even from a WebDAV share on an Internet server. Since the malicious executable is launched with CreateProcess, there will be no security warning due to launching a remote file.

Note that neither Safari nor Firefox, nor any other web browsers are at fault here. They merely play the role of an attack delivery vehicle, while the security error is in Oracle's code.


File Planting vs. Binary Planting

File planting has a common attribute with binary planting in that files (data files or binaries) are loaded from the current working directory, which the attacker can control and thus plant a malicious file. Two major differences between file planting an binary planting, however, are:

First, a binary planting exploit looks the same in 99% of cases. If an application is willing to load your DLL or launch your EXE, you simply plant a generic malicious DLL/EXE and it almost always works. In a file planting attack, you have to understand the context of the file, what the application does with it and how (if at all) your ability to plant the file can be leveraged to mount a decent attack.

Second, some binary planting attacks can be blocked by firewalls that don't let computers in internal networks download executables from the Internet (based on files' extensions or content), and by web browsers that block downloading of such potentially dangerous files. With file planting, there can be no predefined rule to recognize a potentially malicious data file.

There are also many other interesting, significant as well as subtle differences between the two, but let this be enough for now.


What Should Oracle Do To Fix This Bug?

JRE should stop loading its configuration files from the current working directory, at least on Windows. This may not be so easy to do as some developers and their applications likely depend on this feature and doing so might break these applications. A fairly risky compromise would be to prevent loading of configuration files from the current working directory when JRE is invoked from web browsers, which would address the scope presented here. The risk would be that some other applications may also launch or integrate JRE and may thus provide a similar attack vector. A thorough functional and security analysis of this issue is thus inevitable if Oracle wants to fix this bug properly.



(Credits for research presented here goes to my colleagues, security researchers at ACROS Security: Jure Skofic for developing the uber vulnerability detector and Simon Raner for a great analysis of this vulnerability.)

The Anatomy of COM Server-Based Binary Planting Exploits

[May 6, 2011 update: we published a proof of concept for this vulnerability.]

Last week at the Hack In The Box conference in Amsterdam we presented some techniques for advanced exploitation of binary planting bugs. The stage was set by our previous blog post where we described how unsafely registered COM server DLLs, as well as safely registered COM server DLLs that make unsafe binary loading calls, could be abused for mounting binary planting attacks. This post reveals our work to the rest of the world.


The Magic Of Special Folders

One of the elements we used in our exploits were Windows special folders. Special folders are folders that can be shown by Windows Explorer but don't always behave like ordinary folders, which simply contain files and other folders. Some examples of special folders are Control Panel, My Computer, My Documents, Administrative Tools and Printers. Every one of these special folders is implemented as an in-process COM server with a specific class identifier (CLSID). For instance, the CLSID of My Computer is {20D04FE0-3AEA-1069-A2D8-08002B30309D}.

Let's begin with a small magic trick (works on XP, Vista and Windows 7): Create a new empty folder anywhere on your file system and rename it to folder.{20D04FE0-3AEA-1069-A2D8-08002B30309D}. (Note that the CLSID must be the extension of the folder name, i.e., must come after the final dot.) Immediately after renaming, the folder's icon will be changed to the icon of My Computer and, moreover, opening the folder will actually show the My Computer content.

Apart from having an obvious entertaining value, this trick also plays an important role in our exploits. Many applications, when processing files from special folders, or display the content of special folders, trigger the instantiation of such folders' COM servers based on the CLSIDs in their extensions. Which brings us to the first exploit.


Double-Click Attack 1: Wordpad on Windows XP

As already mentioned in our stage-setting blog post, all Windows XP installations have a registered COM server called "Display Panning CPL Extension" with CLSID {42071714-76d4-11d1-8b24-00a0c9068ff3}, implemented by a non-existing deskpan.dll. Consequently, if some application decided to instantiate such COM server, this would result in loading deskpan.dll from the current working directory. As you might have guessed, the special folders magic can make an application instantiate just any registered COM server. Let's do this with Wordpad.

The video below shows the following procedure:

1. create a "malicious" deskpan.dll;
2. create a new folder and rename it to files.{42071714-76d4-11d1-8b24-00a0c9068ff3} - note that Windows XP hide the folder extension, and that this special folder still behaves like an ordinary folder;
3. copy the malicious deskpan.dll to the new folder;
4. open the folder;
5. create a new rich text document in the folder;
6. double-click the rich-text document.

After double-clicking the rich text document, Wordpad gets launched and its current working directory gets set to the special folder (which is the expected behavior). However, for reasons unknown to us, Wordpad then triggers a call to the COM server-instantiating function CoCreateInstance with the CLSID of our special folder. This causes a registry lookup for the COM server DLL (deskpan.dll), and then an attempt to load this DLL using a LoadLibrary call. Failing to find this DLL in Wordpad home directory as well as in all Windows system folders, the "malicious" deskpan.dll is finally loaded from our special folder and executed.


Double-Click Attack 2: Applications on Windows 7

In contrast to Windows XP, a fresh installation of Windows 7 has no unsafely registered in-process COM servers. It does, however, have several safely registered COM servers whose DLLs make unsafe library loading calls. (XP and Vista have such DLLs too.)

One such case on Windows 7 is the COM server called "AnalogCable Class", registered with CLSID {2E095DD0-AF56-47E4-A099-EAC038DECC24} and having C:\Windows\System32\PsisDecd.dll as its DLL. When an application instantiates this COM server, the PsisDecd.dll is loaded from the System32 folder (which is okay), but this DLL quickly makes a call to LoadLibrary("ehTrace.dll"). Now it's not that ehTrace.dll doesn't exist on Windows 7: it does exist in folder C:\Windows\ehome - but applications launched outside this folder are unable to find it. This means that applications from folder C:\Windows\ehome, for instance ehshell.exe, can safely and successfully instantiate the said COM server, while other applications automatically become vulnerable if they try to do the same.

The video shows the following procedure:

1. create a "malicious" ehTrace.dll;
2. create a new Microsoft Word 2010 document;
3. create a new Microsoft PowerPoint 2010 document;
4. create a new text document;
5. create a new PDF document;
6. create a new folder and rename it to files.{2E095DD0-AF56-47E4-A099-EAC038DECC24} - note that Windows 7 also hide the folder extension, and that this special folder still behaves like an ordinary folder;
7. copy all four data files and the "malicious" DLL to the new folder;
8. open the folder;
9. double-click the Word document; (causing Word 2010 to execute the "malicious" ehTrace.dll)
10. double-click the PowerPoint document; (causing PowerPoint 2010 to execute the "malicious" ehTrace.dll)
11. double-click the PDF document; (causing Nitro PDF Reader to execute the "malicious" ehTrace.dll)
12. double-click the text document; (launching Notepad but not immediately executing the "malicious" DLL)
13. selecting "File -> Save As" from the menu in Notepad. (causing Notepad to execute the "malicious" ehTrace.dll)

Similarly to the Wordpad exploit on Windows XP, the above exploits are based on the curious and heavily undocumented nature of special folders, which makes otherwise innocent applications instantiate chosen COM servers. Thus Word, PowerPoint and Nitro PDF Reader (and many other applications) all try to instantiate the "AnalogCable Class" COM server while having their current working directory set to our special folder. This results in a search for ehTrace.dll, and in the loading of "malicious" ehTrace.dll from our special folder. The final target, Notepad, does not get hacked simply by opening a file - but does execute the "malicious" DLL when the "Save As" dialog is opened. Apparently Notepad does not automatically trigger the COM server instantiation when a document is loaded, but opening the "Save As" dialog causes the code behind this dialog to interact with the special folder, thus instantiating the appropriate COM server.

Leveraging COM Server Exploits Through Web Browsers

Skeptics among you may say that, okay, this opens up new attack vectors for various binary planting vulnerabilities, but the user would still have to double-click a document on a remote share. And users wouldn't do that, would they? (Of course they would but let's pretend they wouldn't.) So in order to satisfy the most demanding among you, we leveraged the above exploits through web browsers, resulting in some pretty user-friendly scenarios, in a manner of speaking. Let's start with Windows XP and Internet Explorer 8.

Web Attack 1: Internet Explorer 8 on Windows XP

The following video shows how a user would experience the attack. Visiting a malicious web site, clicking once on one link, and again on another, is enough to get a remote binary executed on his computer.

Two tricks are employed in the background of this attack. The first is aimed at launching applications without double-clicking. One of the methods we found for this makes use of the default Windows XP Task View, i.e., the task list shown in Windows Explorer on the left of each folder view. When a printable document is selected in the folder, this task list includes the "Print this file" link which, when (single-) clicked upon, launches the application associated with the file type of the selected file and instructs it to initiate the printing process. The procedure is thus: 1) click the file in a remote special folder to select it, and 2) click "Print to file" to launch the application which then loads a malicious DLL.

The second trick is clickjacking. This old trick is simply used for hiding the actual attack inside a 1x1 iframe such that wherever the user clicks on the web page the first time (anywhere on the page, not only on links), he actually clicks inside this tiny iframe - precisely on the Wordpad document shown in a remote shared folder, thereby selecting this document. The iframe then repositions its remote content such that when the user clicks again, he actually clicks on the "Print this file" link in the same remote shared folder as before, thereby launching Wordpad and executing the malicious DLL inside it. Now, since most attackers want to hide their attacks as much as possible, we made the demo such that when the user clicks inside the tiny iframe, we detect that and simulate the click on the underlying web page as well, which is why the links apparently clicked on actually respond to the clicks.

For those of you preferring the schematic diagrams, here's how it works in the language of objects, arrows and annotations (taken from our Hack In The Box slides).

Web Attack 2: Internet Explorer 9 on Windows 7 With Protected Mode


We've already seen that applications can be made vulnerable through unsafe COM servers on Windows 7 just like on Windows XP. But there are two additional challenges here. First, Windows 7 don't have the task view like Windows XP do, so another way to avoid double-clicking had to be found. And second, you can't just launch any application from IE when in protected mode without popping up the yellow security warning.

For the first challenge we chose to reveal a "right-click, send to compressed (zipped) folder" trick. IE allows the user to right-click a folder inside a remote shared folder (without a warning), and then select "send to" and "compressed (zipped) folder" from the context menu. This triggers a process of compression, which sets the current working directory of IE to the remote shared folder - and completes the first part of the attack.

The second challenge was overcome with the help of verclsid.exe. This curious little executable, mostly unknown to users, gets frequently launched in the background and quickly terminates without any visible effect. Verclsid.exe is, ironically, a security measure introduced by a Windows security update associated with bulletin MS06-015, but to us it is interesting because it is "whitelisted" for the IE protected mode: when IE launches a new verclsid.exe process, the user doesn't have to okay a security warning. Furthermore, verclsid.exe instantiates the COM server associated with the extension of a chosen special folder, providing just the binary planting opportunity we need. In our attack, we trigger the launching of verclsid.exe by loading a number of different special folders in an additional 1x1 iframe while IE has its current working directory set to our remote shared folder. Since verclsid.exe is launched by IE, it also inherits IE's current working directory (which hosts our "malicious" DLL) and eventually loads our DLL. The attack is again hidden with clickjacking.

Let's see how the user experiences this attack. Visiting a malicious web site, right-clicking anywhere on the page and selecting  "send to" and "compressed (zipped) folder" from the context menu is enough to get a remote binary executed on his computer.





Again, the schematic diagram of the attack:

Lessons Learned

The main takeaway from our presentation was that binary planting, as a conceptual problem with loading binaries on Windows, is not at all a trivial problem if you really understand the numerous details and hidden processes that affect and enable it.

By shedding light on a few previously unknown attack vectors we only revealed a small portion of our advanced binary planting research, which is aimed at improving the exploitation of various binary planting vulnerabilities. If we want to convince developers to fix security defects, we need to show them that they're easy to exploit, and we hope to see some proactive effort as a result of our work. And this is by no means aimed towards Microsoft alone; it was simply easiest for us to use the components that come with Windows, but we found a large number of other vendors' product to be exploitable in the ways described above.


How To Protect Yourself?

Apart from our generic recommendations for administrators, a couple of additional temporary measures will protect you from the attacks described in this post (but unfortunately not from numerous similar attacks):

1. On Windows XP, delete the {42071714-76d4-11d1-8b24-00a0c9068ff3} registry key under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID.
2. On Windows 7, copy ehTrace.dll from C:\Windows\ehome to the System32 folder.

What's next?

We'll continue to raise awareness of this vulnerability class we call binary planting. There's a lot of misunderstanding about it among developers as well as security researchers, and we'll do our best to change that. Our first humble milestone is to stop seeing new product versions making unsafe LoadLibrary calls. Unfortunately, we don't seem to be anywhere close to that.


(Again, most of the above research has been done by Luka Treiber, security researcher at ACROS Security.)

"Binary Planting" vs. "DLL Hijacking" vs. "Insecure Library Loading"

Binary Planting's Multiple Identities

When a new thing occurs or is invented, or when a previously obscure thing becomes popular, a need emerges to give it a name so we can talk and write about it. It was no different with binary planting, DLL hijacking, DLL preloading, insecure library loading, DLL load hijacking and DLL spoofing. Except that, unfortunately, these different names all describe essentially the same thing - an attack* against a Windows application where this application loads a malicious executable instead of some intended legitimate one. We get asked a lot why we choose to use the term binary planting, so here's our reasoning.

One major reason for us to dislike words "DLL" or "library" in the name is that this problem affects not only dynamic-link libraries but also other types of executables. Furthermore, "DLL" sounds as if the insecurely loaded library always has a ".dll" extension - which is not the case, as our research has found applications trying to load libraries with extensions ".ocx", ".nls", ".tbp" and many other funny extensions. We chose to use the noun binary, which covers all types of executables involved in these vulnerabilities. So why not simply use executable? Executable is too long a word and would probably quickly be shortened to "EXE," causing a similar misunderstanding we already have with "DLL."

As for other shortcomings of the alternative terms:

• DLL hijacking implies that either a DLL gets hijacked or something gets hijacked using a DLL. But in large majority of binary planting vulnerabilities the binary (for instance, a DLL) in question does not exist - that is, until the attacker plants it. You can't hijack something that doesn't exist. One could say that a vulnerable application gets hijacked through a malicious DLL but then every vulnerability could be called hijacking of some sort. Note, however, that before Windows XP SP2, the dynamic-link libraries search order had the current working directory in the 2nd place, which produced a lot of possibilities to actually hijack an existing DLL (e.g., one from the Windows system folder) by placing a malicious copy with the same name in the current working directory. Back then, hijacking would have sounded more suitable.   
• DLL preloading implies that some presumably malicious DLL gets loaded in advance (of something). We find no such advance-loading process taking place in the context of this vulnerability.
• Insecure (library) loading sounds accurate as long as it's only libraries one considers. When other executables (EXEs or COMs, for example) join the party, loading is not a very suitable term any more. While technically, these also get loaded before they're executed, it's more common - and more understandable - to say they get ran, started, executed or launched.
• DLL load hijacking is a little better than DLL hijacking as it implies that it is the process of loading that gets hijacked (and used for malicious purposes). However, this term contains an unfortunate hard-to-pronounce triple-L, and is likely to quickly (d)evolve into DLL hijacking. And again - just like with insecure library loading -, loading is not a very suitable term for non-library executables (EXEs, COMs, etc.).   
• DLL spoofing is actually a nice term, short and accurate, but has long been widely used for another similar but conceptually very different activity, namely manually replacing an existing DLL on one's own computer in order to change the behavior of an application or operating system. This activity has nothing to do with security, at least not in terms of one person (attacker) doing something bad to another person (user), since the user does it to himself, so to speak.   

We chose the verb planting because, in our opinion, it accurately describes what the attacker needs to do in order to carry out the attack: planting a malicious binary somewhere where a vulnerable application will pick it up and execute it.

So these are our reasons for preferring the term binary planting to other alternatives for describing the entire scope of the problem. As it currently seems, DLL hijacking (for describing an attack) and insecure library loading (for describing a vulnerability) are here to stay as well, at least for libraries. This will certainly continue to cause unneeded confusion but perhaps a vulnerability class that has been overlooked for such a long time deserves more than one name.


(* Strictly speaking, the term insecure library loading does not describe an attack, but a vulnerability.)

Silently Pwning Protected-Mode IE9 and Innocent Windows Applications

Binary Planting Through COM Servers

This blog post sets up the stage for our Hack in the box presentation in Amsterdam on May 19.

[Update: Find the continuation of this blog post here.]

Those familiar with Windows COM servers know that they come in two types, in-process and out-of-process. For this post, the former type is of interest: an in-process COM server is a dynamic link library (DLL) that a COM client instantiates when needed, usually by calling the CoCreateInstance function with the class identifier (CLSID) of the said COM server. What happens then is the COM server initialization code looks up the provided CLSID in local registry under key HKEY_CLASSES_ROOT\CLSID, and finds the path to the DLL under the InProcServer32 subkey. It then expands eventual environment strings in the obtained DLL path and calls LoadLibrary with the resulting path. Whatever happens afterwards is of no interest to us here.

From the binary planting perspective the above process would be vulnerable if both of the following conditions were met:

1. the path to the COM server DLL is a relative path instead of an absolute one; and
2. the DLL doesn't exist in the LoadLibrary search path prior to the current working directory (i.e., in COM client's home directory or any one of the Windows system folders).  

Condition #1 is at the discretion of whoever registers the COM server. While most COM servers are registered with full absolute paths to their DLLs, some merely specify the name of the DLL without the path. This may not be due to a developer's oversight or laziness: the so-called side-by-side COM components (see here and here) require the DLL to be specified with a relative path.

Condition #2 is a bit more tricky as it seems unlikely, at the first glance, that someone - or some application - would register a COM server that doesn't exist on the system. But for reasons beyond our willingness to investigate, some software products do just that. Furthermore, some other software products fail to unregister their COM servers upon removal, leaving the user's computer with exploitable remnants of a removed COM server DLL. And finally, in the case of side-by-side COM components, these DLLs are successfully found and loaded when the COM server is invoked by the original application (the DLL is in the same folder as the COM client executable), but if another applications tries to invoke the same COM server, it won't find the DLL and will finally try to find it in the current working directory - to attacker's great satisfaction.

If you're now asking yourself whether such cases where both conditions are met actually exist: we did a quick search on our testing systems and found a few, one of them being preinstalled, so to speak, on every Windows XP machine, and others being introduced by various software products. Let's take a look at the "preinstalled" XP case.


The "preinstalled" XP binary planting vulnerability

On every Windows XP machine, there exists an in-process COM server named "Display Panning CPL Extension" with CLSID {42071714-76d4-11d1-8b24-00a0c9068ff3}. Truth be told, we don't know what its purpose is, and neither does the searchable Internet, but the DLL it specifies under the InProcServer32 subkey is "deskpan.dll". This is a relative path to a DLL that doesn't seem to exist on any XP system, and thus meets both of the above conditions.

Therefore, if any Windows process tries to create an instance of this COM server for whatever reason, and the current working directory of that process is set to an attacker-controlled location (possibly on a remote share), the attacker can plant a malicious deskpan.dll and have the said process load and execute it on user's computer.

Windows 7, Vista, and well-registered COM servers

Naturally, such attack also works on Windows 7 and Windows Vista as well as older Windows systems, as long as some registered COM server fulfills the above conditions. But it does, as usually, get even worse: we found that many well-registered COM servers on all Windows versions, having specified their DLL with an absolute path, load additional DLLs with a relative path, and many of these DLLs do not exist. This provides extensive binary planting potential to a great number of flawed LoadLibrary calls that could previously be considered non-exploitable. Yes, on all fully up-to-date Windows versions without any additional software installed.

The questions that now remain unanswered are:

1. how to get some Windows process on user's computer to try to initialize a chosen vulnerable COM server; and
2. how to get the current working directory of that process to point to the attacker's remote share?  

At the Hack in the box conference in Amsterdam on May 19, we will answer these questions by demonstrating two of our previously unpublished hacks:


Demo #1: Exploiting innocent Windows applications

First we will demonstrate how various applications on your Windows 7, Vista or XP can be forced to initialize any vulnerable COM server, and load a malicious DLL in the process. We'll show how Microsoft Word 2010 and PowerPoint 2010 execute a malicious DLL upon opening a document on Windows 7 (something that doesn't occur under normal circumstances), even in "protected view."  


Demo #2: Pwning protected-mode IE9 without warnings

And as if that weren't enough, we will show how this technique can be leveraged to launch a binary planting attack against Internet Explorers 8 on Windows XP as well as against Internet Explorer 9 in protected mode on Windows 7 - without any suspicious double-clicks or security warnings. (For the impatient: it's not through ActiveX controls.)

We look forward to seeing you in the audience and sharing our research with you. Of course we will also tell you how to avoid introducing described vulnerabilities in your own software creations and how to protect your web browsing experience from the perils of binary planting. In the mean time, we've updated our Binary Planting Guidelines For Developers accordingly.

(Credit for the above research goes mostly to Luka Treiber, security researcher at ACROS Security.)

Microsoft Patches Binary Planting Issues In Various Vendors' Products

That is, after making them vulnerable in the first place

Last October our company reported that Microsoft Visual Studio 2010 and 2008 (we didn't test 2005) injected an easily exploitable binary planting vulnerability into every MFC (Microsoft Foundation Class) application built with these development environments - and also into any other application using the Visual C++ redistributable libraries. The number of affected applications was, and still is, potentially pretty high: out of just over 200 applications we tested in our binary planting research project, thirteen (~ 6%) were found to be suffering from this flaw (some of them also had, or still have, other binary planting issues).

These are the "dirty thirteen" we found, although keep in mind that the "dirty" part is not their developers' fault. Also note that while some of these products may have had subsequent updates and versions, these are likely to be vulnerable as well unless they were substantially re-coded as non-MFC applications.

1. Autodesk 3ds Max 2010 Release 12.0
2. Autodesk 3ds Max 2011 Release 13.0
3. Avast! Free Antivirus 5.0.545
4. Avira Premium Security Suite 10.0.0.542
5. BitDefender Total Security 2010 - Build 13.0.17.343
6. CorelDraw X5 15.1.0.588
7. Corel Paint Shop Pro Photo X3 13.2.0.41
8. CyberLink PowerDirector 8.00.2220
9. EMC QuickScan Pro Demo 4.7.0 (build 8554)
10. EMC ApplicationXtender Document Manager v6.50.124.0
11. Microsoft Office Professional 2010 14.0.4760.1000 (32-bit)
12. Nuance PDF Converter Professional 6.0
13. PC Security Shield Security Shield 2010 13.0.16.313

This week Microsoft finally fixed this bug in Visual C++ redistributable packages (apparently, version 2005 was vulnerable too). Now, does this fix magically make things right for end-users? Not entirely. If you're using a vulnerable product that dynamically loads the Visual C++ redistributable package, installing the correct security update(s) will resolve the problem and remove the vulnerability. All of the above listed applications will, for example, be fixed. However, MFC applications that statically link the MFC libraries effectively integrate these in their executables and do not use the (now fixed) redistributable libraries. Such applications will have to be re-built in (updated) Visual Studio and redistributed to end-users.

Recommendations

• Users should apply the security updates for Visual C++ redistributable packages
• Visual Studio Developers should apply the applicable security updates and re-build MFC applications that statically link MFC libraries (and obviously, distribute the new build to end users).

Updated Online Binary Planting Exposure Test

Yesterday Microsoft issued a security update for the Windows Address Book binary planting vulnerability, which was used in our Online Binary Planting Exposure Test. Since the launch of this online test, thousands of Windows users worldwide used it to check their exposure to Internet-based binary planting attacks, and we're happy to see people using it for testing their countermeasures.

Obviously, Microsoft's security update broke our online test. While it could still be used for verifying the effectiveness of this particular Microsoft's update, it could no longer serve its original purpose.

We thus extended our online test with two additional unfixed vulnerabilities, one for Windows XP and one for Windows Vista and Windows 7, which allow users to continue testing their computers for exposure to Internet-based binary planting attacks.

For Windows XP, we chose a publicly disclosed binary planting vulnerability in Program Manager Group Converter. Similarly to the now fixed Windows Address Book vulnerability, this one is triggered by double-clicking on a GRP file.

For Windows Vista and Windows 7, our online test exploits a binary planting vulnerability in Windows Media Player 11 and 12, triggered by opening an MPG file. Its exploitability in a real-world attack is limited: Windows Media Player correctly sets its current working directory to a safe location upon startup, therefore simply double-clicking an MPG file in Windows Explorer will not load the malicious DLL from the attacker's location. It is perfect for our test though, as all Windows Vista and Windows 7 systems have Windows Media Player installed, and our tests are not exploit demonstrations but rather a tool for determining one's exposure to a particular type of attack.

We welcome everyone to use our free online test for both verifying the effectiveness of Microsoft's security update and for determining whether it is possible for an external attacker to exploit binary planting vulnerabilities on your computers. Do the Online Binary Planting Exposure Test now!

The Unbearable Lightness Of Non-Fixing

A Short Study on Security Reactiveness And Proactiveness

Exactly 97 days after a new old vulnerability type called Binary Planting, DLL Hijacking, DLL Preloading and Insecure Library Loading has gained public attention, it is clear that:

1. These bugs are ubiquitous and can be found in many widely-used as well as less known applications;
2. Not just DLL loading, but also EXE loading is affected;
3. Remote exploitation of these bugs is not just possible but possible in a wide variety of ways, also from Internet servers directly to internal corporate networks (Stuxnet, for instance, uses binary planting); and finally:
4. Few vendors seem to care much about fixing these remote-execution bugs.

Let us substantiate the last claim and provide some thoughts about possible reasons for this situation.

We have two different sources of information on existing binary planting bugs and their status. The first source are published full-disclosure reports provided by many researchers. We chose Secunia's list of verified advisories as a representative sample of publicly known binary planting bugs, although many researchers worldwide are doing a great job in finding these bugs. The second source is our own private list of publicly unknown binary planting vulnerabilities, which we've built throughout our Binary Planting Research Project. We're only using a subset of the vulnerabilities we found in this project: we re-tested some of the most widely-used products and omitted bugs subsequently found by others and publicly disclosed.

These two sources are both fairly large (compared to other similar sources), both verified and both providing vulnerabilities of the same type. The only important difference between them is that one provides publicly known vulnerabilities and the other vulnerabilities unknown to the public. This gives us a unique opportunity to get a peek into the - otherwise inaccessible - world of unknown vulnerabilities.



Status of PUBLICLY KNOWN binary planting vulnerabilities

	Total	Unfixed	Fixed	Percent Fixed
DLL Planting bugs	151	128	23	15%
EXE Planting bugs	8	1	7	88%
DLL+EXE Planting bugs	159	129	30	19%

The above table shows the status of those binary planting vulnerabilities that have been fully disclosed to public. Note that the amount of time elapsed since their disclosure is not taken into account; however, majority of these bugs have been disclosed at least 2 months ago. We assume (i.e., hope) that most affected applications' vendors are aware of the published vulnerabilities.

Out of 159 vulnerabilities verified by Secunia, 19% have been fixed so far. Interestingly, after some web browser vendors' initial quick response (Firefox, Opera, Safari), most of the fixes were done by smaller vendors, perhaps predominantly in open-source software. In general, large vendors seem to be very slow in patching - which is often rationalized by extensive testing they need to perform, but may also be due to their business models not providing sufficient rewards for security fixing. An unfixed known vulnerability in Windows Address Book, for instance, can still be used for testing your exposure to binary planting.

Status of PUBLICLY UNKNOWN binary planting vulnerabilities

	Total	Unfixed	Fixed	Percent Fixed
DLL Planting bugs	66	62	4	6%
EXE Planting bugs	28	28	0	0%
DLL+EXE Planting bugs	94	90	4	4%

The above table shows the status of binary planting vulnerabilities that have not been disclosed to public; these bugs have been discovered between December 2008 and July 2010 (but only a subset is being used here). It is unknown whether the affected applications' authors are aware of these vulnerabilities or not.

Unsurprisingly, very few of the publicly unknown vulnerabilities have been fixed, and of those 4 that have been, the affected products have mostly changed their design and appearance substantially, which might have led to accidental (as opposed to intentional) fixing.


Conclusions

What can we conclude from this? First, the status of publicly known binary planting bugs shows that vendors are slow at fixing these bugs even though their existence is obviously accessible to their customers, and also available to those who might want to attack the said customers. In a profoundly unscientific way we could say that today's software vendors' security reactiveness runs at 19%. If we ever hope to have our increasingly critical computer systems decently secure, vendors should strive to reach a 100% rate of prompt reaction to known vulnerabilities. Fixing a remotely exploitable critical bug in a few days should then be a norm, not an exception.

Second, the status of publicly unknown binary planting bugs provides a rare insight into software vendors' proactiveness when it comes to security. Remember that binary planting vulnerabilities have been all over the media for over three months, analyzed on many blogs and discussed in length on numerous web sites and forums. It is hard to imagine that a software vendor actually proactive in security (never mind what their marketing material says) could miss all this. And a proactive vendor would at least fire up Process Monitor and take a look at how their applications load libraries and launch executables. Accounting for the likelihood that the four fixed unpublished bugs were fixed by accident, we could say that software vendors' security proactiveness, as far as binary planting bugs go, runs near zero.

Finally, there's no reason to believe that binary planting bugs are getting treated any differently from other types of vulnerabilities. Similar results would probably be obtained from any sufficiently long lists of known and unknown vulnerabilities. Assuming that software vendors are behaving rationally and optimally with respect to their business objectives, the security of tomorrow's systems will require some adjustments to their business models. Bug bounties, recently offered by Mozilla, Google and some other vendors, just might be a step in the right (i.e., proactive) direction.

Analysis Of The Microsoft Office 2010 Binary Planting Bugs

Keeping binary planting bugs out of 120 million lines of code

In the course of the ongoing binary planting research, our company has discovered five binary planting bugs in Microsoft Office 2010: two in Word 2010, one in PowerPoint 2010 and one in Excel 2010. We notified Microsoft about the PowerPoint bug on July 20th (about 110 days ago), but subsequently this bug was also found and published by other researchers.

Yesterday Microsoft released security updates for Microsoft Office 2010 (here, here) resolving this issue. They acknowledged our researcher for the find, and, not unimportantly, seemed to have upgraded the severity rating to "critical" (from their original assessment of binary planting bugs as "important"). In light of our current research, where we're already able to exploit binary planting bugs with as little user assistance as visiting a web page and clicking twice in arbitrary locations, the highest severity rating would be quite appropriate.

Microsoft didn't just fix the PowerPoint binary planting bug we reported; they also fixed two other binary planting issues we knew about in Word 2010 and Excel 2010 (although you won't find these mentioned in their bulletin). Since these are the first binary planting bugs fixed by Microsoft, they deserve a bit of attention. Let's start with some technical details:

The three binary planting issues all had a common source: the library called mso.dll (installed in %ProgramFiles%\Common Files\Microsoft Shared\office14\). This library made an unsafe call to LoadLibrary("pptimpconv.dll") in PowerPoint, LoadLibrary("wdimpconv.dll") in Word and LoadLibrary("xlimpconv.dll") in Excel. These DLLs, however, did not exist on Windows computers, and were thus loaded from the current working directory. The exploitation of such bugs is simple: place an Office file alongside a malicious DLL with the right name somewhere where the user will be able to access it (e.g., DVD, USB key, local drive, local share or remote WebDAV share), and get the user to open the document. For the PowerPoint bug this was it; for Word and Excel however, the Office Protected View, if it decided to kick in, actually provided an additional layer of security as these DLLs were only loaded if the user decided to enable editing by clicking the button in the message bar.

For all three bugs, it was a case of a "classic" binary planting error of a most common type: trying to load a DLL to see if it's there. Google search seems to find nothing about these DLLs outside the binary planting context, so we conclude that this was likely a case of "forward compatibility," i.e., Office applications trying to load DLLs that were planned to be placed on the computer at some point in the future.

Yesterday's security update fixes these bugs such that the non-existing libraries are not being loaded any more.

From the development perspective, one might wonder how difficult it is for a vendor to find all binary planting issues in their own code, or, better yet, to prevent them from being introduced in the first place. It seems really easy: search the entire source code for LoadLibrary calls and make sure they all provide a full path to the DLL, or that the DLLs they load are sure to be found in the application folder or one of the system folders.

But it isn't easy. The millions of lines of Office code probably contain tens of thousands of LoadLibrary calls, many of which don't use string literals for DLL names but some input passed by a calling function. Furthermore, many of these calls, even if potentially vulnerable, may not be exploitable (so it wouldn't make economic sense to invest into additional coding and testing), but it can also be very time-consuming to determine which are exploitable and which aren't. No vendor will invest a lot of effort into something that may not even be a problem.

And it's not just LoadLibrary calls: all functions/methods in all languages (including macros, VBScripts, JScripts and shell scripts) that load libraries or launch executables can be a source of binary planting bugs.

The mighty proactive SDL (secure development lifecycle) apparently doesn't help much either, or there wouldn't be so many binary planting bugs in so many products by so many vendors practicing it. Training developers in secure coding sounds nice, and it surely contributes to the security of software products, but if it fails to eliminate trivial bugs like binary planting (and buffer overflows, and cross-site scripting, and what-not-injections), perhaps it is time to rethink the priorities.

With today's complex software products, security requires more control. Much more control. Even if developed by super-trained security paranoids, applications need more external security testing, more hacking from different directions, more proactive "attacks" by people with different experiences and knowledge. All that before they get installed on users' computers, if we want to call our approach to security "proactive" in any meaningful way.

P.S.: As for the two aforementioned unfixed binary planting bugs in Office 2010 and further news on binary planting, follow our research on Twitter.

Breaking The SetDllDirectory Protection Against Binary Planting

The curious case of Windows environment variables or how to re-hack fixed iTunes and Safari

If you're a Windows developer trying to protect your applications from binary planting attacks, you have probably heard of the SetDllDirectory function. This function removes the current working directory from the search path when  loading DLLs and allows you to replace it with a (hopefully safe) location you specify.

For instance, the DLL search order after calling SetDllDirectory("C:\SafePath\") becomes:

1. The directory from which the application loaded
2. C:\SafePath\ 
3. 32-bit System directory (Windows\System32)
4. 16-bit System directory (Windows\System)
5. Windows directory (Windows)
6. Directories in the PATH environment variable

When providing an empty string to SetDllDirectory, the current working directory is simply removed from the DLL search order:

1. The directory from which the application loaded
2. 32-bit System directory (Windows\System32)
3. 16-bit System directory (Windows\System)
4. Windows directory (Windows)
5. Directories in the PATH environment variable

In theory, calling SetDllDirectory at the beginning of your code should solve the binary planting problem at least as far as loading DLLs go (reminder: EXEs are also affected). The concept sounds good and it is in fact one of the recommendations in our developer guidelines for preventing binary planting vulnerabilities.

In practice though, DLL-based binary planting attacks may still be possible. How? Enter the world of unexpanded environment variables, a known Windows bug that goes a long way in helping binary planting attackers.

Our researchers have (re)discovered a curious fact that some Windows environment variables sometimes don't get expanded in the PATH. For example, the CommonProgramFiles environment variable, which typically expands to "C:\Program Files\Common Files", sometimes simply remains %CommonProgramFiles% in the PATH. This bug affects many other environment variables on all Windows platforms and has not only been publicly discussed before since 2003 (see here, here, here, here and here) but Microsoft has also issued a KB article on the subject 3 years ago. The bug, however, was never fixed.

Now what does this mean for binary planting? Suppose an application calls SetDllDirectory to protect itself against DLL planting attacks. Obviously, the current working directory is no longer in its library search path - but the PATH still is! And if any one of the environment variables in the PATH remains unexpanded, well..., it becomes a relative path. That is, relative to the current working directory. For instance, if the PATH looks like this:

PATH=C:\Program Files\Java\jdk1.6.0_21\bin;
%CommonProgramFiles%\Microsoft Shared\Windows Live;
%SystemRoot%\system32;%SystemRoot%;
%SystemRoot%\System32\Wbem;
C:\Program Files\QuickTime\QTSystem\

and the CommonProgramFiles variable doesn't get expanded, the actual PATH included in the search path will contain the loaction

%CommonProgramFiles%\Microsoft Shared\Windows Live

In case the DLL hasn't been found in preceding locations in the search path, the application will at this point try to load it from a subdirectory of the current working directory, specifically from

CWD\%CommonProgramFiles%\Microsoft Shared\Windows Live

For illustration purposes let's take Apple's latest iTunes and Safari as examples (remember that their DLL and EXE planting bugs have already been fixed). These applications both call SetDllDirectory at the beginning of their execution, which is a secure coding practice that we recommend. Now let's assume you also have ActivePython installed. ActivePython adds %APPDATA%\Python\Scripts to the system PATH. There is nothing wrong with this! What is wrong is that APPDATA, due to the Windows bug described above, often remains unexpanded in PATH, which effectively makes iTunes, Safari and countless other applications vulnerable to binary planting attacks.

Let's see this in action.




Again, this is not Apple's fault (although they could improve their code by specifying full paths to their libraries) and it's certainly not ActivePython's fault (PATH is meant to be used this way).

Besides, it's not just the APPDATA variable that helps attackers in this way. Our Online binary planting exposure test's logs show Windows machines trying to load DLLs from various unexpected paths, including:

• %APPDATA%/Python/Scripts
• %ProgramFiles(x86)%
• %CommonProgramFiles%/Microsoft Shared/Windows Live
• %PROGRAMFILES(x86)%/Common Files/Microsoft Shared/Ink
• %USERPROFILE%/Local Settings/Temp
• %systemroot%/system32/DATA/Config
• %NpmLib%

What can we learn from this all? Mostly, don't just depend on SetDllDirectory to solve your DLL-planting problems. Use absolute, fully qualified paths to DLLs when loading them. Until Microsoft fixes this bug, any application that sets user or system PATH can unwittingly make your application vulnerable to binary planting if you're loading libraries from relative paths. And even then, some particularly adventurous application might add a relative location to PATH for whatever peculiar purpose, and break the SetDllDirectory  protection for the entire system. Again, use absolute paths to DLLs!

Finally, it needs to be said that this bug fortunately doesn't hinder the effectiveness of Microsoft's CWDIllegalInDllSearch hotfix. This hotfix successfully blocks DLL loads from the current working directory if configured properly even if relative locations are found in the PATH (it does nothing to prevent EXE planting attacks though).


Unexpanded variables bug analysis

For those interested in more information about the curious behavior of this Windows bug, here are some of our most important observations. We were testing on Windows XP Professional 32 bit, Windows Vista Business 32 and 64 bit and Windows 7 Professional 32 bit.

1.  We noticed that the "expandability" of certain environment variables sometimes changes by logging off or restarting the computer. For instance, APPDATA in the user PATH is initially unexpanded on Windows 7, but gets expanded after logoff or restart. On Windows XP, however, logoff makes this variable "expandable," but restarting the machine again makes it "nonexpandable".
2. Windows Vista 64 bit never expanded APPDATA in the user PATH, whatever we tried.
3. While Windows XP expanded APPDATA in system PATH at least after logoff, Windows Vista and Windows 7 never expanded APPDATA in system PATH.
4. COMMONPROGRAMFILES is never expanded in system PATH upon initial setting, and while other systems resolve this after logoff or restart, Windows Vista 64 bit never seems to expands this variable, period.
5. The same goes for PROGRAMFILES, which is a very common variable to use.

Many other environment variables are affected, making it relatively likely that the SetDllDirectory protection against binary planting will not be efficient on computers with multiple software products installed (which might add locations to user or system PATHs).