l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2001 Dec 30 17:05

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] What anti-virus tools available that run on Linux?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] What anti-virus tools available that run on Linux?


I have had an arguement before with another user on this list on the topic
of Linux and UNIX viruses. This time, I'll give more data on this, as
Linux can be affected by viruses.

Blanket statements of them not existing, or not a problem are risky as
they are absolute in their mention and may give a sense of false security
or misinformation to new users.

(Please see comments below including URL to discussion of UNIX and
existing *nix Viruses...)

On Wed, 27 Jun 2001, Micah Cowan wrote:
> On Wed, Jun 27, 2001 at 02:59:54PM -0700, Donald Dunn wrote:
> > What anti-virus tools available that run on Linux?
> > Please name your favorites.
> > 
> > Don Dunn
> There are two ways to interpret this this, and I'll address each of
> them.
> 1. You mean tools to protect against viruses (yes, that's the correct
>    term.  Virii isn't a word.  Viri would be correct also.) that are
>    harmful to Linux systems.
> There aren't any viruses for Linux, so no useful virus protection
> software can exist.

This is the major point I'd like to address. I have commented on Linux and
UNIX based virues before, and included references to source code viruses,
and others also mention in Professor Ludwig's books that can attack x86
Linux based systems. (Most are quite architecture dependent.)

(I have mentioned to a LUGOD list before that I met with a small group of
coders about 2 or 3 years ago at DefCon to discuss the theory of Linux
based viruses. We quickly came to the conclusion it was quite possible.)

Here is one additional URL to reference risk. (Some people dont believe a
person until they can read data from another person.)


It is a good read, and quite a joy-ride. Perhaps even a story to keep you
sysadmins awake at night. In particular, look at the last one on that
page. Most require root access, but some may allow a user to infect binary
files if they have write access to them - no need to be root if the user
has group membership to write to a binary file with group write
permissions in their group! Once the binary is infected, if root runs it,
then all files are now open. Game Over. (Local security limits and write
access limited to root or non-shared damon groups with users can avoid
this well.)

Last on this area... Just as the bind/named based worm was used to execute
a bit of code, that (payload) code could have just as easily been a virus
(choose one from that page) and when a named process running as root is
infect by code inijection of the virus, it now can infect any files it can
see. a chroot-ed env can assist to some extent, but with kernel access as
root, a skilled user may find ways to address files not on their mounted
chrooted location.

I will admit that the present risk for infection in Linux systems is low
based on *history*. Howver, Linux as an OS is not immune to viruses. "Wild
type" viruses for Linux are rather *uncommon* (Sorry! How about very rare
and close to endangered?. ;-) Quite rare at present, but that is not
excuse to not follow the second poster's suggestions on avoiding
potentially damaging code on any OS.

> There have been many recent news articles contradicting this, but they
> didn't have their facts straight.  In particular, the so-called
> "cross-platform" virus is not a virus at all, at least not on the
> Linux side.  It requires you to download an attachment and physically
> run it, as root, manually.  This is very clearly a trojan, which is
> extremely different from a virus.  This sort of attack has always been
> possible, and the very easy protection against it is:  *never*
> download and run unknown executables as root (duh!).

Quite good advice. :-)


> The other 'virus' I am aware of is the one that was affecting RedHat
> machines with a (I think it was) vulnerability in BIND (yet *again*).
> This may qualify as a virus, but I think it's more of a worm (Pete
> will correct me if I'm wrong).  It exploits a buffer-overflow in BIND
> and the fact that it runs as root.

Yes, the purist would likely classify it is a worm, but a generalist may
include trojans, worms, and other code run without intention of being run
as a general category of "virus". Many applications that are "AntiVirus"
software will also check for the other (purist) types, but the software is
still not called "anti-worm,anti-virus, and anti-trojan software", but
instead called "antivirus" as the marketing groups from companies seem to
generalize instead of purify.

Also, present discussion of theoretical virus code and virus code that
exists, but not in the wild exists and may pass by present systems used by
anti-virus software - except those that start with a "clean
system" (assumed) and then have antivirus software that uses several
fingerprinting systems in parallel for each file and interrupt any writes
to files that are executable. This however makes software updates rather
difficult. ;-)

> The last one is a more serious threat, but should not affect home
> users.  The only people who ought to be running BIND are sysadmins.
> This, too, could be avoided with a small amount of intelligence.
> Linux can be completely protected from viruses by following a few
> simple rules:
> 1) Use difficult-to-crack passwords - no dictionary words or names;
>    use a combination of letters, numbers and punctuation and make it
>    at least 8 characters long.  Use alternative authentication
>    methods to passwords if you can.
> 2) Never run anything as root unless you are sure of its functionality
>    and origins.

Though I do very much agree with the above #2, it can be time consuming to
check packages as well as would be desired. :-/ (A detailed review would
include examination of all source code. I don't know of anyone who has
enough time to do this even for just the kernel! It is a matter of
choosing a level of review that is manageable.)

> 3) Even if you are sure of its functionality and origins, never run
>    anything as root unless you *absolutely* have to.  If you must,
>    then take reasonable precautions: chrooting is always a good idea
>    (and would make the BIND worm problem above go away).  If it's
>    something as simple as needing root for something such as a
>    privileged port, discard your root privileges as soon as possible
>    after you've obtained the necessary resources.  It drives me crazy
>    that network services still exist in common use that run as root -
>    the whole thing.  The frequent security problems in Sendmail and
>    BIND would not have happened if people had been a little more
>    cautious in their treatment of god-mode.
> 4) Use strcpy, strcat, sprintf very cautiously, if you're a C
>    programmer.  Use gets() absolutely *never* at all (use fgets()
>    instead).

This good! :-)

> 2. You mean software that runs on Linux that protects *other* systems
>    from viruses.
> There exists software for this, but I am very unfamiliar with it -
> largely because it's fairly trivial to write scripts for the mail
> system which will automatically reject mail attachments with certain
> MIME-types or filename extensions.  If you scrap all .vbs, .js,
> etc. scripts, and redirecting html messages, you'd have no problems.

There was a commercial product made by Virex or some other company that
could be installed as a package with a pre Debian 2.0 (1.3?), but required
you to provide the commercially purchased files during package
installation. It allowed you to scan your local filesystems for known
virus code for multiple OS all on your linux mounted filesystems. It did
not take off too well, and I do not know of its status at present.

Many people that use Linux as a file server for both Macs and PCs have
just opted to scan for viruses over the network using a standard client
machine. This can take for ever and is not ideal, but running AV software
*on* your busy file server can also bring it to a crawl. Tough decision.

The procedural suggestions offered by the original poster are some of the
better thoughts on anti-virus: prevent infection in the first place.

Other products you may want to check out include things like tripwrie to
watch for weird file changes. There are other applications out there that
will inform you of files that have changed. You can also perform periodic
binary compares of your filesystem with a "clean copy" of your filesystem
binary files to see if any files are inconsistent with the original
installs - suggesting a modification.

Anti-Virus techniques and systems are difficult to address as the target
continues to move. What is good today, may be foiled tomorrow. Perhaps
this information is now obselete... tick tick tick...

Thanks for reading!
(No disrespect to the follow-up poster who included some very good


Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ 
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html
     Systems Department Operating Systems Analyst for the SSU Library

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.