Onderwerp: Java 1.4.2_02 InsecurityManager JVM crash

-----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() {
=09 System.out.println("doit");
=09=09 int o =3D classDepth(null);
}

public static void main(String[] a) {
=09InSecurityManager m =3D new InSecurityManager();
=09m.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


- --

Never be afraid to try something new. Remember, amateurs built the
ark; professionals built the Titanic. -- Anonymous

Marc Sch=F6nefeld Dipl. Wirtsch.-Inf. / Software Developer

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (AIX)
Comment: For info see http://www.gnupg.org

iD8DBQE/mwUxqCaQvrKNUNQRApt/AJ9uwaavBSTpMFa9vZ+BhwBDNxD8sACaA3DZ
E3sLSXijpoAjR1iOdC1FGPo=3D
=3DTYLu
-----END PGP SIGNATURE-----

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

Hi,

either they (Sun) remove the deprecated functions completely or they
introduce permissions which explicitly allow to call deprecated stuff.
An adversary does not care whether the function he uses to interfere
correct operation is deprecated. Deprecation is not a security feature,
correct and aware coding is.

Marc


On Mon, 27 Oct 2003, Francisco Andrades wrote:

> Date: Mon, 27 Oct 2003 16:01:18 -0400
> From: Francisco Andrades <fandrades@nextj.com>
> To: bugtraq@securityfocus.com, full-disclosure@lists.netsys.com
>
> 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() {
> > =09 System.out.println("doit");
> > =09=09 int o =3D classDepth(null);
> > }
> >
> > public static void main(String[] a) {
> > =09InSecurityManager m =3D new InSecurityManager();
> > =09m.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
>
>

--

Never be afraid to try something new. Remember, amateurs built the
ark; professionals built the Titanic. -- Anonymous

Marc Sch=F6nefeld Dipl. Wirtsch.-Inf. / Software Developer