More Tough Questions for Finjan


Message-ID: <3467749A.4B1A0E2B@cs.princeton.edu>
Date: Mon, 10 Nov 1997 15:54:50 -0500
From: Dan Wallach 
Organization: Princeton University, CS Department
MIME-Version: 1.0
Newsgroups: comp.lang.java.security,comp.lang.java.misc,comp.lang.java.programmer,comp.security.misc,comp.security.firewall,alt.security,de.comp.security
To: ron@finjan.com
CC: "Mark D. LaDue" 
Subject: Re: Finjan Software Response to Mark D. LaDue
References: <3465a7f3.19487691@news.netvision.net.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

While I cannot comment on whether LaDue's review is correct (I've never
used a Finjan product), I feel some of Ron Moritz's comments are
somewhat inconsistent with everything we know about Java security.

Ron Moritz wrote:

> Finjan:  LaDue does not acknowledge the facts that Finjan (a) defined
> the Java and ActiveX security field; (b) was the first third-party
> vendor to introduce solutions, both at the desktop and at the gateway,
> to address enterprise Java and ActiveX security issues; and (c) has
> received several awards and much applaud for its technology and
> innovation from the press, including:

[list deleted]

Finjan does not acknowledge that the "Java security field" was defined
by Sun themselves, as a fundamental part of the Java design in the
original HotJava alpha releases in 1995.  Finjan also does not
acknowledge the contributions of researchers here at Princeton, at the
University of Washington, and elsewhere around the world.  Finjan also
fails to acknowledge the sophisticated new Java security infrastructures
supported by Netscape 4.0, IE 4.0, and Sun JDK 1.2.

Finjan's technology (as distilled from its marketing documents) seems to
include: 128-bit checksums of applets and catching of security
exceptions (for detecting "bad" applets), applet monitoring (and
termination), and some form of sandboxing for ActiveX controls.  I'll
focus on the Java stuff, since that's what I know about.

None of these technologies seem strong in the face of a hostile
adversary.  A malicious applet can be trivially changed every time it's
delivered by a Web server.  Such polymorphic applets would fail the
checksum tests.  A more appropriate solution would likely be statically
looking for specific code sequences within the applet, similar to how
traditional virus checkers work.  These, of course, require having
existing viruses (or attack applets) to analyze.

As far we know, there have never been *any* malicious Java applets
*ever* written beyond those used by academics to demonstrate bugs.  Our
own attack applets were only shared with the specific Java vendors (Sun,
Netscape, and Microsoft), and if you're running the latest and greatest
versions of their products, you're safe against our older attacks.

It's worth noting that not a single one of our attack applets ever
needed to cause a security exception to be thrown, and, in fact, some
commercial Java programs (such as Corel's office suite) tried to open
files to detect if they were running as applets or not.  Non-hostile
programs can cause security exceptions, too.

I'm also curious how Finjan hopes to terminate an applet once it's
running.  If you call Thread.stop(), that just sends a ThreadDeath
exception which can be caught and ignored.  Even if they hack themselves
deeply into the Java runtime and terminate the actual thread, they could
destabilize the entire browser, since that thread could be in the middle
of a critical section.  Even then, if they can safely terminate the
thread, the thread's garbage will eventually be collected, causing
finalize() methods to run, and effectively bringing the hostile applet
back to life again.  Even more fun, this sort of resurrected applet
thread would no longer have anything to do with the original applet (it
started on the system's GC thread!).

One of the main things which I think Finjan does usefully is
black-listing support (so I can cause the Java applet on Finjan's home
page not to load on my browser).  This kind of blacklisting is also
supported  by IE 4.0's security zones and our own JavaFilter (available
free from http://www.cs.princeton.edu/sip/).

I would feel better if there were a detailed public description of how
Finjan's products work as well as rigorous independent testing of the
Finjan security architecture.

Personally, I run Netscape 4.03 with Java turned on.

--
Dan Wallach                  Princeton University, CS Department
dwallach@cs.princeton.edu    http://www.cs.princeton.edu/~dwallach/