Java, Netscape, OpenDoc, and Babel

I've been reading up on Java at the Web sites (such as
http://java.sun.com/1.0alpha3/doc/overview/java/index.html) and am awaiting
with bated breath the HotJava browser port for the Mac, to play with.

The "tower of Babel" is getting higher and higher, with Python, TCL,
Safe-TCL, Perl, and the various multimedia languages (Shockwave, Lingo,
ScriptX) all competing for attention.

I guess this is all to the good, and let the best languages and frameworks
prevail.

On a SmalltalkAgents list I am on (I own SmalltalkAgents, a powerful
implementation for the Mac, with a Windows version coming), one poster had
the following to say:

"I am hoping that OpenDoc and specifically CyberDog from Apple provide the
basis for a more rational and open Internet component environment. NetScape
is becoming a kitchen sink app and any solution they create for plug-in
components will set back things when an open industry standard for
components (OpenDoc) is about to be released."

NetScape a kitchen sink? Perhaps, but kitchen sinks have been selling
pretty well for years.

I just picked up a copy of "Pattern Languages of Program Design," edited by
James Coplien (of the well-regarded C++ book) and Douglas Schmidt. This
book has a series of interesting papers on the "design pattern" approach
(as in the book by Erich Gamma et. al.).  The idea behind "pattern
languages," seen by some as the evolution of object-orientation, is to find
architectural abstractions, such as "iterarators" and "constructors" which
encapsulate important behavioral features of a system.

The "applied ontology" in crypto seems to be a natural fit. Or so I think.
Maybe wishful thinking.

But in which framework or language, given the profusion of frameworks and
languages?

We had some TCL advocates a while back (Strick, Hal...)...any reaction to Java?

And so it goes.

--Tim May




..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,
tcmay@sensemedia.net   | anonymous networks, digital pseudonyms, zero
408-728-0152           | knowledge, reputations, information markets,
Corralitos, CA         | black markets, collapse of governments.
Higher Power: 2^756839 | Public Key: PGP and MailSafe available.
"National borders are just speed bumps on the information superhighway."

Just a quick note to chime in. The OSF just did a deal with Sun
to port Java to several platforms. The OSF is opening a "web mall"
where you can grab software objects and run them. Expect to Java
*really* take off in about 2-3 months. Every business on the net is going
to want a Java shopping-client-basket on their web-mall/web-store.
(Web Consultants! Learn Java!)

-Ray

Ray Cromwell writes:
> 
>   Just a quick note to chime in. The OSF just did a deal with Sun
> to port Java to several platforms. The OSF is opening a "web mall"
> where you can grab software objects and run them. Expect to Java
> *really* take off in about 2-3 months. Every business on the net is going
> to want a Java shopping-client-basket on their web-mall/web-store.
> (Web Consultants! Learn Java!)

As a security consultant, I'm very happy about Java because once the
holes are found in it and massive, Morris style worms are launched
with it, I'll be laughing all the way to the bank.

I exagerate only slightly. I don't believe Java to be secure, in spite
of the claims. Its too complicated, and it operates in an environment
who's correct operation is required for it to remain secure. Good
system design says that you want a system's failure mode to produce a
secure result, but thats not what Java does.

Perry

|> As a security consultant, I'm very happy about Java because once the
|> holes are found in it and massive, Morris style worms are launched
|> with it, I'll be laughing all the way to the bank.

|> I exagerate only slightly. I don't believe Java to be secure, in spite
|> of the claims. Its too complicated, and it operates in an environment
|> who's correct operation is required for it to remain secure. Good
|> system design says that you want a system's failure mode to produce a
|> secure result, but thats not what Java does.

I disagree for the simple reason that Java and Hotjava are not being
treated as trusted code in their applications. Applets are tightly
contrained in what they can do, and hotjava's default attempt to
configure a "firewall" when it boots up is not likely to engender a false
sense of security.

I've been looking at the Java code closely for a couple of months now, and
I find it to be relatively clean in its implementation (Solaris version at
least). I think the biggest worry might be holes in the non-Sun ports along
the host machine interfaces. Overall, I give the Solaris implementation
extremelly high marks in terms of its security. I think I'm actually more
worried by far less powerful browsers whose code I don't approve of, like
Mosaic. The vast majority of security problems result from the fact that
most code has security added in AFTER coding starts. Java has been designed
for excellent security from the very begining.

JWS

solman@MIT.EDU writes:
> I disagree for the simple reason that Java and Hotjava are not being
> treated as trusted code in their applications. Applets are tightly
> contrained in what they can do,

You are incorrect. Applets are DESIGNED to be tightly constrained in
what they do. You want to bet your career that there are no bugs in
the implementation of this design? The thing keeping you from opening
sockets or doing file-io is a very thin scrim. Are you *certain* that
it is bug free? I'm not.

> I've been looking at the Java code closely for a couple of months now, and
> I find it to be relatively clean in its implementation (Solaris version at
> least).

Are you willing to bet your career that its bug free? Thats my question.

> I think I'm actually more worried by far less powerful browsers
> whose code I don't approve of, like Mosaic.

Don't get me wrong -- Mosaic also bothers me, as does Netscape. Java,
however, gives me the willies.

> The vast majority of security problems result from the fact that
> most code has security added in AFTER coding starts. Java has been
> designed for excellent security from the very begining.

*designed*. Can you be certain that both the design and the
implementation are bug free?

I like systems that are more fail-safe. About half a dozen
simultaneous bugs would be needed to break some of my more secure
firewalls, for example. Java does *not* provide security in depth.

.pm

Thus spake Perry:
|> solman@MIT.EDU writes:
|> > I disagree for the simple reason that Java and Hotjava are not being
|> > treated as trusted code in their applications. Applets are tightly
|> > contrained in what they can do,

|> You are incorrect. Applets are DESIGNED to be tightly constrained in
|> what they do. You want to bet your career that there are no bugs in
|> the implementation of this design? The thing keeping you from opening
|> sockets or doing file-io is a very thin scrim. Are you *certain* that
|> it is bug free? I'm not.

What's with the facetious questions? Only an idiot would guarantee a piece
of software to be error free. I am highly confident that there is very
little probability of a raider applet doing significant damage. That's as
much as I can say of any of of any of the systems I use... and its saying
alot given that the thing is executing code it pulls off the net. Is there
still room for cleaner code? Definitely, and I think we'll see some of it
as Java goes Beta and then production.

|> I like systems that are more fail-safe. About half a dozen
|> simultaneous bugs would be needed to break some of my more secure
|> firewalls, for example. Java does *not* provide security in depth.

I think that the high level architecture of Java provides as much security
as such a product can possibly provide. By the time Java becomes widely
distributed (it is still in Alpha3), I expect it to have features that deny
access to any applet not signed by somebody in a list the user creates, a
sort of web of trust. On top of this layer, Java already offers rudimentary
firewalls. The combination of these layers should be quite effective.

Of course, Netscape will probably find a way to screw their implementation
up :)

JWS

solman@MIT.EDU writes:
> What's with the facetious questions? Only an idiot would guarantee a piece
> of software to be error free. I am highly confident that there is very
> little probability of a raider applet doing significant damage.

I see little reason for such confidence.

> |> I like systems that are more fail-safe. About half a dozen
> |> simultaneous bugs would be needed to break some of my more secure
> |> firewalls, for example. Java does *not* provide security in depth.
> 
> I think that the high level architecture of Java provides as much security
> as such a product can possibly provide.

Thats far from true as well. The Java interpreter could have all its
I/O abilities removed, for example, rather than relying on correct
implementation of the possibly correct language model to keep users
from performing I/O. -- I can name lots of similar things.

Having designed systems to be as secure as possible, I'd say that Java
violates lots of the constraints. Its too big, too complicated, and
relies for its security on the correctness of its implementation.

> By the time Java becomes widely distributed (it is still in Alpha3),
> I expect it to have features that deny access to any applet not
> signed by somebody in a list the user creates, a sort of web of
> trust.

Again, this depends on the correctness of the implementation.

> On top of this layer, Java already offers rudimentary
> firewalls.

What?????

.pm

> 
> 
> Ray Cromwell writes:
> > 
> >   Just a quick note to chime in. The OSF just did a deal with Sun
> > to port Java to several platforms. The OSF is opening a "web mall"
> > where you can grab software objects and run them. Expect to Java
> > *really* take off in about 2-3 months. Every business on the net is going
> > to want a Java shopping-client-basket on their web-mall/web-store.
> > (Web Consultants! Learn Java!)
> 
> As a security consultant, I'm very happy about Java because once the
> holes are found in it and massive, Morris style worms are launched
> with it, I'll be laughing all the way to the bank.

  Holes have already been found in CERN HTTP. The GETS() style bug
was in the first few versions allowing attacks to overwrite the
process stack. Any mail server written in perl is susceptible
to weird attacks. For instance, if you ever eval/exec any variable
that is double-quoted, rather than single quoted, it is possible to
run shell commands via backtics or shell subprocesses in variable names.
In fact, can you even prove that elm or pine don't have some obscure
bug wherein a certain message, say with malformed headers, can
overwrite the stack and allow Morris style attacks? The "Good Times"
virus may actually be possible. 

  Security is very nice to have. it's nice to rely on. But sometimes 
there's a need for some liberty. Make everything as secure as you
can, but if security prevents you from doing something that you want
to do, it's not helping you. The internet would be a very cold and 
barren place if the only application people ran was mail.

  Object Oriented Superdistributed components are so useful an abstraction,
I think it's worth the security risk. HotJava solves some fundamental
issues with protocols. Right now the W^3 working groups have been struggling
to define URI/URCs and a whole host of other web protocols. They've been
doing it for years, but they suffer from Xanadu like problems as far as
I can tell. They don't want to saddle the web with a bad protocol, so 
they search to define a perfect one. Hence, no prototypes are ever
deployed, because if they were, the user community might make them
a defacto standard and lock them into it much like MS-DOS locked
PCs into the Dark Ages. With Java, you define all the protocols you
want. If your browser doesn't understand how to fetch a protocol,
it can fetch a protocol handler. There's no need for a kitchen
sink application that understands every protocol in existence.

  And with HotJava, you don't NEED to automatically fetch an application
and run it. You can just use it as an extension language. If someone
defines a new application or protocol handler for it, and this person
is fairly trusted on the net, you can decide to run it (kinda like
turning off autoload images), and even review the source code first.
This is no less secure than ftping software from some site and compiling
it.  

  Maybe for you, the issue is protecting corporate networks behind firewalls.
That's good, well then don't let employees run HotJava. However, I look at
it from the home slip/ppp'ed user standpoint. I think over the next two
years, slip/ppp'ed users will displace corporate/academic users as the
largest group on the net. 

  There will be worms and viruses. Just like there are nowadays. And there
will be fixes. And there will be yet another arms race between virus
writers and people who write anti-virus software. No doubt, there will
be HotJava based worm/virus scanners, etc. A new market will come into
being. You'll make money off of fixing holes. I'll make money off
custom java clients business web pages. It's the price that should be
paid, that is always paid, with any new technology. I'm not advocating
being careless. I'm just saying that paranoid security hampers 
development of more robust and better software. HotJava is a piece
of low-hanging fruit. As more people use it and more problems are found,
better fruit will be found.

-Ray

Ray Cromwell writes:
>   Security is very nice to have. it's nice to rely on. But sometimes 
> there's a need for some liberty. Make everything as secure as you
> can, but if security prevents you from doing something that you want
> to do, it's not helping you.

Yes it is.

I know lots of users that would like to do certain dangerous things,
but they are better off not being able to do them because if they
could very likely the security problems would mean in six weeks their
company would be bankrupt and they wouldn't have a job.

Not all cool things are desirable things.

I suspect that the java-like methodology of downloading small apps to
users can be done securely, but the java model doesn't feel like the
right way to do it, at least to me.

Perry

> 
> I suspect that the java-like methodology of downloading small apps to
> users can be done securely, but the java model doesn't feel like the
> right way to do it, at least to me.
> 

  I agree with you. However, I think the only way to get a handle on
what the security issues are of such a methodology, is to deploy one
and see what happens. Then you can build a second generation 
environment based on that knowledge. There's also the issue that
even if the environment is secure on paper, with an application as
large as a browser and an execution environment, you can never
know if it was implemented properly. Sendmail-like bugs could haunt
the system for years. That's why its good to deploy it early, fix all
the big holes discovered as fast as possible. At minimum though, I think
Java should atleast run chroot()ed on Unix systems. Instead, their 
approach is to define a "writable" directory on disk that apps can write 
too. This does make me nervous because I can see the potential to send 
over a program to be compiled and executed. I don't know what you would do
under the MacOS and Win95 to make it secure. There is also security
at the meta-applet level. Even if you chroot() Java to some directory
where applets can write to, one applet can destroy another's data. If
the data saved by one applet is valuable to you, like hotlist settings
gathered over months, a rogue applet can trash them. But sometimes
applets need to be able to read/write each others data so you can't
just disallow it. So HotJava should have a access protocol for applets
too. The Java team could learn a lot from the experience LambdaMOO.

-Ray

Ray writes:

|   Object Oriented Superdistributed components are so useful an abstraction,
| I think it's worth the security risk. HotJava solves some fundamental
| issues with protocols. Right now the W^3 working groups have been struggling

	Its nice of you to say that.  Its nice of Perry to disagree.
Lets start using some concrete examples, so the source of
disagreements become obvious?

	I suspect Ray is working in an environment less security
concious than Perry's.  Perry works on a lot of security-critical
applications where a lot of money is at stake.  If I were going to go
after financial institutions, I'd definetly look at which ones were
using Java, and see what I could upload into their systems.  Getting
copies of the recent files might be *very* informative.  I'd be
worried if I were at Solomon brothers.

	If I were running Java at home, I'd be a lot less worried,
especially as all the interesting data on my hard drive sits on an
encrypted partition.

Adam


-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

Adam Shostack writes:
> 	If I were running Java at home, I'd be a lot less worried,
> especially as all the interesting data on my hard drive sits on an
> encrypted partition.

Not everyone is so careful. To most people, their personal financial
information, especially if it allows embezzlement from their accounts,
is probably as valuable to them as a banks's information is to
them...

.pm

> 
> Ray writes:
> 
> |   Object Oriented Superdistributed components are so useful an abstraction,
> | I think it's worth the security risk. HotJava solves some fundamental
> | issues with protocols. Right now the W^3 working groups have been struggling
> 
> 	Its nice of you to say that.  Its nice of Perry to disagree.
> Lets start using some concrete examples, so the source of
> disagreements become obvious?
> 
> 	I suspect Ray is working in an environment less security
> concious than Perry's.  Perry works on a lot of security-critical
> applications where a lot of money is at stake.  If I were going to go
> after financial institutions, I'd definetly look at which ones were
> using Java, and see what I could upload into their systems.  Getting
> copies of the recent files might be *very* informative.  I'd be
> worried if I were at Solomon brothers.

  If a business wants high security, they probably shouldn't be running
anything but mail. Even allowing users ftp access is dangerous
because someone could download a trojan horse. My college  took
the /exec function out of IRC for this very reason. If data can 
get  through a firewall by any means, DNS, mail, etc, it's possible to write
some kind of program to send stolen information on those channels. Hell,
there is a big enough problem with users bringing software from home
into work and infecting company networks with viruses.
  
  I work in an environment which is very security conscious (IBM Watson 
Research). You should see how paranoid their virus lab setup is.
And I'm frustrated by not being able to run stuff from work I run at
home because of the firewall. I probably shouldn't be running the
stuff at work anyway, but I can't pass up having access to a T1/T3
net connection on my desk. I have no problem with security, as long
as it is user friendly. If everyone had to manually run PGP from the shell
to post a message to cypherpunks, would there be many posts? 

  At home however, I have full control over my environment. I don't
avoid all potentially dangerous software, because for me, the benefits
outweigh the risks. I have never seen the source code to DOOM's
internet drivers, so I have no way of knowing if data is being stolen
or downloaded to my harddrive. I would rather choose to encrypt
the harddrive, and run the software in an alternate partition even though
this still doesn't guarantee safety. I know people who go farther such
as swapping HD's in-and-out depending on whether they are in "fun, 
experimental computer use mode", or "serious, money risking mode"
But ultimately that decision is up to me. Most of the people who will
be running HotJava are users in non-corporate environments. 

  Once you actually browse some HotJava web pages with HotJava, the
ordinary Web becomes static and boring. It's like the difference between
ftp and Netscape, or TinyMUD and LambdaMOO. There's just so much
potential, especially for crypto-clients. Because Java provides a
single development platform, single execution environment, GUI, and
network access.
 
-Ray

Ray wrote, responding to me:

| > 	I suspect Ray is working in an environment less security
| > concious than Perry's.  Perry works on a lot of security-critical
| > applications where a lot of money is at stake.  If I were going to go
| > after financial institutions, I'd definetly look at which ones were
| > using Java, and see what I could upload into their systems.  Getting
| > copies of the recent files might be *very* informative.  I'd be
| > worried if I were at Solomon brothers.


|   If a business wants high security, they probably shouldn't be running
| anything but mail. Even allowing users ftp access is dangerous
| because someone could download a trojan horse. My college  took
| the /exec function out of IRC for this very reason. If data can 
| get  through a firewall by any means, DNS, mail, etc, it's possible to write
| some kind of program to send stolen information on those channels. Hell,
| there is a big enough problem with users bringing software from home
| into work and infecting company networks with viruses.

	FTP is available by mail.  So is web access.  Marcus Ranum
(formerly of TIS) has written a TCP/IP over SMTP. (He doesn't
distribute it.)

	The problem of securing a network in this environment is a
very difficult one.  Parts of it can be shown to be hard, although
partial solutions are possible.

	I suspect the risks are enhanced by easy to use clients, as is
the productivity of the workers.  Many experts recommend studying each
service and deciding whether or not to allow it based on a risk
assesment.  The size of Java makes it tough to evaluate, as does its
extensible nature.  I'm tempted to agree with Perry that its too big
and doesn't have enough fail-safes yet.  I'd be much happier if the
Java execution environment did a chroot() before running any code, and
code went to the executor through a one way funnel.  Making this
funnel truely one way limits the nifty things you can do with Java
substantially.

|   Once you actually browse some HotJava web pages with HotJava, the
| ordinary Web becomes static and boring. It's like the difference between
| ftp and Netscape, or TinyMUD and LambdaMOO. There's just so much
| potential, especially for crypto-clients. Because Java provides a
| single development platform, single execution environment, GUI, and
| network access.

	No argument here.  I think Java is way nifty, and might be
enough of a killer app for me to upgrade to a powerPC mac.

Adam


-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

Reply-To: perry@piermont.com
   X-Reposting-Policy: redistribute only with permission
   Date: Fri, 28 Jul 1995 10:10:59 -0400
   From: "Perry E. Metzger" <perry@imsi.com>
...
   I exagerate only slightly. I don't believe Java to be secure, in spite
   of the claims. Its too complicated, and it operates in an environment
   who's correct operation is required for it to remain secure. Good
   system design says that you want a system's failure mode to produce a
   secure result, but thats not what Java does.

   Perry

How would you make Java secure or create a secure Javalike language?
(Secure to your satisfaction, of course).

I don't even play a security consultant on TV, but would removing hooks
into X-windows (if it has them; I don't know if it does, although Ray
mentioned something about how it could open multiple windows with graphics
in them, I think) be a good start?

What sort of interface does it have to the filesystem? I would guess that
a secure language would have its own filesystem mapped to a file of fixed
size in the normal filesystem, so that it couldn't cause disaster by
filling your hard disk.

Does it have that?

Phil

Phil Fraering writes:
> How would you make Java secure or create a secure Javalike language?
> (Secure to your satisfaction, of course).

Well, you can't make anything secure, but you can make things more
secure.

My fundamentnal design principles are:

1) You can't abuse features you don't have.
2) You can't abuse privs you don't have.
3) You can't catastrophically fail to do something you don't do.

I would eliminate the notion of having the Java interpreter make the
system "safe" with language features that cripple certain threads of
execution. Instead, I'd emasculate the whole system. Remove any i/o
features right out of the interpreter -- ditto execution features or
other features. I'd run the interpreter in a separate unix process
communicating only through two pipes, one down which you feed code and
mouse events and one up which you get bitmaps and URLs to fetch. The
interpreter runs in a padded cell and can't alter the world except by
passing up bitmaps and URLs. It doesn't talk to anything other than
the browser.

Even then, I'm not entirely comfortable, but I'm more comfortable.

> What sort of interface does it have to the filesystem? I would guess that
> a secure language would have its own filesystem mapped to a file of fixed
> size in the normal filesystem, so that it couldn't cause disaster by
> filling your hard disk.

Thats not a secure system, because you depend on the interpreter
properly doing the mapping. If there are no system calls to open(2) in
the whole program it can't misuse any of those calls. If there are no
calls to exec, it can't mis-execute things. Security through emasculation.

Perry