lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3F9D798E.1000905@nextj.com>
From: fandrades at nextj.com (Francisco Andrades)
Subject: Re: Java 1.4.2_02 InsecurityManager JVM crash

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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ