Re: java security concerns

>Sendmail is about 29K lines of C code -- not significantly larger by
>my standards -- and has proven nearly impossible to secure.

Good point.

>Sendmail performs a much simpler task and has not proven secure.

I don't necessarily agree. The core java interpreter is simply:
	while (1) {
		get_next_opcode
		switch(x) {
		}
	}

> ... Marcus Ranum has noted that you can't
>trust a program thats bigger than a couple of pages long, and I
>believe he's right.

Its a useful metric. But the concept of trust isn't defined. If
you write in pure Java code (that is no references to any native
methods) we should be able to do much better than that. 

And since Java doesn't have "programs" it just has "classes" and
many of those fit on two pages where does that leave us? Would it
be reasonable to say that if I want to write a Java class I trust
I should keep it under two pages? If I then write another class 
that uses that class, that is also under two pages have I met
the requirement? Can this aggreagate four page Java class be trusted?

>As an aside, have you tried breaking your own program? Spend a week on
>it some time. Its usually an educational experience and it breaks you
>out of the mindset you have fixed in for a while.

Many times. 

>As people have found out, it has proven possible to core dump the Java
>interpreter. That means that your implementation has contained flaws
>that potentially permitted people to do unplanned things to the state
>of the interpreter.

I agree.

>By the way, I suggest that Sun should offer a large money prize for
>the first significant security hole found the Java implementation. Its
>a tiny price to pay for security.

I don't think the lawyers would let us. 

Would anyone be interested in a Java daemon that one could send arbitrary
classes to in an attempt to subvert the runtime? I once thought this would
be a good way to give safe exposure to the system in general. You know sort
of "here's a program that can feed classes to a Java runtime on a system
which is known to have a file X on it. Try to return the contents of X."

It probably wouldn't be to useful beyond that, and it would only validate
the classes you have access to, not necessarily the full set in a release.
(hence my not doing it given its utility only in testing the core runtime)

--Chuck

Perry:
>By the way, I suggest that Sun should offer a large money prize for
>the first significant security hole found the Java implementation. Its
>a tiny price to pay for security.


Chuck:
> I don't think the lawyers would let us. 
> 

	This is a shame. What reason would they have for not letting
you? It could well be a very good marketing move. Maybe your marketing
dept can convince the legal dept.

> Would anyone be interested in a Java daemon that one could send arbitrary
> classes to in an attempt to subvert the runtime? I once thought this would
> be a good way to give safe exposure to the system in general. You know sort
> of "here's a program that can feed classes to a Java runtime on a system
> which is known to have a file X on it. Try to return the contents of X."
> 
> It probably wouldn't be to useful beyond that, and it would only validate
> the classes you have access to, not necessarily the full set in a release.
> (hence my not doing it given its utility only in testing the core runtime)
> 

	That, and a cash reward for getting the contents would be even
better. 

-- 
sameer						Voice:   510-601-9777
Community ConneXion				FAX:	 510-601-9734
The Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer@c2.org

I think to require formally proven implementation for something
like Java is simply unreasonable. Even if it were possible. The
whole computer market, and for that matter, most of the market as a
whole, relies on "unproven" products. Most of what you buy and use is
based on a notion of "quality" which is merely an inductive argument
that the product had no problems in the past. Everytime you buy a piece
of software and use it, you risk your security. Everytime you ftp
something off the net and run it, you are taking that risk. How do you know 
MS Word doesn't have security holes or trojan horses built in, have you 
seen the source? Software always has bugs, holes, and security flaws. It 
always will. If we were to require each new generation of software to be
"formally correct", software would never evolve. There is an important
feedback process between customers, software companies, and even
hackers, that drives software towards higher quality. Perfect software
implementations proven correct by mathematics is a pipe dream. Maybe
you can have higher confidence in small, simple software -- I've heard
Negroponte expressing that nostalgia for the days of word processors
that ran in 32k of ram, but frankly, I'm glad those days are gone.

   Will the IPv6 and IPSEC stack implementations be formally proven 
correct?   

  Yes, it may be possible that exploiting holes in Java will be easier
than those in sendmail, just as it is easier to exploit a hole in 
software on a networked machine rather than a non-networked one. But this
can not be an argument against Java or its utility. The same arguments
were raised when Postscript first came out, yet the huge benefits
of postscript are obvious, while the amount of security damage
done by it is minimal. Java will have lots of holes. It will go through
the same evolutionary progress that all software does. Sendmail was
given a chance to evolve, I think Java deserves the same
chance, given its potential.

-Ray

Ray Cromwell writes:
>   Yes, it may be possible that exploiting holes in Java will be easier
> than those in sendmail, just as it is easier to exploit a hole in 
> software on a networked machine rather than a non-networked one. But this
> can not be an argument against Java or its utility. The same arguments
> were raised when Postscript first came out, yet the huge benefits
> of postscript are obvious, while the amount of security damage
> done by it is minimal.

Postscript is completely safe if the interpreter is emasculated, and
most of them are. (It is a huge risk when run on a non-emasculated
interpreter, but fortunately it is easy to castrate one of the things.)

Java isn't like that, unfortunately. I wish it was simply a
display-postscript like thing that built pretty pictures inside a
confined window -- I could trust that to be done right if it was done
carefully.

Perry

Iam sorry I dont fallow your logic. You find Postscript files
save because you can set up the interpreter to ignore Postscript commands
to write to files and execute programms (check the CIAC alerts), yet
you find Java applets insecure even when you can set up the same
restrictions and more under HotJava (and hopefully Netscape)?
That does not compute. Granted Java is certanly more complex than postscriptm
it a genereric programming language, and will be used by more people.
But that same concept aply.

Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5 
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01 

On Tue, 10 Oct 1995, Perry E. Metzger wrote:

> Postscript is completely safe if the interpreter is emasculated, and
> most of them are. (It is a huge risk when run on a non-emasculated
> interpreter, but fortunately it is easy to castrate one of the things.)
> 
> Java isn't like that, unfortunately. I wish it was simply a
> display-postscript like thing that built pretty pictures inside a
> confined window -- I could trust that to be done right if it was done
> carefully.
> 
> Perry
>

Aleph One writes:
> Iam sorry I dont fallow your logic. You find Postscript files
> save because you can set up the interpreter to ignore Postscript commands
> to write to files and execute programms (check the CIAC alerts), yet
> you find Java applets insecure even when you can set up the same
> restrictions and more under HotJava (and hopefully Netscape)?
> That does not compute.

Yes it does.

To (perhaps over)simplify my point, the Java interpreter cannot be
stripped of all i/o capabilities and still remain useful. I can
physically remove all the "dangerous" calls from a Postscript
interpreter and still have it be useful.

Perry

> 
> 
> Aleph One writes:
> > Iam sorry I dont fallow your logic. You find Postscript files
> > save because you can set up the interpreter to ignore Postscript commands
> > to write to files and execute programms (check the CIAC alerts), yet
> > you find Java applets insecure even when you can set up the same
> > restrictions and more under HotJava (and hopefully Netscape)?
> > That does not compute.
> 
> Yes it does.
> 
> To (perhaps over)simplify my point, the Java interpreter cannot be
> stripped of all i/o capabilities and still remain useful. I can
> physically remove all the "dangerous" calls from a Postscript
> interpreter and still have it be useful.

  There is a large class of Java apps that need no file i/o capability.
99% of all Java apps on the web right now don't save any persistent state 
information. I couldn't find any Java apps on the Java page that
used file i/o.  If by "stripped of i/o capabilities", you mean
that the Java interpreter is not permitted to ever call open/read/write,
not even to read in files it needs like config/preferences files or 
dynamically linked libraries, I'd say that's absurd. There's not many 
things that can be stripped of such capabilities, including postscript
interpreters, except for those which run the interpreter straight
out of rom. But it's still unclear whether those lack "i/o capabilities",
given that some postscript printers run operating systems and tcp/ip
stacks, and it is feasible for the interpreter to crash and execute
an i/o call. However, the Java interpreter can certainly be compiled
to not allow Java applets to ever do disk or network i/o. It doesn't
even take a recompile. Just delete the file i/o class.  

  It is certainly possible, to within a high degree of confidence,
to "box in" all i/o calls, especially if they are run in a separate
process. 

-Ray

Perry E. Metzger writes:
 > To (perhaps over)simplify my point, the Java interpreter cannot be
 > stripped of all i/o capabilities and still remain useful. 

?!?  What if all I give you is a couple of Java classes that write to
a frame buffer, and that frame buffer is the screen (or your 24-pin
dot matrix printer or whatever)?

 > I can
 > physically remove all the "dangerous" calls from a Postscript
 > interpreter and still have it be useful.

I don't see the difference.  An interpreter is an interpreter.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mike McNally writes:
>  > I can
>  > physically remove all the "dangerous" calls from a Postscript
>  > interpreter and still have it be useful.
> 
> I don't see the difference.  An interpreter is an interpreter.

I suppose most of this is dead obvious to me because I work in
security every day, but it seems that some otherwise smart people don't
see the point I'm making, repeatedly.

As an exercise to the reader compare the following two tasks in
difficulty.

1) Find a bug that lets you execute arbitrary programs unintentionally
   from a program that contains instances of the 'fork()' system call.

2) Find a bug that lets you execute arbitrary programs unintentionally
   from a  program that contains *no* instances of the 'fork()' system call.

[hint: it is much harder to get a program to do something that it has
no code at all to do than to get it to do a buggy form of a something
it already does.]

Perry

> 
> 
> Mike McNally writes:
> >  > I can
> >  > physically remove all the "dangerous" calls from a Postscript
> >  > interpreter and still have it be useful.
> > 
> > I don't see the difference.  An interpreter is an interpreter.
> 
> I suppose most of this is dead obvious to me because I work in
> security every day, but it seems that some otherwise smart people don't
> see the point I'm making, repeatedly.
> 
> As an exercise to the reader compare the following two tasks in
> difficulty.
> 
> 1) Find a bug that lets you execute arbitrary programs unintentionally
>    from a program that contains instances of the 'fork()' system call.
> 
> 2) Find a bug that lets you execute arbitrary programs unintentionally
>    from a  program that contains *no* instances of the 'fork()' system call.

   I agree, however I would point out that not all postscript interpreters
are emasculated (especially those on unix systems like IRIX, they contain
all kinds of calls to fork(), read()/open(), etc). Nothing in the
Java spec tells you that you must call fork() in a Java interpreter
implementation. In fact, Java has nothing to do with the GUI calls, the
network calls, etc. You can support as much or as little system
I/O in a Java implementation as you want. If need be, a Java
implementation could hard code all data needed from a hard disk into 
executable and run entirely in ram, and totally remove all file
system access. (except the implicit one needed to load and run
the executable in the first place) Even Java apps without network
or filesystem capability are useful (as graphic widgets), but I think
atleast the ability to load URLs is a good thing, and can be done
in a reasonable secure manner.

  Atleast from my reading of the Java Language Spec, and Virtual Machine,
there is no requirement that an implementation implement the File I/O
classes. Having a standardized class hierarchy is probably a good idea
though.

-Ray

Ray Cromwell writes:
>    I agree, however I would point out that not all postscript interpreters
> are emasculated (especially those on unix systems like IRIX, they contain
> all kinds of calls to fork(), read()/open(), etc).

Many postscript interpreters are a serious security threat. However, I
found it fairly easy to chop enough of the code out for the one I run
that I feel safe with it -- the exercise wasn't that hard.

> Nothing in the Java spec tells you that you must call fork() in a
> Java interpreter implementation. In fact, Java has nothing to do
> with the GUI calls, the network calls, etc. You can support as much
> or as little system I/O in a Java implementation as you want.

Yes, but in practice, to support the given applets that Netscape will
be browsing you have to open the kimono a bit too much overall. With
sufficient emasculation, I believe Java could be made safe, but then
it wouldn't be the Java that Sun and Netscape are pushing any more.

Perry

Perry writes:
> Ray Cromwell writes:
> >   Yes, it may be possible that exploiting holes in Java will be easier
> > than those in sendmail, just as it is easier to exploit a hole in 
> > software on a networked machine rather than a non-networked one. But this
> > can not be an argument against Java or its utility. The same arguments
> > were raised when Postscript first came out, yet the huge benefits
> > of postscript are obvious, while the amount of security damage
> > done by it is minimal.
> 
> Postscript is completely safe if the interpreter is emasculated, and
> most of them are. (It is a huge risk when run on a non-emasculated
> interpreter, but fortunately it is easy to castrate one of the things.)

I'm not clear on what you mean by emasculated.  It seems to me that
postscript interpreters are full of holes that can be exploited by
a cleaver enough attacker.

-- 
-> See: Info-Sec Heaven at URL http://all.net
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

>   I think to require formally proven implementation for something
> like Java is simply unreasonable. Even if it were possible. The
> whole computer market, and for that matter, most of the market as a
> whole, relies on "unproven" products. Most of what you buy and use is
> based on a notion of "quality" which is merely an inductive argument
> that the product had no problems in the past. Everytime you buy a piece
> of software and use it, you risk your security. Everytime you ftp
> something off the net and run it, you are taking that risk. How do you know 
> MS Word doesn't have security holes or trojan horses built in, have you 
> seen the source? Software always has bugs, holes, and security flaws. It 
> always will. If we were to require each new generation of software to be
> "formally correct", software would never evolve. There is an important
> feedback process between customers, software companies, and even
> hackers, that drives software towards higher quality. Perfect software
> implementations proven correct by mathematics is a pipe dream. Maybe
> you can have higher confidence in small, simple software -- I've heard
> Negroponte expressing that nostalgia for the days of word processors
> that ran in 32k of ram, but frankly, I'm glad those days are gone.

What you miss is the distinction between different kinds of programs and
their protection implications.

	Networking programs with unintended flaws may allow outsiders
	to gain access to your internal network and do harm.

	Non-networking programs with unintended flaws may fail to operate
	properly or act as a vector for the spread of corruption, but
	they don't give outsiders unlimited insider access without insiders
	somehow facilitating the process.

That's why we are far more concerned about networking programs that about
word processors.

	In terms of word processors with Trojan horses, we don't want
them either, but there's a big difference between a Trojan horse and the
ability to spread a virus.  Viruses can spread whenever there is sharing
and general purpose programming.  Hence, most modern spreadsheets, word
processors, Postscript interpreters, etc. allow viruses to spread.

	A big problem with remote auto-execution is that it allows
someone not authorized to use your computer decide to run a program on
it.  This may make you the unwhitting vector for a virus, cause your
system to crash, etc.  With auto-execution, the web turns from a
networked read-only database with limited searching capabilities into a
giant distributed processor in which the users have little or no control
over what their computers are used for.

The battle is for control over your own computer and what it does.

>    Will the IPv6 and IPSEC stack implementations be formally proven 
> correct?   
>
>   Yes, it may be possible that exploiting holes in Java will be easier
> than those in sendmail, just as it is easier to exploit a hole in 
> software on a networked machine rather than a non-networked one. But this
> can not be an argument against Java or its utility. The same arguments
> were raised when Postscript first came out, yet the huge benefits
> of postscript are obvious, while the amount of security damage
> done by it is minimal. Java will have lots of holes. It will go through
> the same evolutionary progress that all software does. Sendmail was
> given a chance to evolve, I think Java deserves the same
> chance, given its potential.

I don't see any huge benefits to postscript.  In fact, postscript files
are essentially impossible to search for items of interest, to display
on a normal video screen, to quote from without reentering the data, etc.

The point is, do we want to turn the Web into a distributed computing
environment in which anyone can eecute any code on anyone else's
computers?

	Don't assume I am against it - after all, I was the only vocal
	proponent of viral computing for almost 5 years and got
	villafied for it plenty of times. 

I am in favor of making the decision conciously, not by accident or
ignorance, and providing proper protection mechanisms.  If the question
of Hot Java is asked in terms of permitting all computers using the Web
to become part of a global viral computing environment, I am ready to
hear the answer.

-- 
-> See: Info-Sec Heaven at URL http://all.net
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

On Mon, 09 Oct 1995 17:30:38 -0700, cmcmanis@scndprsn.Eng.Sun.COM
(Chuck McManis) wrote:

> >By the way, I suggest that Sun should offer a large money prize for
> >the first significant security hole found the Java implementation. Its
> >a tiny price to pay for security.
> 
> I don't think the lawyers would let us. 

Pardon my French, but if your lawyers make it impossible to do
technical work correctly, isn't it time to get new lawyers?  I can't
see how offering a reward for reporting bugs could possibly be
objectionable to any rational lawyer.

This can be a VERY useful (and very inexpensive) debugging technique.
Didn't Knuth offer a cash reward to the first person to find each typo
in his "Fundamental Algorithms" series -- and then doubled the amount
each year?

It can also be a very useful teaching tool, in that it encourages
users to explore little-used corners of a system.

I applaud any company that has the guts to do it.

On Tue, 10 Oct 1995, John Lull wrote:

> On Mon, 09 Oct 1995 17:30:38 -0700, cmcmanis@scndprsn.Eng.Sun.COM
> (Chuck McManis) wrote:
> 
> > >By the way, I suggest that Sun should offer a large money prize for
> > >the first significant security hole found the Java implementation. Its
> > >a tiny price to pay for security.
> > 
> > I don't think the lawyers would let us. 
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I think this means they didn't ask.
If they did, perhaps the problem is their ability to say with a straight 
face that their product is "secure" while at the same time running a 
contest to find insecurities!

EBD


> 
> Pardon my French, but if your lawyers make it impossible to do
> technical work correctly, isn't it time to get new lawyers?  I can't
> see how offering a reward for reporting bugs could possibly be
> objectionable to any rational lawyer.
> 
> This can be a VERY useful (and very inexpensive) debugging technique.
> Didn't Knuth offer a cash reward to the first person to find each typo
> in his "Fundamental Algorithms" series -- and then doubled the amount
> each year?
> 
> It can also be a very useful teaching tool, in that it encourages
> users to explore little-used corners of a system.
> 
> I applaud any company that has the guts to do it.
> 
> 

Not a lawyer on the Net, although I play one in real life.
**********************************************************
Flame away! I get treated worse in person every day!!

On Tue, 10 Oct 1995, John Lull wrote:

> Pardon my French, but if your lawyers make it impossible to do
> technical work correctly, isn't it time to get new lawyers?  I can't
> see how offering a reward for reporting bugs could possibly be
> objectionable to any rational lawyer.

I agree; I sent private mail to the parties saying in effect "if your 
lawyer can't structure this, it's time to get a new lawyer."

A. Michael Froomkin        | +1 (305) 284-4285; +1 (305) 284-6506 (fax)
Associate Professor of Law | 
U. Miami School of Law     | froomkin@law.miami.edu
P.O. Box 248087            | http://www.law.miami.edu/~froomkin
Coral Gables, FL 33124 USA | New address, but it's still just as hot here.