Great Circle Associates Firewalls
(July 1996)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: RE: Java security
From: Russ <Russ . Cooper @ RC . Toronto . on . ca>
Date: Tue, 30 Jul 1996 19:40:17 -0400
To: "'Paul D. Robertson'" <proberts @ clark . net>
Cc: "'Firewalls @ GreatCircle . COM'" <Firewalls @ GreatCircle . COM>

I just want to be clear here, I was stating the obvious in my original
post. AFAIK, the VM is not supposed to be dependent on the OS to
maintain its security, however, it does depend on the implementation of
the VM.

To me, the inherent insecurity of Java is that it is supposed to be
viewed as secure. ActiveX should not be viewed as secure by anyone,
anytime. This is a big difference in my mind. Microsoft is not
attempting to state the security of ActiveX, and its use of digital
signatures is intended only to the extent that it allows them to prove
that they were the originators of the applet so they can sell software
across the net. If they were attempting to do any further security, the
WinVerifyTrust API implementation would be checking the signature
against the CA every time the object was accessed. The way its
implemented, this check is done once and recorded, subsequent access
check first to see if its been previously authorized, and if so, it will
use the object. So if a CA invalidates an object (say, because the
author was found to be a malicious hacker), anyone who had previously
accessed the object would continue to use the malicious object without
question.

This doesn't represent a problem for the sale of software, but it
obviously represents a problem if ActiveX objects are used the way Java
applets are used. Clearly Microsoft is leaving it up to other folk to do
something to secure ActiveX objects for more widespread use than what MS
intends (IMO). Microsoft also sees ActiveX widely used on an IntrAnet,
where the security of objects (in many environments) is less of an
issue. I'm not promoting that idea, but its my interpretation of what MS
believes.

I agree that securing the VM should be possible, but so far, its been
impossible to guarantee. Sun and Netscape may be very security
conscious, but the simple reality is "can we ever completely trust
them?". I would say, gauging by the activity by companies trying to find
ways to screen or proxy applets, it would seem the answer is no for
some. I doubt that we'll be in a position to consider it safe for quite
some time to come. The same is true with ActiveX objects, so don't think
I'm saying that one is better than the other. At least with an ActiveX
object I'm not struggling to decide if its secure, I just assume it
isn't.

ActiveX has longer legs in the PC marketplace because it is more closely
integrated into the OS. While this may present a greater challenge for
developers, it means that a security product developed to deal with
ActiveX objects can also be used to handle a substantial amount of OS
security as well. Something developed for Netscape stays in their
Browser (until they release a complete OS that is), and so the scope of
the product is somewhat more limited (IMO). Products like Nortel's
eNTrust can be extended to have the ability to do far more than just
handle objects arriving via the browser.

The Java language, on the other hand, is a very different animal than
Java applets. When it comes to security, the issues are completely
different and shouldn't be confused. The Java language, like any
language, is not constrained by VM's or Sandboxes, or whatever. You can
develop whatever security implementation you chose in the Java language,
as you could in C. Applets are the fun, neat, easy to implement version
of Java, but its not the Java language.

As an example, you will be able to write ActiveX objects with J++ (MS'
name for their implementation of the Java language), and then script it
with the JavaScript language if you want.

This all boils down to a desperate need to build better security at the
desktop, together with better tools for Firewall administrators to
define permissions for those desktops through gateways to less trusted
networks (assuming we adhere to the idea that there are "trusted" and
"untrusted" networks). With better tools at the desktop we can implement
user policies to define permissions regardless of where they are, and
what their doing.

For all those who think that filtering Java applets are the way to go,
think of this. I set my Netscape cache to never expire. I take my
portable home and access the Internet through my private connection and
download a malicious applet. I go back into the office to show everyone
this neat new applet I've found. Bingo, the applet can run despite the
wonderful filter on the Firewall. I'm not even trying to be malicious,
I'm just an uneducated user...;-]

We need a way to turn off what we consider insecure, and prevent it from
being turned on again by the user. This doesn't exist in any browser
that I've seen so far, but it will be more possible when the browser and
the OS are the same thing, when we can use authentication servers to
provide permission profiles back to the OS.

Cheers,
Russ
...due to licensing restrictions, this message can only be read by 10
people within 10 minutes...
>


Follow-Ups:
Indexed By Date Previous: Re: So called ISDN secrets
From: Rahul Dhesi <dhesi @ rahul . net>
Next: Re: Re[2]: Ascend pipeline products.
From: lists @ lina . inka . de (Bernd Eckenfels)
Indexed By Thread Previous: RE: Java security
From: ray @ rayk . com (Ray Kaplan)
Next: Re: Java security
From: "Simon J. Gerraty" <sjg @ quick . com . au>

Google
 
Search Internet Search www.greatcircle.com