Slow, But Moving In The Right Direction
Since our presentation of COM server-based binary planting exploits at the Hack in the Box conference in May this year, Microsoft has introduced a number of relevant changes to Windows and Internet Explorer. To refresh our memory: in Windows, so-called "special folders" (e.g., Control Panel or My Computer) are implemented as in-process COM servers associated with unique CLSIDs and our researchers found that opening a file from an ordinary folder with name extension equal to some of these CLSIDs results in various DLLs being loaded and executed from this same folder. This has obvious security implications (details here and here) and our advanced binary planting research leveraged it to the point where it was possible to attack a user through Internet Explorer on both Windows XP and Windows 7.
Change #1: No "file://" Inside "http://"
The proof of concept we prepared was a web page that included a tiny (1 by 1 pixel) iframe hosting the content of a remote shared folder; when the user clicked anywhere on that page, he actually clicked inside the shared folder where the first click selected a file there, and the second one initiated the printing which triggered the binary planting bug.
Microsoft changed the behavior of Internet Explorer such that a web page (served via http://) can't display the content of a shared folder (served via file://) in a frame/iframe. This is good: there are probably very few cases where such mixture would be legitimately needed. And if you have a case like that, you can always put your web page in the "Trusted sites" zone.
Naturally this broke our proof of concept as we delivered it via http:// from http://www.binaryplanting.com/demo/XP_2-click/test.html. However it is not difficult to circumvent this limitation: if the main web page is loaded via file:// as well, it will be allowed to display a remote share in a frame/iframe, at least if it's coming from the same server. Therefore our proof of concept could be brought back to life simply by having it loaded via file:// from file://\\www.binaryplanting.com\demo\XP_2-click\test.html.
Change #2: No "file://" From "http://"
If you're reading this in Internet Explorer and try to click on the file:// link at the end of the last paragraph, you will probably notice that it doesn't work. This was the second change introduced to Internet Explorer, and again a good one. An obvious attack vector for the typical double-click binary planting attacks is a link on a web page that opens up Windows Explorer with attacker's remote shared folder. Since most users would not be able to distinguish between the displayed "malicious" folder and a shared folder in their internal network, they could easily open a document in it - and get their computer owned.
Not allowing a web page loaded via http:// to open a file:// URL blocks this attack vector and this is good. Since other leading web browsers don't launch file:// URLs in Windows Explorer, the attacker is now left with secondary attack vectors such as e-mail, various documents and instant messages. (Unless he finds a way to circumvent this new IE barrier.)
Change #3: Away With deskpan.dll On Windows XP
The September Windows update MS11-071 introduced a number of changes, but the one most relevant to this post is the removal of a non-functional COM server on Windows XP registered with a non-existing DLL called deskpan.dll, which was used in our proof of concept. Esteemed paranoid readers of our blog have manually removed this COM server 100+ days earlier when we recommended it in May (see "How to protect yourself" section). We welcome Microsoft's move to fix this exploitable configuration error as part of a security update.
However...
As we already hinted before, 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.
For instance, an attacker - having had the deskpan.dll COM server taken away from him - can migrate his Windows XP exploit to the COM server with CLSID {32714800-2E5F-11d0-8B85-00AA0044F941}. This COM server loads C:\Program Files\Outlook Express\wabfind.dll (which exists) but then this DLL tries to load wab32res.dll without a full path. While wab32res.dll does exist in C:\Program Files\Common Files\System\, this folder comes after the current working directory in the search order - allowing a fake wab32res.dll to be loaded and executed from the attacker's "special" folder.
Furthermore, our research found that there are at least ten additional vulnerable COM servers on a default Windows XP installation.
Finally, the COM server-based binary planting vulnerability we described on Windows 7 has not been fixed yet. The "AnalogCable Class" COM server, registered with CLSID {2E095DD0-AF56-47E4-A099-EAC038DECC24}, still loads and executes ehTrace.dll from attacker's folder.
Conclusion
Microsoft is clearly putting an effort into removing binary planting bugs from their code and introducing mitigations that help block various binary planting attack vectors. While we know there's still a lot of cleaning up to do in their binary planting closet, our research-oriented minds remain challenged to find new ways of exploiting these critical bugs and bypassing new and old countermeasures. In the end, it was our research that got the ball rolling and it would be a missed opportunity for everyone's security if we didn't leverage the current momentum and keep researching.
Stay tuned - follow our research on Twitter.
Thursday, September 15, 2011
Friday, July 8, 2011
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:
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.)
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:
- .hotspotrc : a Java configuration file with a single line OnOutOfMemoryError="malicious.exe"
- Test.class : a Java applet that consumes all available memory (ours simply concatenates a string to itself many many times)
- Test.html : an HTML document that loads the applet
- 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:
- 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.)
- Safari loads and renders Test.html from our directory.
- Test.html invokes a Java applet called Test.class, triggering the initialization of the Java virtual machine.
- 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.
- jvm.dll loads the Java applet Test.class from our directory and executes it inside the Safari process, causing an OutOfMemoryError error within seconds.
- 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.)
Subscribe to:
Posts (Atom)
Posts
