JAVA 0 day vulnerability explained..

One of the recent threat in java is founded , with which attacker can spread malware and various other infected files which effect  users system without users having to open any files. The hackers called this new exploit as a “New Year’s gift”. The exploit code looks like java code with no trace of any exotic bytecode.

 After searching  different website on this vulnerability,,,,,,i have obtained following output which is not covered in single website.

The exploit takes advantage of two security flaws:

1. The first flaw stems from the fact that it is possible to obtain references to restricted classes.
2. The second one allows it to invoke class constructors by using the reflection API included in Java 1.7.

Following is the exploit code..

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

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.