Re: 50 attacks on Netscape - please send the check

fc@all.net (Dr. Frederick B. Cohen) writes:
>50 Attacks: a.k.a. Why Not to Run Hot Java in your netscape (or other) browser:
> ... (drivel elided)

This fellow seems to be systematically (if not deliberately) ignorant
about these things.

One of my co-workers reviewed his book on computer viruses in IEEE
Multimedia and noted that it manifests many of the same fallacies. You
can read it (the review, not the book) at

http://www.communities.com/paper/itsalive.html

--
-------------------------------------------------------------------------------
| Chip Morningstar                     |                                      |
| Electric Communities                 | "I'm old enough to be living in      |
| 280 2nd Street, Los Altos, CA 94022  |  the future I was warned about."     |
| 415-917-5640                         |         -- Myron Krueger             |
| chip@communities.com                 |                                      |
-------------------------------------------------------------------------------

> 
> fc@all.net (Dr. Frederick B. Cohen) writes:
> >50 Attacks: a.k.a. Why Not to Run Hot Java in your netscape (or other) browser:
> > ... (drivel elided)
> 
> This fellow seems to be systematically (if not deliberately) ignorant
> about these things.

  I'm frequently seeing this same behavior by lots of people on
this list and it's sad. There are people making claims about
HotJava/Java that are obviously bogus if you even read the white paper,
looked at the source code, or programmed a "Hello World" applet.
The Java papers are an easy read.   If you want to know about the
implementation, read the source. At least criticize specifics about
the implementation rather than speculating what they are and then
proceeding to claim to have found a security hole in the implementation.
I'm even more surprised when I see someone with a Phd acting like
this.

-Ray

Earlier on, when the Java threads started, I posted several responded to 
a post like this explaining why java theoretically protects against 
attacks like the ones mentioned, and suggested what parts of the code 
need to be examined/attacked to violate the security assumptions. 
Everybody here knows what you can do if you can execute any code you 
want; to show a breach you must show that the code you want can be executed.

Although I wouldn't put money on the current implementation of the Java 
VM is 100% perfect, I am pretty confident that a fully trusted VM can be 
built (the instruction set and type verifiers are very simple and 
conservative). Adding in the garbage collector and the thread system may 
make things more complicated, but hopefully these factors won't make 
things too bad. 

Once you have a trusted VM and core runtime, all you need to do is add 
once the run-time classes you need and are able to verify to your desired 
level of trust, and you have a reasonably trusted language to write your 
programs in. This, and several other features of java should make it 
easier to write trusted code.

	1) Exceptions. Java has exceptions, and like CLU on prozac, nags 
	   you if you don't explicitly catch or pass thru them. Errors 
	   which are ignored are a very common cause of security holes.
	2) Bounds checked arrays. Can't overflow, making the world safe 
	   for stack frames everywhere.
	3) Garbage collection - no leaks, and no use of freed memory.
	4) Real access protection  for private members - easier to make sure
	   info isn't leaking if all access is mediated through a single unit.
	
Hmmm. What other features would be good for writing trusted code like 
network servers? Anyone got any cites on language issues and security? 
That don't involve ADA :-)?

Simon


----
(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1) 	((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))