I'd like to give you my thought w.r.t. the relative security of
Java VM and ActiveX.
First of all, let me say that this is definitely an apples-oranges
comparison. The two technologies are aimed at different niches in
terms of security functionality, but unfortunately at the _same_
market: applet security.
ActiveX security model: Reliable delivery
ActiveX aims to improve security by allowing hosts to
distinguish between "approved" applets and
"non approved" applets.
An "approved" applet is not only reliably delivered, it comes
from a known source, author etc and is "published" software
similar. Think of "Code Signing" as "Digital Shrinkwrap".
Java Security model: Encapsulation and Reliable Delivery
Java aims to improve security by encapsulation. Rather than
running the applet as native code, the applet is interpreted
via a Java VM. The Java VM keeps up with the source of
the applet and restricts its access to local resources.
Think of "encapsulation" as "Execution by Proxy".
However remember that Java will probably incorporate code
signing soon. So we should really be comparing "Reliable Delivery" vs
"encapsulation" rather than Java VS ActiveX.
These two competing security models _both_ have utility.
Let me compare their uses in the following env's
Environments:
StandAlone: My PC or Workstation.
LAN: running applications from file servers.
WAN: running applications from file servers.
Internet: running applications from file servers.
First what can "Reliable Delivery" do in these?
StandAlone: My PC or Workstation.
Reliable Delivery is accomplished today by shrinkwrapping
and packaging and physical delivery to retail outlets.
"Code Signing" would protect me from the remote chance
that binaries are altered in transport.
LAN: running applications from file servers.
Protects against binary patching or alterations as
applications or applets are on the wire. This is an
_improvement_ of the technologies currently in wide-spread
use for file sharing.
WAN: running applications from file servers.
Can protect me from altered binaries, or
"non-approved" binaries. Can limit my selection of
executable file servers
Internet: running applications from file servers.
Can allow me to reliably download software from
participating vendors over the internet. This too is
a big improvement in security over straight ftp, and a
big improvement in ease-of-user over PGP.
The _HUGE_ misconception and potential problem is the
mistaken belief that this boost in security is enough
to allow me to download "network aware" applets. It's
one think to update my word processor, but quite
another to download anything that listens to
anything any where. Since ActiveX applets are
essentially network aware COM objects there is a
potentially huge security hole here.
Now what can "Reliable Delivery" __NOT__ do in these?
Protect against unintentional security holes in software.
Protect against Trojan Horses.
Protect against Data Content Viruses.
Protect against Viruses invecting the Vendor.
Allow safe execution of network aware applets.
Secondly what can "Encapsulation" do in these envs?
StandAlone: My PC or Workstation.
Encapsulation could provide an excellent boost in
security here. Unfortunately the operating systems in
use on the desktop, Windows, Win95 and WinNT,
don't provide adequate separation between application
code and system code. WinNT goes futher than the
others but not far enough.
The current Java VM model doesn't help me here, because I
want to access my local files, and that means running
java appliCATIONS not Applets. However the
technology could be extended to restrict my Java word
processor to read/write _only_ word processor documents.
And/or to limit the directories that it would access.
I don't know if Sun knows what it could do here :)
LAN: running applications from file servers.
If I can completely trust my "Encapsulation" I could
say "I don't care where this applet comes from or who
wrote it". This would be a HUGE improvement in
security. Is it realizable? Maybe. But it will take
time to shake all the security bugs out of the Java VM.
The _dis_advantage is that one java VM bug breaks
everthing until its fixed. The _ad_vantage is that
there is probably a way to fix it.
However a weaker stance is to allow
only reliably delivered applets and say "I trust
the vendor but thats's not enough" the vendor may
have made a mistake. An esoteric java VM exploit would
only work if some
vendors software happens to allow access to that type
of exploit.
This is the "multiple levels of
security" approach and the one that I advocate.
WAN: running applications from file servers.
same as above
Internet: running applications from file servers.
Pure and perfect encapsulatin would allow me to
safely download and execute software from any vendors
over the internet. Combining encapsulation with
code signing would give unparalleled security.
A Java wordprocessing vendor could license the
wordprocessor _AND_ the file storage. The benefit is
that I have the assuranced that the vendors software
isn't mucking with my machine and the vendor controls
his software distribution and upgrade cost and
potentially sells new services. Would people buy it?
Would you like to be able to fly out of state and
access your wordprocessor docs from any location in
the world with just a browser? All we need is a
little more bandwidth.
Now what can "Encapsulation " __NOT__ do in these?
-Protect against Data Content Viruses?
A java applet of any use is likely to modify persistent data
somewhere.
If someone writes Word_For_Java, we'll soon have a Word_For_Java version
of the concept virus. But then, the VM could restrict access to the
global macro files and such when "running" someone elses
document. I'll have to think about this one more.
-Allow safe execution of network aware applets. ?
Encapsulation goes a long way here. At least my PC or
workstation will be safe, but what about other hosts? Applets
sending fake email and manipulating other Internet resources are
a problem that encapsulation alone will not solve. I advocate
a security policy authorizing signed applets to access only
their source machine as verified by a Certificate Authority.
But notice that it does cover the following.
Protect against Viruses invecting the Vendor.
Protect against unintentional security holes in software.
Protect against Trojan Horses.
Conclusions:
1. Reliable delievery is a moderate security gain.
2. Encapsulation has _major_ potential but should be augmented
with reliable delivery.
Now back to Java vs ActiveX.
1. Java needs to add reliable delivery and perfect their VM.
2. ActiveX needs to add encapsulation.
3. As they stand now, Java's security is superior to ActiveX's for
intenet downloadable executable content.
What bothers me the most about all of this is that Microsoft seems to
be claiming that ActiveX is has an effective model for downloading network
aware objects. It is _NOT_.
However, I'm not sure if they are making that
claim outright or if others are attributing it to them. Their FAQ
does however state this:
From www.microsoft.com ActiveX FAQ
Is signed code really secure?
Yes. The security methods used to support this proposal are not new;
they rely on tried and proven
technology. The specifications on which the technology is based have
been used successfully in the
industry for some time. These include PKCS #7 (encrypted key
specification), PKCS #10 (electronic
request forms), X.509 (certificate specification), and SHA and MD5
hash algorithms.
IMO the above statment is misleading, it equates "secure code" with "signed
code", and is typical of their stance. However, I'm trying hard to
see the good in ActiveX w.r.t security inspite of such.
I am also perplexed with the current perception that Java is a
security _problem_ instead of a security _solution_. The current rash
of Java VM holes is a set of bugs coming from a _single_ program (with
multiple implementations) that is undergoing extensive analysis.
Imagine what ActiveX will do for us when users want to trust _every_
program to be network aware!
Mark Riggins
Secure Systems Engineering
AT&T Bell Labs
Disclaimer: This is my own opinion and not necessarily that of my
employer.
|
|
