[Wolves] Linux viruses

[Stuart Langridge]

On 6/12/2004, "Kevanf1" <kevanf1 at gmail.com> wrote:
>On Mon, 06 Dec 2004 11:12:18 +0000, Chris Ball <chris at mnemonik.net> wrote:
>> Correct me if i'm wrong, but wouldn't removing a linux virus involve
>> just scanning your home directory 99% of the time?
>
>That's my understanding too.  However, I think permissions also come
>into play.  I have probably set up permissions incorrectly on one of
>my drives.  In effect giving myself too many permissions for a user
>rather than root or SU.  That could possibly be a disaster area for
>other newcomers.  It can be a little too easy to give overall blanket
>permission for a certain drive or folder when perhaps only read access
>is really necessary.  I know, I have done this before and only
>realised when I have become a bit more experienced with Linux.  And I
>have a very, very long way to go yet :-)

Ade will almost certainly jump in here to comment on this, what with this
being one of his hobby horses, but the idea that a virus needs root
access to do stuff has the potential to be, I think, dangerously naive.

Think of it this way. A virus that is running as you, rather than as
root, can't damage any of the stuff that's installed on your machine;
none of the programs, none of the configuration files. That stuff,
though, isn't important. On a Debian box, for example, it can all be
reconstructed with one command: dpkg --set-selections < package-list,
where package-list is a list of all the packages you had installed.
It's standard, and it's known. You'll lose any specific configuration
you'd done on that machine, but, to be frank, there's not that much of
that anyway: most packages just install and work without too much
tweaking. Your home directory, though: that's another matter. Most of
us don't run as many backups as we should, up to and including people
who don't run any backups at all. Anything that wipes out your home
directory will cause much more irreparable damage than something which
wipes out /usr/bin, which can be perfectly reconstructed from your
distribution's install CD. A virus running as you can quite happily do
that: you have write access to your own home directory.

A second point, and one which is even more important in this day and age,
is that most "viruses" these days aren't actually viruses at all;
they're network worms. A network worm spreads by installing itself on
other computers: each machine infects 2 or 10 or 1000 others, and so the
worm spreads exponentially. Again, this can all work perfectly well as a
user: you, as a user, are perfectly capable of connecting to other
machines over the network and downloading or uploading a pacakge,
whether that package is a downloaded MP3 or a network worm executable.

This, of course, doesn't address the method of infection, called the
_infection vector_: how a virus actually gets onto someone's PC. The
history of virus attacks goes something like this:

1. Floppy boot sector viruses. The infection vector is infected floppies;
people share floppies, and the virus runs when an infected floppy is
inserted.
2. Infected executables. The virus hides in an executable program, and
when the program is run, the virus runs, as well as or instead of the
actual program. The infection vector is people sharing infected copies
of programs.
3. Executables sent in emails. The virus runs when someone explicitly
runs the program they've been sent, which is either a virus-infected
executable or just a virus (with no executable other than the virus
itself). Note that "executables" in this context could be a script
rather than a compiled binary program. The infection vector is these
emailed executables: note that a running virus can email copies of
*itself* to other people without any user interaction, *once you've run
it once manually*. Examples include ILOVEYOU.
4. Network worms. These spread by exploiting bugs in some kind of service
running on a machine which is listening to the network for connections.
These bugs allow the virus to send a copy of itself to the network
service and *have that copy be executed on the target machine* **without
user interaction**. These can spread entirely automatically, and infect
hundreds of thousands of machines in minutes. Examples include SQL
Slammer and Code Red.
4a. Executables sent in emails which exploit a bug in the mail client.
These are viruses sent in specially created emails which cause the
email, when opened in the vulnerable mail client, to be executed
*without further user interaction*. These are therefore a special case
of both (3) and (4).

1 doesn't really apply any more: people don't use floppies much. 2
doesn't really apply to Linux, for the reasons cited in the original
mail: a user can't generally infect executables on the system because
that user doesn't have write access to those executables: they are
owned by root. 3, 4, and 4a, however, make up the vast majority of
viruses today, and they are all perfectly possible on Linux. In order:

3. Executables sent in emails
Most Linux mail clients don't allow a user to double-click an executable
attached to an email and have it run. Instead, they insist that you save
the executable to the filesystem and then run it from there. However, if
you're prepared to do that, then infection can happen: the executable
can quite happily be a virus. The virus program can run, and can mail
copies of itself out to others and thus continue to spread. Addressbooks
for Linux mail clients tend to be stored in standard places and are
unencrypted: it would be trivial to write a virus which knew how to look
for the address books for Evolution, Thunderbird, KMail, and mutt, and
constructed a virus-bearing email to each person in any found address
books. The "speed bump" of having to save the executable to the
filesystem first is not much of a deterrent: pretty much every Windows
mail client also implements this now, making Windows no more (and no
less) vulnerable to a virus spread in this way than Linux.

4. Network worms.
These spread via bugs in listening network services. By definition,
no-one is invulerable to bugs. The general policy on these has been
*prevention*: minimise the number of listening services, don't let
arbitrary users connect to arbitrary services by hiding them behind a
firewall. Linux was historically very good at this, and some
distributions continue to be so: Ubuntu has *no* services listening in a
default install, for example. Windows was historically very *bad* at
this: many, many services were listening by default. Microsoft have
tightened up their act considerably on this, but they still have some
way to go. Nevertheless, any listening service is potentially vulnerable
to suvh an attack. Running services as an unprivileged user is also
useful-ish here: if a worm uses a bug in, say, Apache, and Apache is
running as the unprivileged user www-data, then it cannot destroy
root-owned things and additionally has no home directory of its own with
useful data, unlike real users. However, the www-data user normally can
make outgoing Internet connections, meaning that a machine infected in
this way can continue to spread the worm, even though the worm doesn't
actually damage anything on the machine itself. In fact, a machine can
be brought down simply by the number of worm processes running on it, as
has happened in the past.

4a. Executables sent in emails which exploit a bug in the mail client.
Again, this infection vector relies on bugs, but there is no real reason
why Evolution, for example, couldn't have a bug which executed an
attachment found in an email without further user interaction. It
hasn't happened so far, but that doesn't mean it's not going to. Once
again, this virus would be running as the user and would therefore have
access to destroy the user's home directory, as well as spread itself
over the network. This category includes things which exploit bugs in,
say, the system JPEG library, as well as those which exploit bugs in the
mail client per se.

Note that an executed virus *does not need to write to the disk* in order
to spread off the machine that it is on. it could be resident entirely
in memory, sending out infected mails or network probes, without ever
writing to the disk, once it has been executed one time. Such a virus
will disappear when the machine is rebooted, but Linux machines are left
on permanently more than Windows machines, even desktop workstations
(rather than servers), and even more so in te age of broadband. A virus
could also set itself up to run on reboot: again, a virus running as the
user does not have access to write to the system startup files (in
/etc/init.d or similar), but it could quite easily write to a user's
~/.profile or ~/.bash_profile or ~/.bashrc (which are run whenever the
user starts a shell) or ~/.xsession or ~/.xinitrc (which run whenever
the user starts an X session) or ~/.kde/Autostart (which runs when the
user starts KDE) or ~/.gnome/Autostart (which runs when the user starts
Gnome). All of these places are potentially somewhere that a virus could
put itself (or a link to itself) to ensure that it was restarted on
every reboot: none of them need privileges beyond that which the user
already has.

This has been a rather long document! The risk of viruses on Linux is
very real. The things we can do about it are:

a. User education.
Don't run executables mailed to you by friends. This is already going
on: people are learning this. Part of the complexity of this issue is
that a lot of things can count as an "executable" (i.e., they can run
some code, rather than just being data) even if you wouldn't expect
them to: Microsoft's Office suite has had particular problems in this
regard, since Office documents can contain macros (particularly
Autostart macros, which run as soon as the document is opened). The
distinction between "data" and "program" is increasingly blurred. In
general, Linux programs have been written so that they are very, very
careful with "data" documents that actually can contain program code,
mainly because we've all seen what happens when you're not careful:
you end up with Office macro viruses. But carefulness on the part of the
user is also advised. User education only helps with virus type 3,
though. (We're consigning 1 and 2 to the dustbin of history.)

b. System tightness.
Locking down a system so that it doesn't listen to the network too much
makes it more difficult for a worm to remotely exploit that system,
unsurprisingly. As remarked above, Linux used to be very good at this,
got quite a bit worse (when people thought: we can have what we like
listening! We're Linux! We're invulnerable!), and is now getting
better again. Fizzy is the man to talk to about this, and I imagine that
Bambam, Ade, and Ron would also chip in with more detail. This protects
against virus type 4.

c. Open source.
The more people you have hacking on the code, the more people there are
to spot a bug in it, and the quicker you can get that bug patched and
the new version released to users. Whether this actually happens is a
subject open to debate: although anyone can potentially hack on the
Thunderbird code, not that many people *actually* do so. This protects
against types 4 and 4a.

d. Make it more difficult for users to do stupid things like run an
executable straight out of an email.
This sounds good in theory but is a bit difficult in practice, since it
almost always runs directly contrary to the principle that computers
should be as easy to use as possible. Having to save an executable to
the filesystem is a pain. The security/usability balance is a delicate
one.

e. Virus scanning
A virus scanner can (potentially) intercept a virus and identify it as
such before it has a chance to do any damage. Virus scanners don't
really exist for Linux, because there aren't any Linux viruses to scan
for. ClamAV scans for all the viruses it knows about, which are all
Windows viruses at the moment (as far as I am aware). If Linux viruses
start to exist then it will no doubt check for those too. Ade's
contention on this is that Windows people are all aware of the virus
problem and therefore have antivirus software running: Linux people do
not, because they think that they are invulnerable. So when Linux
viruses do start to appear, people will have to be convinced to start
running AV software (unlike Windows people, who already have been
convinced, although in a rather painful way).

Anyway, those are my thoughts on the threat of Linux viruses. Those of
you who listen to LugRadio will note that this marks, after some
consideration, a shift in my position. However, there currently exists
no major threat: there are no Linux viruses (not in the wild, really;
there have been some demonstrations of a concept), and Linux network
services *tend* to be better and more securely written for Linux than
Windows, decreasing the possibility of a damaging network worm. The
issue, then, is to convince people that in the future there *will* be a
problem and to take preventative action *now*, rather than waiting until
it happens and then scrabbling for a solution. The problem there is that
humanity is really, really bad at taking preventative action. It will be
an uphill task: I'd like to see the Linux distributions include AV
software as standard (even if, right now, it has nothing to scan for).

Aq.