[Full-Disclosure] Re: Java 1.4.2_02 InsecurityManager JVM crash

[Francisco Andrades]

Although this is a serious bug, the method SecurityManager.classDepth() 
has been deprecated for a while, you should not be using it.

Seems to be a bug on native code (since it's deprecated it may not have 
been updated lately).

Marc Schoenefeld wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
>  Java 2 Security Managers are objects that should enforce
>  system integrity and safety. Everyone would expect that
>  the provided base classes from the JDK are therefore a
>  role model for code quality and stability. But that's
>  all theory. Let's do some practice:
> 
>  Imagine a lazy implementor (like me) of a SecurityManager,
>  he codes the following:
> 
>  /* InsecurityManager-Demonstration  */
>  /* coded by Marc Schoenefeld        */
>  public class InSecurityManager extends SecurityManager {
> 
>        public void doit() {
>        	          System.out.println("doit");
>        		  int o = classDepth(null);
>        }
> 
>    public static void main(String[] a) {
>    	InSecurityManager m =  new InSecurityManager();
>    	m.doit();
>    }
> }
>  When you run the class with the command
> 
>  java InSecurityManager
> 
>  you get a jvm crash, instead of  a null pointer exception.
>  I tested this with the latest 1.3.1,1.4.1,1.4.2 implementations.
>  All Sun implementations crash, the IBM 1.4.1 (comes with
>  Websphere or Cloudscape) is stable.
> 
>  This sample of code will do no harm to productive environments,
>  because you cannot instantiate a second security manager, but
>  it may be a snapshot of the inner condition of jvm security.
> 
>  Lesson learned: Do not believe white papers or specifications,
>  test the implementation and report bugs to the vendor. Choose
>  a stable implementation.
> 
>  Sincerely
>  Marc Schoenefeld

-- 
Francisco Andrades Grassi
www.nextj.com
Tlf: +58-414-125-7415