[3110] in WWW Security List Archive
Re: New and destructive word macro virus
daemon@ATHENA.MIT.EDU (John Cronin)
Fri Sep 27 18:53:30 1996
From: John Cronin <John.Cronin@oit.gatech.edu>
To: CHESS@watson.ibm.com (David M. Chess)
Date: Fri, 27 Sep 1996 17:10:33 -0400 (EDT)
Cc: www-security@ns2.rutgers.edu
In-Reply-To: <199609271420.KAA694287@mailhub1.watson.ibm.com> from "David M. Chess" at Sep 27, 96 10:16:41 am
Errors-To: owner-www-security@ns2.rutgers.edu
Once upon a time, David M. Chess told me this tale:
->
->> From: hallam@ai.mit.edu
->
->> Viruses in general are an entirely unnecessary form of security hole
->> which is the result of inadequate system design.
->
->Disagree: in any general-purpose system in which one person can
->create programs that another person can execute, there is the
->potential for viruses. I have yet to see a system design that
->both prevented viruses and allowed programming. You can't get
->a virus in your microwave oven, but you can't program it either.
I have to partially disagree here. While it is theoretically possible
to write a virus for Unix for instance, for it to really do damage, it
would have to be run as root. If a non-root user runs a program that
contains a virus, it will only be able to infect that user's files, or
any files that are world writable, or writable by his group. Since
most system files don't meet this criterion, they cannot be infected
(unless root runs that same program). When somebody manages to bust
root, they are usually more interested in other things (running a sniffer,
creating trojan horses, etc). I have used Unix for 11 years, and I have
never had a virus or run any kind of virus scanner. A macro virus of some
kind would also only be able to infect the files on the user who has it.
However, when that user sends an infected file to somebody else (and thus
it effectively belongs to somebody else now) the virus can spread.
Still, it shows the advantages of a file system with a concept of different
users. While I would be the last one to tout the security of Unix, it is
more secure than Windows 3.1 and Windows 95. The verdict is still out on
whether it is more secure than Windows NT. I suspect they are about
equivalent.
->> The only Web security issue that arises is mechanisms to filter out
->> such formats at firewalls. I would recommend such steps for all
->> executable content, with the possible exception of postscript.
->
->That would certainly make the security problems (not just viruses)
->simpler! But the marketplace seems to have a strong hunger for
->executable content. I think we need to work on ways of making
->it secure, rather than wishing it would go away? I will leave
->to others the debate on whether or not it's actually desirable,
->or just a marketing-created hunger! *8)
We can make security much better if we get rid of the modems and network
connections. ;-)
Seriously, if we do away with executable content, then we are back to the
old client server, let the mainframe/server do all the work mentality. One
of the potential benefits of distributed computing is to spread the processing
burden around. Another benefit is letting servers do things they are better
at (raw data processing?), and letting clients do the things they are better
at (display and interface processing). You get better results by spreading
out the work, but of course security suffers. That means more work for us
(of course you could look at it as job security - if it was easy, who would
pay us?). I prefer the Java sandbox method to ActiveX run on the metal
method, for a number of reasons. Security is one, portability is another.
However, ActiveX will probably have a performance advantage over Java.
But I will leave that for another thread.
--
John Cronin
Office of Information Technology Customer Support Center 0710
Georgia Institute of Technology, Atlanta Georgia, 30332
Internet: john.cronin@oit.gatech.edu
phone: (404) 894-7563
