David Baxter PhD
Late Founder
Java: A Fix it for when you cannot let go
Microsoft TechNet Blogs, Security Research & Defense
29 May 2013
There is much to say about the use of Java in both consumer and enterprise environments. Like any other platforms, it has both devoted supporters and fervent critics. But for most, Java is a requirement, a means to an end.
In the past few years, Java as a platform has been the target of numerous malware attacks, which exploit a number of Java runtime vulnerabilities on the target machines. The rise in Java exploitation has been attributed largely to unpatched software, although 0-day issues do creep in occasionally.
Fortunately, there are steps that can be taken to mitigate some of these issues. Oracle is providing a series of measures to prevent unauthorized Java Applets and Web Start Applications from running by requiring them to be signed with a trusted certificate. This is a great start. However, not everybody runs an up-to-date version of Java runtime. For a long time, Java updates used to install side-by-side with older versions. That?s no longer the case, but the problem of unpatched software persists. In addition, there are legacy apps that require an older platform to run.
What can be done about this? If you need to run Java inside a browser, not much -- keep your software up to date and visit only trusted websites. If you only care about running Java desktop apps, there are a few mitigation steps that allow the customer to disable Java support inside your browser, leaving desktop functionality intact. These steps will remove a prevalent remote exploit vector, but at the same time keep Java installed for local applications. This subject has been covered elsewhere; for instance, here.
Our customers tell us that the most effective mitigation tactics are both complete (covering all software versions, past and current) and friendly to enterprises, which face complex deployment issues. In order to address these concerns, we have issued an update to KB2751647 ? How to disable Java web plugin in Internet Explorer. We are making available a ?Microsoft Fix it? solution to block all Java web-attack vectors through Internet Explorer. The solution will work for all versions of Java (tested 5 and above) and all supported versions of Internet Explorer (32-bit or 64-bit):
The Fix it solution consists of two parts. The first makes use of Windows Application Compatibility Toolkit, changing the behavior of Internet Explorer at runtime so that it will prevent the load of Oracle?s Java Web plugins. This is achieved by hooking all LoadLibrary* functions so that they return NULL (last error ERROR_FILE_NOT_FOUND) when attempting to load all Java ActiveX dlls (npjpi*.dll, jp2iexp.dll). The second part prevents Internet Explorer from automatically opening JNLP files. It does this by clearing the ACL (access control list) of the JNLP protocol handler registry location (HKCR\JNLPFile), thus preventing all user apps from reading its contents.
This solution covers current and past versions of Java, as well as foreseeable future versions. It does not interfere with Java?s update mechanism either. In fact, the Fix it works as expected even if installed prior to any installation of Java. It can also be easily deployed making use of the non-interactive options of msiexec.
Microsoft TechNet Blogs, Security Research & Defense
29 May 2013
There is much to say about the use of Java in both consumer and enterprise environments. Like any other platforms, it has both devoted supporters and fervent critics. But for most, Java is a requirement, a means to an end.
In the past few years, Java as a platform has been the target of numerous malware attacks, which exploit a number of Java runtime vulnerabilities on the target machines. The rise in Java exploitation has been attributed largely to unpatched software, although 0-day issues do creep in occasionally.
Fortunately, there are steps that can be taken to mitigate some of these issues. Oracle is providing a series of measures to prevent unauthorized Java Applets and Web Start Applications from running by requiring them to be signed with a trusted certificate. This is a great start. However, not everybody runs an up-to-date version of Java runtime. For a long time, Java updates used to install side-by-side with older versions. That?s no longer the case, but the problem of unpatched software persists. In addition, there are legacy apps that require an older platform to run.
What can be done about this? If you need to run Java inside a browser, not much -- keep your software up to date and visit only trusted websites. If you only care about running Java desktop apps, there are a few mitigation steps that allow the customer to disable Java support inside your browser, leaving desktop functionality intact. These steps will remove a prevalent remote exploit vector, but at the same time keep Java installed for local applications. This subject has been covered elsewhere; for instance, here.
Our customers tell us that the most effective mitigation tactics are both complete (covering all software versions, past and current) and friendly to enterprises, which face complex deployment issues. In order to address these concerns, we have issued an update to KB2751647 ? How to disable Java web plugin in Internet Explorer. We are making available a ?Microsoft Fix it? solution to block all Java web-attack vectors through Internet Explorer. The solution will work for all versions of Java (tested 5 and above) and all supported versions of Internet Explorer (32-bit or 64-bit):
| Apply Fix it | Uninstall Fix it |
The Fix it solution consists of two parts. The first makes use of Windows Application Compatibility Toolkit, changing the behavior of Internet Explorer at runtime so that it will prevent the load of Oracle?s Java Web plugins. This is achieved by hooking all LoadLibrary* functions so that they return NULL (last error ERROR_FILE_NOT_FOUND) when attempting to load all Java ActiveX dlls (npjpi*.dll, jp2iexp.dll). The second part prevents Internet Explorer from automatically opening JNLP files. It does this by clearing the ACL (access control list) of the JNLP protocol handler registry location (HKCR\JNLPFile), thus preventing all user apps from reading its contents.
This solution covers current and past versions of Java, as well as foreseeable future versions. It does not interfere with Java?s update mechanism either. In fact, the Fix it works as expected even if installed prior to any installation of Java. It can also be easily deployed making use of the non-interactive options of msiexec.
