Re: Java

[Scott Barman <scott @ di2 . disclosure . com>]

On Fri, 22 Mar 1996, Paul McNabb wrote:

> I have been talking to Sun Java people for awhile, and this is what I
> understand the security to be:

I have been very vocal in my opposition to Java for security reasons.
So in an effort to silence my critics in saying I have not looked at it
carefully enough, I signed the non-disclosure agreement and picked up
the most recent copy of the Java Development Kit.  I am porting it to
SunOS 4.1.3 and will try to do so to FreeBSD as well in an attempt to
make a filter/proxy for it.

In my reading of the sources (thus far) here is what I found:

(NOTE: I am doing this at home, on my own time, and the sources are on
 my SS2 at home, not at work!  So I am trying to do this from memory)

> 1) a very tight language with little chance of problems due to out-of-range
> errors, memory overwrites, etc.

This is very well done.  The machine concept that runs the bytecode
interpreter looks like it does a very good job at preventing problems in
bytecode.  HOWEVER, so far, I found a few cases where the bytecode
interpreter does not check its own bounds.

BTW: I asked this once of a Sun engineer and he seemed to get upset with
me, but doesn't the bytecode concept remind you of the UCSD P System??
(How many people are "old" enough to remember this? :-)
 
> 2) an engine that tries to look at everything the applet is doing and
> prevent anything that looks suspicious (note: this includes prohibiting
> the applet from creating subprocesses, running other programs, directly
> access most operating system functions, etc.)

Hmmm... no it doesn't.  I found the code that allows Java to open any
arbirtrary TCP connection.  There is supposed to be a restriction, but I
found the bug that has been long reported in this area.  I will put it
like this: I would not have programmed this section as it was.  In fact,
I will probably re-write it and offer it back to Sun (for a fee,
recognition, or somthing just as obnoxious! :-).

The whole javaio superclass is very interesting and is in dire need of
review!  It is this are I am concentrating on to see how to write a
filter/proxy for Java.
 
> 3) "registering" applets with a digital signature so that you can know
> "for sure" where the applet came from (and presumably you run only those
> from people you trust).

I haven't seen this yet (I haven't gotten that far! :-) so no comment at
this time.

> Item #2 is the real problem.  It sure helps make the applet secure --
> but it really limits the usefulness of the applet.  The problem is that
> the applet's environment isn't secure enough if it runs something outside
> the Java engine's strictly controlled environment.  That's where 3rd
> party products like our Decaf come in.  Without those kinds of security,
> Java will take a long time to really be a big force in the market.

I don't know what your product is, but in the context of Java and the
internet, I cannot say it's safe!  There is a potential for problems far
beyond what was found in Netscape's version of JavaScript!  I may
publish applets that exercise those problems, but they can be deadly!!

Thus far, with JDK at my finger tips, I figured out how I would write an
applet that would not only grab the /etc/passwd file, but search the
system for any security-type file (/etc/allow, /etc/deny, /etc/shadow,
etc.) and have it emailed back to me while making the browser show some
pretty annimation at the same time.

Oh, and if someone from Sun is listening in, why don't you make sure that
temporary files created in a Java applet are removed in your final
descructor?  I haven't looked deeper, but I am not seeing these things
removed properly.  That's all we need is for a hacker to plant a real
binary with their Java applet and let a new one access it later (I
haven't figured out how, but give me time).

Java?  I'll get mine from Quartermaine, thank you!

(To non-DC area people, Quartermaine is a local coffee shop whose coffee
 I prefer over other national brands).

--
scott barman                  DISCLAIMER: I speak to anyone who will listen,
scott @
 disclosure .
 com                      and I speak only for myself.
barman @
 ix .
 netcom .
 com