Post by Rich Bell Post by Kelsey Bjarnason Post by Rich Bell Post by Kelsey Bjarnason
Explain to us how a system which _has_ the defenses, still gets
infected, and, thanks primarily to the registry, tends to slow down
more and more as time goes on, to the point of being effectively
unusable, is "easy to use".
It can still get infected if they don't install critical updates,
don't keep their security apps up to date or if they do stupid
things like letting it run email attachements, just like on any OS.
You can send me file attachments from now until the end of time, and
not a *single* one of them will *ever* execute on my Linux boxen.
Ever. Linux simply *does not work that way*.
Sure, you have to make it executable, but do you honestly believe that
people won't do it?
Some, undoubtedly, will. So what?
Windows is effectively a monoculture; this is why things such as viruses
are so damned effective. Well, that, and it has at best crippled
concepts of security.
Linux isn't a monoculture. Even assuming I do decide to save the file,
browse to it, mark it executable and then run it, what's it going to do?
If I target, say, Windows XP, I know a few things right off the bat.
1) I know the files and registry settings that'll let me auto-run.
2) I know the key applications (explorer, say) which are guaranteed to
be there, as targets for infection should I want to avoid the usual
3) I know that barring a few oddball systems, retrieving address books,
mailer settings and the like is trivial, as they're pretty much always
going to be in the same place.
4) I know what anti-intrusion measures are in place, namely none, except
for very odd setups, which I can simply ignore.
5) I know the underlying chipset - x86 - so I can code my virus to a
6) I know the typical firewalling setup, which is either no firewall, or
the XP built-in one, which doesn't track outbound connections.
Contrast that to Linux:
1) The only certain "startup" areas are in /etc/init.d and its
derivatives... but linking in there is pretty easily seen.
2) One could, presumably, also tie in via the user's shell startup
script... but that involves knowing the format of a whole mess of such
things, as there's a whole mess of different shells.
3) Address books, mailer settings and the like are _not_ all in the same
place, nor even the same format, so I'll have to know say the half-dozen
most common ones, at least.
4) I have no idea what anti-intrusion measures are in place, so I'll
have to have the code deal with pretty much all of them, just in case.
5) For all I know, the system is running on a PPC chip. Or something
weirder. Looks like I'm going to have to rely on scripting, rather than
binary coding... and then I'll have to simply hope that the system
supports the particular form of scripting I'm using.
6) The typical firewall setup logs pretty much everything and may or may
not allow me to make outbound connections; worse, what controls the
firewall (shorewall, guarddog, another app, a custom script, whatever)
may or may not be known to me, so I can't very well alter it directly...
and I'll have to deal with logging to hide my tracks if the firewall
records changes in its state (such as adding rules). Which means I'll
have to also be able to do database updates, since ulogd, at least,
allows the firewall to record log entries to a MySQL or Postgres
database. Possibly others.
7) I'll have to deal with items such as applets whose sole purpose is to
allow - or disallow - applications from making or accepting connections,
again possibly with logging in multiple formats.
Now, assuming I've managed to do all this, I'l _also_ have to do it in
such a way that the script is neither excessively large, nor _obviously_
a virus, despite being, at this point, simple script code. And then, I
_still_ have to rely on users actually saving, browsing, marking as
executable and executing.
All that, contrasted to the Windows approach, which, until very
recently, was "deliver a binary attachment, tell 'em 'Look at the sexy
babe'" and have 'em click "open attachment".
You figure out which approach is more likely to cause widespread
Post by Rich Bell Post by Kelsey Bjarnason
"just like any OS" is a load of crap. Linux doesn't do this. Unix
doesn't. OSX, as far as I'm aware, doesn't. It is *Windows* that
acts like a $2 whore, screaming far and wide "I'll open up for
Once again, users will take the extra step to make an attachment executable.
Some will, sure. As noted, however... so what? You persist in seeing
but one tiny aspect of the process... but even that tiny aspect is, in
itself, sufficient to seriously impact the functionality of a virus.
Post by Rich Bell
I have never had an email attachment do anything on my XP machine unless I
chose to do it.
MS apparently learned its lesson, finally. It wasn't so long ago that
all you needed to do was click the attachment and select "open
attachment" and *blooie*. All because MS doesn't grasp the difference
between "open" and "execute", a distinction which every computer person
in the history of man has had no problem with _except_ those employed by
MS. Where they find these people isn't clear.
Of course, they've also made things even more fun. It was within the
last year or two that emails were going around where you didn't need to
even open the attachment to get infected; simply viewing the email in
the preview pane was sufficient - because Windows, as per usual, does
the $2 whore bit of opening up to and running anything and everything -
By contrast, Linux mail readers tend to fall into one of two categories;
those that don't even render the HTML, or those that do, but sanitize it
first. Neither, generally, will retrieve remote items by default -
images, web bugs, etc - and even when you choose to do this, not a
single one I'm aware of will allow _anything_ in the email to execute.
Net result, it is nigh-on impossible to use email in Linux as an
infection mechanism, compared to Windows, where it has been used again
and again and again, in a variety of ways, for exactly that purpose.
Post by Rich Bell Post by Kelsey Bjarnason
So? I'm talking about machines that have _current_ and _up to date_
AV, anti-spyware and other tools... yet _still_ get infected. You
cannot eliminate the risk caused by a poor design simply by running
such tools; at most you can reduce the risk somewhat. The correct
approach is to fix the design.
I am not getting infected so it is a user problem.
Sure. The user installs the AV software, the anti-spyware stuff, goes
off and does his thing and still gets infected... but it's _his_ fault.