See Full Disclosure post Java Deployment Toolkit Performs Insufficient Validation of Parameters.
What’s the threat? Malicious web site can run code in the context of the user. The code may already exist on the destination machine or be distributed through a jar file. The following example executes Calc on a Windows machine:
Ruben at ReverseMode.com illustrates how parameters are validated and shows that a similar exploit should be available for Linux environments as well.
How do you mitigate this vulnerability? Approaches suggested have included “set the kill bit,” “block access to npdeploytk.dll” and “block access to javaws.exe”. The indicated ActiveX control does not exist, so its kill bit has not been set. Setting a kill bit may help with Internet Explorer, but does not help Windows users running Firefox. Removing the npdeploytk.dll files (from C:\Program Files\Java\jre6\bin\new_plugin and C:\Program Files\Java\jre6\bin) does not mitigate the vulnerability. Denying access to or removing javaws.exe will break production applications which require it.
I would also suggest “update your antivirus software.” Eset NOD32 with pattern 5026 (20100413) detects uses of this specific pattern as JS/Exploit.JavaDepKit.A.
April 21, 2010: Firefox blocked Java Deployment Toolkit versions 188.8.131.52 and older. See the current list of blocked applications at https://www.mozilla.com/en-US/blocklist/ and the explanation of this specific blocklist entry at https://bugzilla.mozilla.org/show_bug.cgi?id=558584
Sun (Oracle) released JDK 6 Update 20
Reminder: Upgrading Java leaves the old version installed. The new version becomes the default version and the old version can be used if the application requests it explicitly. This enables graceful migrations to to new Java versions while old version dependencies are resolved. This also means that old versions, old vulnerable versions, should be uninstalled if they are not required.