New bug/exploit for javaws
Last Updated: 2010-04-14 20:34:06 UTC
by Andre Ludwig (Version: 1)
Update: It didn't take long. This vulnerability is now used in the wild. For details, see http://krebsonsecurity.com/2010/04/unpatched-java-exploit-spotted-in-the-wild/
It looks like Tavis Ormandy posted an interesting "bug" in javaws application to Full Disclosure yesterday. I have yet to verify all the details, but if what Tavis posted is true it opens up a rather interesting scenario for an attacker. (one which Tavis in his PoC code outlines rather well!) We will try and update this post as more information is discovered. I have been talking to a few other security researchers who have verified his claims, i have yet to successfully verify his PoC on any of my vms. (might be version issues)
Tavis's post (full information here)
Tavis also did an excellent job in not only formatting of his alert, but also in the content (again, i have yet to verify all this my self!). The below is a snippet of the mitigation portion of his alert.
------------------- Mitigation ----------------------- If you believe your users may be affected, you should consider applying one of the workarounds described below as a matter of urgency. - Internet Explorer users can be protected by temporarily setting the killbit on CAFEEFAC-DEC7-0000-0000-ABCDEFFEDCBA. To the best of my knowledge, the deployment toolkit is not in widespread usage and is unlikely to impact end users. - Mozilla Firefox and other NPAPI based browser users can be protected using File System ACLs to prevent access to npdeploytk.dll. These ACLs can also be managed via GPO. Detailed documentation on killbits is provided by Microsoft here http://support.microsoft.com/kb/240797 Domain administrators can deploy killbits and File System ACLs using GPOs, for more information on Group Policy, see Microsoft's Group Policy site, here http://technet.microsoft.com/en-us/windowsserver/bb310732.aspx You may be tempted to kill the HKLM...JNLPFileShellOpenCommand key, but the author does not believe this is sufficient, as the plugin also provides enough functionality to install and downgrade JRE installations without prompting (seriously). However, if none of your affected users are local Administrators, this solution may work (untested). As always, if you do not require this feature, consider permanently disabling it in order to reduce attack surface.
File System ACLs to prevent access to npdeploytk.dll."
Why not just disable the Java Deployment Toolkit plugin and move on? I've had the WPF plugin disabled since Mozilla black-flagged it months ago.
Apr 11th 2010
1 decade ago
Ruben has been working on it for some time..
Ariel E. Coronel
Apr 11th 2010
1 decade ago