Issue 2894: Security problem in JavaToIDL mapping (java2idl-rtf) Source: (, ) Nature: Revision Severity: Summary: Summary: We have a security hole in the reverse mapping that can be fixed by a straight forward spec change. The Java-to-IDL mapping spec 99-03-09 defines in paragraph 28.4.9.5 that rmi-iiop offer a method > Util.loadClass(String className, String remoteCodebase, Class loadingContext) > throws ClassNotFoundException { ... } > which does the following if everything else fails to load the desired class (on both JDK 1.1 and 1.2) > If a class was not successfully loaded by step 1, 2, or 3, and loadingContext > and loadingContext.getClassLoader() are both non-null, then call > loadingContext.getClassLoader().loadClass(className) By virtue of being a "public" core method as part of the rmi-iiop standard extension this mechanism essentially bypasses the "caller class loader" security check from Class.getClassLoader() by allowing arbitrary code to load a class using the class loader of any other class. The ClassLoader javadoc says to this effect. > Class loaders may typically be used by security managers to indicate > security domains. The fix for this situation is to change the signature of the above method to > Util.loadClass(String className, String remoteCodebase, ClassLoader loader) > throws ClassNotFoundException { ... } > so that the caller has to perform the necessary loadingContext.getClassLoader() call before calling this method. This way the callers security permissions are checked properly by the getClassLoader mechanism. So code that uses this API right now has to change from Util.loadClass(className, remoteCodebase, loadingContext) to Util.loadClass(className, remoteCodebase, loadingContext.getClassLoader()) after this spec change. Resolution: Revised Text: Actions taken: September 20, 1999: received issue May 4, 2000: closed issue Discussion: End of Annotations:===== Date: Fri, 17 Sep 1999 11:01:48 -0700 From: Stefan Bauer X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: issues@omg.org CC: David Heisser , Peter Walker , Simon Nash Subject: Security problem in JavaToIDL mapping Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 23946ebe661e46349e0d4108e8a24c4a We have a security hole in the reverse mapping that can be fixed by a straight forward spec change. The Java-to-IDL mapping spec 99-03-09 defines in paragraph 28.4.9.5 that rmi-iiop offer a method > Util.loadClass(String className, String remoteCodebase, Class loadingContext) > throws ClassNotFoundException { ... } > which does the following if everything else fails to load the desired class (on both JDK 1.1 and 1.2) > If a class was not successfully loaded by step 1, 2, or 3, and loadingContext > and loadingContext.getClassLoader() are both non-null, then call > loadingContext.getClassLoader().loadClass(className) By virtue of being a "public" core method as part of the rmi-iiop standard extension this mechanism essentially bypasses the "caller class loader" security check from Class.getClassLoader() by allowing arbitrary code to load a class using the class loader of any other class. The ClassLoader javadoc says to this effect. > Class loaders may typically be used by security managers to indicate > security domains. The fix for this situation is to change the signature of the above method to > Util.loadClass(String className, String remoteCodebase, ClassLoader loader) > throws ClassNotFoundException { ... } > so that the caller has to perform the necessary loadingContext.getClassLoader() call before calling this method. This way the callers security permissions are checked properly by the getClassLoader mechanism. So code that uses this API right now has to change from Util.loadClass(className, remoteCodebase, loadingContext) to Util.loadClass(className, remoteCodebase, loadingContext.getClassLoader()) after this spec change. -Stefan Stefan Bauer CORBA technologies Sun Microsystems Inc.