# Threats from within & Java runtime integrity

=?iso-8859-1?Q?H=E5kan=20S=F6derstr=F6m?= (hsod@basesoft.se)
Tue, 20 Jul 1999 15:07:26 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: =?iso-8859-1?Q?H=E5kan=20S=F6derstr=F6m?=: "JSECURITY Issue: Broken link"
- Previous message: Jan Luehe: "Re: Getting rid of AllPermission"

    Message-Id: <3794748E.52F4F780@basesoft.se>

    Date: Tue, 20 Jul 1999 15:07:26 +0200

    From: "=?iso-8859-1?Q?H=E5kan=20S=F6derstr=F6m?=" <hsod@basesoft.se>

    To: java-security@java.sun.com

    Subject: Threats from within & Java runtime integrity

Java security discussions often focus on threats from without. What if
the threat is from within? Here are my misgivings. I hope they prove
unsubstantiated.

Imagine a Java application is the guardian of some valuable asset; your
company's strategic business plans, for instace. Would a Java document
management system stand up against an attack from a determined user
within the company?

In particular, what worries me is the possibility to make the JVM load
(for instance) java.security or javax.crypto classes from unexpected
places. In other words, is it possible to circumvent the Java security
architecture by knowing enough Java?

I'm no expert, but the Java 2 runtime (rt.jar) in this (Windows NT)
computer uses its MANIFEST only to note that certain Swing components
are also Beans (no digests). Thus it seems one could replace any of its
classes. Then one would start applications with
-Xbootclasspath:<modified runtime>. In a Solaris environment I suppose
one could modify LD_LIBRARY_PATH to make the runtime load native methods
from a different place. Several critical ClassLoader methods are native.
If you cannot load new versions of java.security or javax.crypto classes
directly, you can still do it if you take control of the system class
loader.

The above scheme obviously won't help you decrypt an encrypted document.
But it may grant you new and liberal Permissions.

The Java security architecture seems fine to me, but only if you can be
101% sure that the mechanisms themselves cannot be invisibly subverted.

    --
    Hakan Soderstrom (contractor), Basesoft Open Systems AB
    P.O. Box 34 140, S-100 26 Stockholm
    Voice: +46 8 131720  Fax: +46 8 131725  E-mail: hsod@basesoft.se

- Next message: =?iso-8859-1?Q?H=E5kan=20S=F6derstr=F6m?=: "JSECURITY Issue: Broken link"
- Previous message: Jan Luehe: "Re: Getting rid of AllPermission"