It was discovered that the JNLPSecurityManager in certain cases failed to properly implement the security policy, and did not throw an exception to prevent completion of a possibly unsafe or sensitive operation and simply returned from the checkPermission method.
Any service relying on the SecurityManager.checkPermission() method to throw an exception then incorrectly assumed that the permission was granted.
The issue was independently reported by Omair Majid for JNLP applications, and for applets by a reporter cooperating with the TippingPoint Zero Day Initiave.
http://icedtea.classpath.org/hg/release/icedtea6-1.7/rev/6f7d633c355a http://icedtea.classpath.org/hg/release/icedtea6-1.8/rev/aa77afad613c http://icedtea.classpath.org/hg/release/icedtea6-1.9/rev/7ec6c82e69ee
Red Hat would like to thank the TippingPoint Zero Day Initiative project for reporting this issue. The original issue reporter wishes to stay anonymous.
This issue has been addressed in following products:
Red Hat Enterprise Linux 5
Via RHSA-2011:0176 https://rhn.redhat.com/errata/RHSA-2011-0176.html
*** EmbargoedBug 664841 has been marked as a duplicate of this bug. ***