[4774] in WWW Security List Archive
RE: Latest Java hole is Netscape/Sun only
daemon@ATHENA.MIT.EDU (Phillip M. Hallam-Baker)
Tue Mar 11 19:30:11 1997
From: "Phillip M. Hallam-Baker" <hallam@ai.mit.edu>
To: "'Adam Shostack'" <adam@homeport.org>
Cc: "WWW-SECURITY@ns2.rutgers.edu" <WWW-SECURITY@ns2.rutgers.edu>
Date: Tue, 11 Mar 1997 17:04:51 -0500
Errors-To: owner-www-security@ns2.rutgers.edu
>[Much other stuff, I'm disagreeing on a point of philosophy.]
> The language should not provide security, the system it runs
>on should. C is a marvelously insecure language, since it has *no*
>security constructs in it. However, putting it on a UNIX kernel,
>where the security of the system is handled by other tools (that
>happen to be written in C), allows us to write reasonably secure
>systems.
Adam raises a good point. There are two parts to Java, Java the
language and Java the O/S. Really they need to be considered
as different things. Perhaps if we call Java the language J++ it
would help :-)
> (Reasonably secure means far better than the 'security in the
>language' camp has done. Good enough? When you have an expert test
>the system, C code on UNIX can be pretty secure.)
I'm not big on testing alone as surety. Regardless of whatever claims
are made I will never believe Sendmail to be secure. I believe that
security has to start with architecture and design.
Java the language puts out of bound a whole class of security
problems that has plagued C++. Because Java has principled
string handling the buffer overrun issues that cause a large
number of C programs (finger, NCSA telnet etc) are put out of
bounds completely. I prefer that solution to testing for buffer overrun
vulnerabilities because testing of digital systems can never be
complete.
> Take the security out of the language, and the language
>doesn't need security. Put the security in a kernel, and you can make
>it small enough to be made trustworthy.
This is where I think a lot of the problems with Java will come.
Java is trying to be two things, language and O/S. That is bad,
the boundaries between the class libraries and the language
are muddy. Putting thread support into the libraries is a bit
antique for a modern language. The advantages of genuine parallel
languages have been well known for some decades. Its a pity
that instead of Hoare's monitors, work done in '77 they didn't look
at CSP, the work he did in '79. CSP is a vastly more powerful
model. Both the Java and Active-X camps would be well advised
to have a look at it.
Adam's suggestion to put the security in the kernel was pretty
much the suggestion made by Butler Lampson. If you want a
secure system make security the responsibility of one
component (aka the reference monitor), make that simple enough
to be checked. A good way of ensuring that it is simple is to use
formal methods to build it since nobody can build over complex
systems formally :-)
At present I'm a bit worried by the Active-X/Java security area.
Active-X worries me not so much because of their approach as
the difficulty I have getting a clear picture of what they are
attempting to achieve. I tend to get the feeling that they aren't
all that sure. Java worries me because the sandbox seems to
be security through assertion. The Java security model may be
OK for a thin client but that merely places the security burden
on the back end server and I don't see that end getting serious
thought either.
So, it looks like we won't be out of work for a while eh?
Phill
