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
| ||
|
Date: Mon, 27 Oct 2003 16:01:18 -0400 From: Francisco Andrades <fandrades@...tj.com> To: bugtraq@...urityfocus.com, full-disclosure@...ts.netsys.com 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