Re: New Java Security Flaw Found

[smb () RESEARCH ATT COM (Steven M. Bellovin)]

At 04:49 PM 7/18/98 -0500, Greg Alexander wrote:
> Is it appropriate to call a java implementation-related security hole a java
> hole?  That'd be like calling a bug in pine a bug in internet e-mail.

As best I recall, all -- and certainly almost all -- of the "Java" bugs
have been implementation bugs.  And yes, it's perfectly fair to call
them "Java bugs", because in my opinion bugs of this nature are
*invevitable* in *any* Java implementation.

The fundamental problem lies in the very nature of the Java security
model.  The safety of the sandbox depends on a very complex set of
semantics, plus a very complex set of checks that have to be done at
runtime, all coupled with the lack of "system calls" in the Java Virtual
Machine.  Complexity is the enemy of security; here, security rests
entirely on a very complex structure.  I don't believe that it is possible
for implementors to get this right -- ever.

We thus have a situation where the nature of the environment is conducive
to bugs.  This is, of course, the same issue being discussed in another
thread -- C's suitability as a systems language.  It is certainly true
that one can write secure programs in C.  It's equally true that it's
harder.  A simple set of library routines, analogous to the String class
in C++, would have made life much better -- *if* it had been implemented
circa 20 years ago, when stdio was introduced, because it would now be a
standard part of the language.

My own research interests concern the question of how to make it possible
to write more secure program.  See
http://www.research.att.com/~smb/talks/odds.ps (or the corresponding .pdf
file) for some early thoughts.