[<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