Re: Mobile Code Security???

["Marcus J. Ranum" <mjr () nfr net>]

>        I'm curious as to the groups opinion on Java, JavaScript, ActiveX ,
>        or more generally - mobile code secuirty technologies.

Looked at in the abstract, mobile code (which I prefer to call
"downloadable code") brings us face to face with the problem of
trusted software distribution and trusting software distributors.
Neither one of those is a pretty problem and folks in the past
who have tried to deal with them have spent a lot of money and
known a lot of pain.

How is it different, from 30,000 feet, to download a java applet
from my site and run it, than to download linux and run it? Or
to buy a copy of Windows NT? In all of those cases, a Bad Guy
may have planted Bad Code in your software. The difference, when
you get below 30,000 feet is that you have different amounts of
trust in the provenance of the code and their coding practices,
as well as different amounts of belief that you KNOW the origin
of the code. Is a Windows patch more "trustworthy" if it comes
from www.microsoft.com, or from www.joesdownload.com? Not really.
What's going on here is that our expectations are different.
I don't think, in this area, that our expectations make sense,
but that's what they are. It's probably because "trust nothing,
everyone is your enemy" is too mentally and technically
expensive as a computing model. Most people want to Get The Job Done
and don't have time or energy to worry about attack applets,
or Mossad trapdoors in their firewall, or NSA trapdoors in
Windows NT.

So, back to 30,000 feet: I like the Java sandbox model. I kind
of wish I could run general Windows applications in a sandbox.
Then I wouldn't have to have this dorky virus scanning software.
At 30,000 feet, my virus scanning software is a patched-in
sandbox for windows, right? On "real" operating systems, like
UNIX, the O/S has a sandbox of sorts: file permissions, protected
devices, virtual address spaces, and a nice clean system call
boundary that keeps user code out of kernel space. UNIX has had
its share of flaws in its sandbox, just like the flaws in
Java's sandbox: weird parameters to certain system calls could
step on uid values in kernel space, etc.

I believe the reason that attack applets are scary, while
trojans in NT are not, is because of the degree of anonymity
that inherently cloaks the attacker. If there was a trojan in
NT, there'd be hell to pay. But everyone would be in the same
boat, so nobody'd point at an individual victim and say "you
screwed up, you FOOL!" Also, whether it was their fault or
not, Microsoft would be held accountable. With an attack
applet, there's no perception of accountability, and the
victim will usually be unique within their area. I suspect
that a lot of the fear of attack applets comes from the idea
that they might get caught from a porn site. Honestly. Let's
say I am at www.hotandslippery.com and my machine suddenly
blows up. Uhuh. The sysadmin is going to ask "what site did
you get that from?" and I am going to be hosed. Better just
reformat the hard disk and say I had a virus. :)

To get our work done, we have to run code from other people.
Therefore we are vulnerable. The question is "which other
people?" The Web, and active content, makes it really easy
to blur the line. At this point, I think of the problem
as akin to shark attack. There is a nonzero probability it
will happen. It's a low probability, on an individual
basis. If it does happen, it'll Suck Real Bad. But I'll
either recover or die. :) Which brings me to the best defense
I can think of: be prepared to resume your business.
I'm wondering if fast recovery will ever replace security
or direct defense as an approach to business resumption.

Anyhow - downloadable content? I think ActiveX is dead/dying.
Java is in trouble, and Javascript isn't in great shape, either.
Something else will come along soon and it'll probably have
lame security, too. :) All things being equal, I wish that the
browser boys had thought to just download C code, then do an
on-the-fly compilation and link against a "sandbox" shared
library. It'd have been easier, every bit as portable, and
fast. Live'n'learn. I'm waiting for O/S to start having more
support for SeOS like sandboxes for runtime execution. Then
the next challenge becomes system management: if managing a
system is hard, managing a system full of virtual sandboxes
is harder.

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr