>
>1/ It is new from the user awareness perspective,
> "ouch, do I have to watch out who I'm accepting data docs from??"
Yeah, you do have to watch who the data is coming from if the data was
generated by and will be executed by a Microsoft application.
Of course, in the general computing community, the concept of "data" files
or email messages with executable components is not new, and those who
architect such languages properly build a "safe" subset of the language
intended for network transmission to arbitary recipients. For instance, Safe
TCL, Safe Postscript, ATOMICMAIL (MIME), etc etc.
These, and others, provide examples of sensible designers understanding that
languages can be built which allow for what is essentially a computer
program to be passed to a client system for execution, in a language where
either there are not enough primatives to allow system calls or
destructiveness, or where those operations cause a user-visible dialog to
appear which seeks their assent before continuing with memory or file
modifications (e.g. "I would like to create the file C:\COMMAND.COM, should
I proceed or abort?")
It seems that Microsoft are a major offender in ignoring the understanding
that providing powerful programing environments as attachments to documents
(VB seems to be their preference) causes major league security implications,
that exceed what "conventional" firewalls can do, and also exceeed what most
users expect - an Excel spreadsheet or a Word document with a "lurking"
Visual Basic application is, of course, just as dangerous when handed from
one office worker to another as it is when emailed in via a firewall.
In my view, one of the best ways to start to deal with this problem, in
addition to the (probably necessary) process of building heuristics into
mail gateways able to detect and block these things if needed, is to attack
the problem at its source - vendors who ship software that provides such a
wonderful vector for the transmission of malicious code should be beaten
about the ears until they understand that they need to define and implement
a "Safe" subset of the language and ship all their applications such that
they will not execute the "unsafe" operators unless the user explicitly
changes a configuration switch in their app to allow it.
Note that I'm not suggesting that Microsoft are the only folks who produce
application software with no obvious concern about data security and virus
protection, but they're probably the most visible offender - one whose very
success makes them important and worthy of having this issue waved in front
of them until they take notice of it.
I wonder how long it'll be before someone gets their corporate data trashed
and blames Microsoft for providing such a fertile vector for the virus to use.
Gnash. Gnash.
Simon
------------------------------------------------------------------------
"Simon Hackett, Internode Systems Pty Ltd" <simon @
internode .
com .
au>
Phone: +61 8 373 1020 Fax: +61 8 373 4911
Web: http://www.internode.com.au
Mail: PO Box 69, Daw Park, SA 5041 AUSTRALIA
Follow-Ups:
|
|
