# Re: Java security

Sundar Narasimhan (sundar@ascent.com)
Fri, 3 Oct 1997 10:25:04 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Li Gong: "Re: Java security"
- Previous message: L. Peter Deutsch: "Java security"
- In reply to: L. Peter Deutsch: "Java security"
- Next in thread: Li Gong: "Re: Java security"

    Date: Fri, 3 Oct 1997 10:25:04 -0400

    Message-Id: <9710031425.AA25294@MountRushmore.ascent.com>

    From: Sundar Narasimhan <sundar@ascent.com>

    To: ghost@aladdin.com

    In-Reply-To: <m0xH7Mr-000R25C@lamp.aladdin.com> (ghost@aladdin.com)

    Subject: Re: Java security

>> Given the security problems with Java ...
>
> I was forwarded your message above (full msg below). Given that I am
> responsible for overall Java security, I am interested to hear what
> specific security problems you were thinking and why these had impact
> on what you were discussing. (Please CC me on your reply.) Thanks.

Peter: you missed the most important problem with Java and its
security today -- three separate and non-interoperable solutions in
the market wrt. code signing. This is what is killing Java acceptance
within large enterprises today. Netscape has lost focus, Sun doesn't
seem to have the clout to make them do DSA in Navigator, people like
Verisign (and other CA's) want to make money, the NS capability API is
well thought out but complex, and MSFT have their own solution which
is getting out there and being deployed. Put those facts together and
arrive at your own conclusions.

I don't want to comment on your list, since the point I'm trying to
make is perhaps NOT technical -- and I think this problem is NOT going
to be solved with technology alone.

I would have to do some digging to find the articles that led me to make the
above comment. There are several general classes of security problems with
Java that have been widely reported in the public press:

1) Java has no security kernel. Security in Java depends on an
enormous amount of widely dispersed code being bug-free.

2) The definition of what security guarantees are being provided is
unclear. For example, without a clear model of what it means for an access
to be authorized, the question of whether an unauthorized access has
occurred is unclear.

3) Because Java has no model of resource allocation,
denial-of-service problems are not dealt with.

4) The Java VM definition does not specify precisely what
constitutes legal compiled code: it specifies neither what properties of
compiled code are sufficient to guarantee legal execution by all conforming
VMs, nor how those properties are verified by the loader. It is therefore
possible for rogue bytecode to exploit weaknesses in particular
implementations of the checker or in the VM's execution machinery,
implementations which may nevertheless conform to the published
specifications.

Any of the above is sufficient to create security concerns with execution of
downloaded content (applets).

I have not been reading the java-security list: I base the above comments on
examples of all of the above problems that have appeared in the public
press. If solutions to these problems have been found, implemented, and
published, please let us know the references.

--

L. Peter Deutsch | Aladdin Enterprises :::: ghost@aladdin.com
203 Santa Margarita Ave. | tel. +1-650-322-0103 (AM only); fax +1-650-322-1734
| ** NOTE ^^^ NEW AREA CODE AS OF AUG. 1 ^^^ **
Menlo Park, CA 94025 | http://www.cs.wisc.edu/~ghost/index.html
"Few things are impossible to diligence and skill."

- Next message: Li Gong: "Re: Java security"
- Previous message: L. Peter Deutsch: "Java security"
- In reply to: L. Peter Deutsch: "Java security"
- Next in thread: Li Gong: "Re: Java security"