[4746] in WWW Security List Archive
RE: Latest Java hole is Netscape/Sun only
daemon@ATHENA.MIT.EDU (Kris Virtue)
Mon Mar 10 04:14:22 1997
Date: Sun, 9 Mar 1997 23:30:20 +48000
From: Kris Virtue <kris@bioeng.ucsd.edu>
To: schemers@stanford.edu
Cc: "'WWW Security List'" <WWW-SECURITY@ns2.rutgers.edu>
In-Reply-To: <199703090624.WAA16150@tree2.Stanford.EDU>
Errors-To: owner-www-security@ns2.rutgers.edu
You have a good point here. I think all of us can liken your point
regarding trust to a good intentioned super user who accidently types rm -r.
Just because you trust someone does not mean something bad will not
happen. It's scary to think that major corporations want us to just take
thier word. Maybe MS should be thinkning about ways to make the net more
secure so that when they "trust me" we can really be sure it them who we
are trusting. Without that, what good is trust? Haven't they heard of
ip spoofing, etc? I can still send fake mail, make fake usenet posts,
etc. Heck, how do you even know this is really me talking? Maybe I am
some rouge programmer working at MS just using ucsd as a front...
- Kris
Kris Virtue Programmer Analyst
University of California, San Diego E-Mail: kris@ucsd.edu
Department of Bioengineering Voice: (619)534-3650
9500 Gilman Dr. MS 0412 Fax: (619)534-5722
La Jolla, CA 92093-0412
On Sat, 8 Mar 1997 schemers@stanford.edu wrote:
> Thomas Reardon writes:
> > Then let me make my own opinion known. First, Java still doesn't have
> > signing, other than announcement-ware. Sun, Netscape, Microsot and
> > others are working to address that.
>
> JDK 1.1 has signing and was released a few weeks ago. Obviously it
> won't see widespread use until the browser vendors implement it
> though.
>
> > As for your "who+what" assertion: The idea of capabilities-based-trust
> > is a complication, not a simplication for end-users. That is, once you
> > decide that you will depend on a trust-based system then that becomes
> > the anchor for your security model, its not really complemented by the
> > sandbox anymore. Sandboxes are great for *untrusted code*.
>
> I have to disagree. I don't care who signs what. Micrsoft could be signing
> IE for all I care, and it will still have the security holes. Once you
> have code signing and a capabilities-based-trust (which is coming, there
> should be a talk at Java One on it), then you have multiple lines of
> defense. Even if you "trust" the code signer, you might still want
> to restrict what it can do. Also, if you do trust the signer, you can
> also trust the signer to state the capabilties they intend to use.
> For example, if I'm running App XYZ, then App XYZ should only be able
> read files created by App XYZ by default, and even then, only in a
> certain directory. These capabilties can be included along with the
> signed bytecode, and instantiated when the applet starts.
>
> > And ActiveX
> > is absolutely only good for *trusted* code (where trusted code is
> > written&deployed within the firewall, or across the firewall via
> > identifiable publishers).
>
> Unfortunately there is no such thing as "trusted" code. Programmers
> will always make mistakes, and when writing in a language like C/C++
> there are plenty of ways to exploit those mistakes. Microsoft itself
> has shipped CDs with Macro viruses on them. How are you going to identify
> some ActiveX compoment that sets a timebomb that at some point in
> the future deletes your hole harddrive? Or changes something in the
> registry that loosens system security in other ways? Or makes your
> modem dial some 1-900 number?
>
> I also think that a capabilities-based-trust model extends well beyond
> downloading code over the network. It could/should be applied to
> all applications you run. Why should a program like "dir" be given any
> capabilites other then "read"? There is a longstanding design goal
> in security systems that operating with the least amount of privileges
> required to do something is always a *good* thing. There is currently
> no way to do that in an ActiveX world.
>
> roland
>
