[snips]
Because you don't know any better? ;o)
(Just kidding about that, I suspect that you know they are
not non-existant for Linux)
Maybe because there are less of them about, and you like the
odds?
No, that's not it. Let's try a simple experiment. We'll post two files
on a web site somewhere: virus.exe, a windows "virus", and virus, a
linux "virus". Both are intended to be executed on the "victim"
machine, though, for testing purposes, a simple display of "Haha, I
ran!" would suffice, rather than actual virus code.
Now, how do we get this on to the victim machine and get it executed?
The first is to simply put up a web page that says, oh, "Download and
run the program to clean the MyDoom virus from your machine." We can e-
mail the link, submit it to search engines, whatever. From a user
perspective, though, here's what happens:
Windows: download file. Download complete. "Do you want to open the
file?" Ummm yes. *zot* you're "infected".
Linux: download file. Download complete. "Do you want to open the
file?" Ummm yes. Oh, look, it's a text file, opened in my text editor.
Harmless. What? I want to execute it? Bugger. Okay... browse to
where I saved it and run it. Nope, opened in the text editor again.
Crap. Umm... oh, right, it's supposed to be an executable. How do I do
that? Ah, yeah, attributes... set mode +x. Now run it. *zot*.
Not much of a risk there, is there? Anyone who knows enough to be
_able_ to get the thing to run is very likely going to know enough not
to do it. So we need other means.
Maybe... maybe we can use a javascript on the web page or the e-mail to
do the trick? Certainly not in the e-mail; I've yet to see a Linux mail
client stupid enough to support active scripting. Maybe on the web
page, then? Possibly... though I've yet to hear of any instance of this
occuring.
ActiveX controls, then? Nope; they're a nifty way to infect Windows
machines... but don't work in Linux. Nor is there any equivalent I'm
aware of, except perhaps Java... which has mechanisms built right in to
prevent this sort of thing.
Well, bugger. Okay, so simply getting it to _run_ is a PITA. But what
happens after we get it to run? One of the key aspects of a virus is
replication - getting itself to spread to other systems. How's it going
to do this? Remember, it has to automatically overcome those obstacles
on the secondary target machine.
Meanwhile... the virus faces another problem in Linux-land that Windows
viruses don't face: disparate platforms. In Windows, a virus can be a
pre-packaged bit of executable code in intel x86 format - basically, a
exe file, ready to run. If one can somehow trick the system into
executing the code, that's all she wrote.
That first step is already considerably more difficult in Linux-land
than in Windows-land... but faces another problem - the system may not
be running an X86 chip. Attempting to execute x86 code on, say, a MIPS
box is likely to create some interesting results, but not very likely to
cause an infection of the machine. It will, however, call attention to
itself as being probable malicious code, to be reported to and examined
by the relevant folks - say the distro's updaters. So the virus, to be
successful, can't simply probe around the net looking for Linux boxes...
it has to look for _specific_ Linux boxes, without attempting to execute
on any incompatible ones, for fear of making itself known.
Long and short of all this is that in Linux, it is extremely difficult
to infect the machine in the first place, and, if you do manage to do
this, it's just as hard to infect the next machine without calling
attention to yourself. You're also faced with, among other things, a
whole battery of tools such as FAM and tripwire and the like, whose
purpose is to monitor files for alteration - you'll need to figure out
how to circumvent the lot of them to avoid calling attention to
yourself, if only because a virus that causes the system to start
spewing forth "File modified - possible security breach" messages is
going to get killed, not live on with users blissfully unaware of it.
All I am saying is that it is not impossible. It would have to be
impossible *everywhere* for a virus to replicate, in order to
reduce them to the status of (non-replicating) trojan horse
and eliminate the desire for AV scanners.
Of course it's *possible* to write Linux viruses; a few have been
written. Problem is, they're very short-lived and very narrowly
distributed; because it's so damnably difficult to infect _a_ Linux
machine, trying to replicate to other machines, coping with different
kernel versions, different browsers and mail clients, different security
tools, different permissions models and different chipsets is just that
much more difficult. Enough so that, despite some rather interesting
articles on how one might approach such things (see the website at
http://www.lwfug.org/~abartoli/virus-writing-HOWTO/_html/
#FTN.note.rick.rant.virus for example) they simply don't work.
That was intended to be a "user friendly" feature imo.
Executing un-trusted third-party code without so much as a warning is
"user friendly"? Sure, if the users are virus writers. To anyone else,
it is nothing more than another completely unnecessary security risk.
design of the client. I saw that a Linux e-mail client is available
with this nice "preview pane" feature too, but I don't know if
its default is to render HTML or not ~ but you can imagine
that some will have it set that way if it is possible.
KMail, when encountering an HTML mail, renders it as text - i.e. you see
the HTML code. It also adds a little note at the top to the effect that
"Look, rendering this as HTML is stupid and dangerous, but if you
really, really feel you must, click here." It also, IIRC, allows you to
define folders to automatically render the HTML in the messages in them
- useful for mailing lists who persist in sending HTML postings. One
might assume you've got a rule that moves things coming from the
listserv into that mailbox, so it's reasonably unlikely you're going to
get malicious mails in there... but it is a risk.
Assuming that a file is safe because of its name is ludicrous.
Actually, you're letting your WIndows conditioning come through here. A
file *is* safe, period, unless made to be unsafe. A .jpg file will be
loaded in the image viewer. A .html file will be loaded in the web
browser. A .jpg.exe file will be loaded in the text editor. You see,
there *is no* "executable file type" in Linux; as a result, it is
virtually impossible to have an "unsafe file" unless you, yourself, take
steps to *make* it unsafe.
It's only in Windows-land that one has to worry about the file name. To
use the "don't judge a book by its cover" notion, in Windows, the cover
*does* define the book - if the cover says it's an executable, run it.
In Linux, the cover is just a piece of paper; the contents of the file
will be _read_, not executed, unless and until the system is explicitly
told to catalog the file as an executable.
...or because its filename's extension (or lack of) wasn't registered.
Figured out how to unregister .exe files? No? Until you do, simply
tacking ".exe" onto a file instantly renders it something the system
_will_ attempt to execute when clicked.
A viruses "point of entry" is its being invited in by the user, and
executed. None of that list (a good list I might add) affects that.
Umm... no. Viruses aren't invited; they invite themselves. When I get
an e-mail from my friend sending the latest pictures of their dog,
that's what I invited. The virus that happens to be riding along with
the message is an *uninvited* parasite. And that's just the point...
even if you can figure out _how_ to get it to me (easy enough; I get
hundreds every day) you still need to figure out how to get it to
_activate_, which is the key difference. Scripting in the mail body
won't do it. Attaching it as an "executable" won't do it. You need
something else, something that will either convince me to to through the
steps of converting it to an executable, or to do so automatically. The
former is difficult, if only because those who are likely to know how to
do it are also likely to know better than to risk it, and the latter is
damnably difficult.
Sure, Windows (default) is unsafe...no argument, but the usefulness
of AV software would still exist even if "flaws" ceased to exist.
Again, how so? Tell you what. You drop any file you want on a web page,
or e-mail it to me, etc, etc, etc. I'll load the page in a Linux
browser, or read the mail in a Linux mail client. Before you do this,
though, try to figure out exactly how you're going to get the file to
execute.
Not too long ago, in one of the Linux discussion fora, someone claimed
he could use a known vulnerability to perform a local root exploit.
That is, if he could get the user to run the app locally, it would,
thanks to a flaw in the system, be able to gain root privileges.
What's nifty about this is two things. First, of the dozen or so people
who actually ran his exploit code, even *with* the proviso of not having
custom kernels, file-alteration monitoring tools, etc, etc, etc, only
one got "rooted". Note that this explicitly required, though, the
complete lack of any additional security items whatsoever, as well as a
specific kernel version, and still only managed a 1 in 12 success rate.
The second point of interest is that in order to get the exploit to
work, he had to figure out how to get the code onto the victim machine
and have it run... a problem he never solved other than to ask for
volunteers willing to risk the potential damage.
1 in 12, *despite* being hand-held to the point of having *no* security
whatsoever *and* having a specific kernel version. Even required a
specific (x86) CPU, as I recall.
Why did it fail? Simple: it relied on a known configuration - a known
toolset. Problem is, the toolsets varied. Some had this mailer, some
used that. Some had Perl scripting support, some didn't. Whatever.
Even when the target vulnerability is known, even when you have the
active and willing participation of the "victim", it *still* proves
difficult to pull off a successful exploit... and a virus doesn't have
that willing and active participation of the victim.
I agree with all except the "totally" part. I would even agree with
almost totally.
Again, totally. The simple addition of the executable attribute, a la
*nix systems, would significantly reduce virus propagation. Not running
scripts where they shouldn't run would reduce it more. Not getting
"cute" - relying on file extensions or other such things, and then
hiding them from the user - would help some more. Not enabling
unnecessary services would help more. Encouraging the use of non-admin
accounts - and ensuring that non-admin users can't muck with *anything*
but their documents and their registry settings, etc - would help still
more. Doing all of these would, I believe, reduce the virus problem to
a fraction of what it is. MS even had a roadmap to follow - existing
multi-user systems where security actually mattered - and they *still*
couldn't manage to get even these basic items right.
NT4 is apparently so bad it can't be fixed. Shatter apparently can't be
fixed. Known serious or critical IE holes have existed in some cases
for months without being fixed. They can't even deploy update
notifications for their own applications... so users running Windows
and, say, Outlook may well have the latest *Windows* fixes... but do
they have the fixes for any *Outlook* vulnerabilities? Or are they led
into a false sense of security because MS can't even get *that* right?
Who is to blame for all this, if not MS? Viruses rely on these
vulnerabilities to propagate and infect... if those vulnerabilities were
actually fixed, or, in many cases, if they never existed at all apart
from some seriously boneheaded design decisions... the virus problem
might not be completely eradicated... but it would be manageable.
D