Let me try to discuss this from the point of view of a firewall vendor
and as someone who has wrestled with this problem time and again
from a site and system policy standpoint.
I believe Mark Ryland's comments skip over a key point. I agree
with many of his facts about possibilities, but not with their
implications.
Yes, blocking specific forms of executables provides no absolute
protection. But in today's computing environment, absolute protection
is mutually exclusive with Internet access. And escalating security
threats are mutually exclusive with worthwhile growth of the Internet.
But security has to be put somewhere, and so far desktop software
producers haven't seriously addressed it.
Basically, I believe more control should be given to the recipients of
messages, documents, and files. Too much is given to creators, and the
whole problem is that good creators aren't easy to distinguish from
bad or even malicious ones. It falls to responsible desktop software
developers and (in the near term) to firewall providers and anti-virus
developers to restore the balance.
For most people, the only computer security thing that matters is
assurance that their computer only do things they explicitly direct it
to. If it sends a bunch of payments to CheckFree, it's because the
owner filled out the checks and pushed the buttons. If it deletes a
bunch of files or reformats their disk, it's because the owner wanted
it to happen and told the system to do it.
When we pull something in from the Net we are relinquishing some
control to the outsider providing the content. Decent browsers leave
us with some residual control, like the ability to abort a slow and
unpromising document before it's finished. But the most that the html
will do is use up disk cache and waste our time. It's not going to
modify stuff on our systems behind our backs. There's nothing in http
to leak arbitrary data out of our systems, either. (At least, not
by design.. I know there are defective client implementations).
I don't believe the problem is executable content per se, because I
see html as a sort of "executable" script, too. The crucial difference
is that http doesn't have dangerous functions. There's no problem
relinquishing control unless there's a risk of unintended side
effects. People don't browse the Web looking for a chance to have
their filesystem wiped out.
The problem with the latest crop of "executable" Web languages is that
they unnecessarily include dangerous and destructive functions. You
don't need to diddle with a user's files to do animation on the screen
or to display dialog boxes or rows of pushbuttons (if you do,
someone's language design is really broken).
Perhaps these destructive functions give the inventors a feeling that
they've built something "serious" and "general purpose." But it also
provides the entering wedge for malicious pranks and, eventually,
systematic subversion of internal computer activities.
That's why firewall developers are installing filters and blockers for
executable contents. It's not the executable that's bad, it's the
unnecessarily excessive capabilities of the underlying languages.
We've already installed several dozen special purpose systems that
detect and block the transfer of executables through MS Mail. Certain
MS Mail versions have this silly button that lets the recipient
execute a binary attachment instantly with a single push. The sites
think it's risky behavior to let them run the executable without any
integrity or virus checking ahead of time. Some of these sites have
even taken to blocking MS Word and spreadsheets. These applications
typically run their macros automatically, giving the recipients no
chance to examine the macros before it's too late.
It's mostly a question of giving control to the recipients instead of
leaving all the control with the creators.
Rick.
smith @
sctc .
com secure computing corporation
|
|
