
This is the examples directory. It contains example of attacks which are
not readily adapted in the regular test suite but which are intended to
help testing engineers design test for potential security holes. It
contains examples of past security bugs, as well as examples on how
sensitive functionality is handled in the existing system.

ClassLoaderFinalizer.html
_________________________

This is the bug known as the "finalizer" bug. It was discovered internally
by JPG. The idea behind the attack is as follows:

There were a set of classes in the basic JDK which were meant to never be
instantiated by applets, because they provide a host of dangerous
functionality, and that centralizing the security check at the constructor
lvel was cleaner than adding checks on every method in the class:

public class SensitiveClass {

  public SensitiveClass() {
    SecurityManager security = System.getSecurityManager();
    if (security != null) {
	security,checkCreateSensitiveClass();
    }
  }
}

One such class, ClassLoader, had three native methods available to all
subclasses: defineClass, resolveClass and findSystemClass. 

While one attack (made possible by a bug in the verifier) was to actually
instantiate an object despite the security exception and then use it,
another attack consisted of getting the object instantiated, fully
expecting to get an exception and not retaining a handle onto it. The
object thus half-instantiated will be an object without any pointers to it,
which will be put on the finalizer queue. When finalize is called on the
object, the method will be able to use whatever methods it wants to achieve
arbitrary mischief.

The example file shows how to take advantage of this bug in a version of
the JDK not designed to prevent it (e.g. JDK1.0.1 and lower). The current
solution is to not rely on preventing instantiation, but rather to add
security checks to dangerous functionality. Note that other such classes
(FileInputStream for example) are not as badly affected because an
uninitialized instance of them is not useful (ie. it lacks a file
descriptor, it has no native method, etc.).



