Java to IDL December 2000 RTF — Open Issues - OMG Issue Tracker

Key: JAV2I12-102

Legacy Issue Number: 2894

Status: closed

Source: Anonymous

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.

Reported: JAV2I 1.0 — Mon, 20 Sep 1999 04:00 GMT

Disposition: Resolved — JAV2I 1.1

Disposition Summary:

No Data Available

Updated: Sun, 8 Mar 2015 14:01 GMT