A new Java 0-day is running rampant around the internet this week. With a code paste Sunday night and a Metasploit module coming in early yesterday morning, along with myriad research and blog posts, this Java vuln is sure to be the topic of the week. Based on information in the pastie link and the usage of the Gondzz and Gondvv class files in the alienvault blog post, plus analysis we've done on the samples we've seen in the wild, we've deduced that the exploit runs as follows:

-Use the Statement() method to set up a new SecurityManager.
-Create an object with the following attributes:
    a. Permissions object with AllPermissions() set.
    b. A ProtectionDomain for the url, using local file "file:///"
    c. Set up an AccessControlContext for that ProtectionDomain
-Call to the user defined function SetField with string "acc", passing along localStatement to complete the object.
-Inside that function we set an Expression with getField and use the variables passed in. Additionally we make a call to another user defined function, GetClass.
-In GetClass we finish setting up the object with a last Expression passed in with string forName (for acc, an AccessControlContext field) in the class sun.awt.SunToolkit. What this does is replaces the default value for the AccessControlContext object with the one for acc.
-Once the function has returned we run .execute() on the Expression objects.
-At the top level we execute the now fully populated Statement and presumably have full local execution access.

In each case of Statement or Expression, there is a call to var.execute() which takes the statement that has been created as a string and executes it as code. There are two specific access violations that occur during the execution of the code:
-Accessing the "acc" field using Class.forName.
-Using getField on sun.awt.SunToolit, a restricted package.

By using Statement and Expression methods to make these calls, they bypass access violation checks. Once the code has created a file with admin rights on the system, it can call calc.exe like in the POC or download a trojan like the exploit in the wild does.

The scariest part about all of this is that the next scheduled Oracle patch release is October 16. As Oracle has a policy of not issuing out-of-band updates, this means nearly two months of time where attackers can exploit this without root mitigation by the vendor. In the interim, security researcher Michael Schierl has released an unofficial patch, which is for now only available by request.

In the interim, we've released SIDs  24020 to 24028 and 24036 to 24038 to cover this in Snort, and JAVA.Exploit.Agent JAVA.Exploit.Agent-1JAVA.Exploit.Agent-2 WIN.Trojan.Agent-131 on the ClamAV side. We'd urge you to add these to your setup as soon as possible (especially since the authors of the Blackhole exploit kit are incorporating this vulnerability already), and to consider disabling Java in whatever browsers you can.

[Ed.: Oracle released a patch to address this issue on August 30. While done without much explanation or fanfare, well-done to the security folks at Oracle for getting on top of this issue so quickly.]