Why Free?

[Kelsey Bjarnason]

[snips]

false

I'll stop you right there. I'll point out to you a couple of simple
facts.

1) Checking C.O.L.A. and other such groups, you'll discover quickly that
there's a very real, if not necessarily very large, anti-linx and indeed
anti-OSS grouping of users, mostly Windows users.

2) Virus writing "howtos" exist, publicly, for Linux; the information on
how to infect, say, an ELF file is readily available.

3) Given the two items above, one would think it inevitable that a Linux
virus would be created.

4) No viable Linux virus has yet been identified.

Now, we can conclude a couple things from this. We could assume that
the entire group of anti-linux types are completely incompetent boobs.
Or we could conclude that despite their very active and very vocal
attempts to deride Linux, they really don't care. Or perhaps we can
conclude they're unable to perform simple web searches.

None of those seem particularly likely. Yet no such virus has ever been
identified.

On the other hand, the people who _have_ tried to write such viruses,
even where the code and methods were publicly accessible such that they
could be improved upon, enhanced, refined and so forth, have failed,
miserably, to produce viable Linux viruses.

And why is this? One needs but read their own reports. In simple
English, Linux is very resistant to such attacks. But hey, if something
else happens to let in viruses the way rotten meat lets in maggots, it
couldn't possibly be because the software is in any way faulty, could
it.

Let's take a look at Cohen's concepts a bit, though. His definition of
a virus, "a program that can 'infect' other programs by modifying them
to include a possibly evolved version of itself", is telling. How does
it infect other programs? Oh, right - it *absolutely requires* that the
underlying OS either allows non-admin users to overwrite executables, or
allow "root exploits". Both are failures in the OS. Note that the
*default* Windows installation has the user running as "root" with full
privileges to do exactly this, and not so much as a hint that this is a
bad idea. While this may be an install-time design oversight, it
remains a flaw in the OS, one which has critical impact on system
security.

We might also note that according to Cohen it is apparently trivial to
write a virus for *nix based systems. Odd, then, that despite the
popularity of such systems, such viruses simply _do not appear to
exist_. No, it's not a question of popularity; *nix systems have been
running for decades in everything from desktops to supercomputers and
everything in between and more. There have, quite possibly, been more
*nix users in the history of *nix than there have been Windows users.
Yet in all that time, with all those systems and all those users... a
lot of whom were, let's be honest, college and university students who
have, historically, been well known for performing exactly this kind of
mischief if given half a chance... not *one* *nix virus has been
detected in the wild as a successful virus - "successful" here implying
infection of a non-trivial number of machines by whatever means.

All those users... all those machines... all those decades... and not
*one* known successful virus. One worm of note - Morris - might be used
as a possible counterexample, to which I'll simply note that this means
in all that time, with all those machines, all those users, there has
been one, count 'em one, successful "virus" for such systems.

That's *one* as compared to some 70,000 viruses and variants for
Windows. And you expect me to buy that this is somehow *not* related to
the fact that Windows is a sieve? That it's mere coincidence that the
systems which effectively have no security or are riddled with
vulnerabilities are the ones that get infected?

Take the shatter exploit as an example. It relies on an OS flaw.
Specifically, it relies on the fact there's bugger all validation of
messages passed between processes, so a low-privilege caller can merrily
send messages to a system-level process and not a thing is done to check
wheter this is legit or not. It also relies on, IIRC, a buffer overflow
- in an OS-provided component. Another OS flaw. Net result? If I can
get my virus running even in a low-privilege process, I can use shatter
to wind up with system-level privileges, all due to OS flaws. Or I can
use IE's stunning ability to download and execute any code I choose
thanks to some stupendously bad design decisions... and note that IE is
now generally regarded as part of the OS. You may be able to remove the
interface component, but the rest remains.

The list goes on and on and on, but the fact remains: if the OS has a
decent security model, getting the virus to run *at all* is difficult,
getting it to propagate is even more so. It's only systems which are
badly design and badly implemented that suffer virus issues worthy of
note... and that wouldn't be the case if viruses were trivial to write
and not dependent upon OS flaws.

Feel free to prove me wrong, though. Say by providing a Linux-based
virus that a) will somehow automagically execute on the victim's machine
without the user needing to make it, explicitly, executable and b) will
merrily propagate to other executables and other systems *without*
relying on flaws in the OS's security mechanisms - no using root
exploits, for example, that would be relying on an OS flaw and would
invalidate the premise you're trying to establish.

Hell, if you think you've got such a critter, send it over; I've got a
box here I can use as a "throwaway" for testing purposes. 'Course,
being my box, it follows *my* security choices and the like, but none of
that matters, right?

 

[BoB]

If that is what you think that was, then okay.

...but I think it was a reference to F-Prot for DOS not
supporting XP's NTFS and the difficulty in finding a
suitable maintenance environment for use on that OS
and filesystem.

Comes the dawn! Her reference to " -- for years, I was a happy
user of F-Prot for DOS," was with another OS. I was kinda slow
on that one. No DOS in NTFS is why I have no desire to use it.

BoB

 

[BoB]

BoB wrote:
[snip]

From that additional info it is obvious you should experience no
real problems in the virus arena. Same here, I'm enjoying Firebird
and looking forward to Firefox when it becomes relatively bug free.

firefox is just the new name for what used to be firebird...
theoretically all versions of firefox should be better than firebird...

New names for each beta is confusing. My profile is still identified
under C:\WINDOWS\Application Data\Phoenix, which remains my favorite
in the name game.

BoB

 

[optikl]

Kelsey Bjarnason wrote:
It's not the user base, either.

The smartest Windows user, replete with AV tools and the like, is still
at moderately high risk - all that needs happen is a new strain come out
before his AV software is updated to protect the machine and voila;
instant infection.

Kelsey, I would disagree with *one* of your premises. A *smart* Windows
user wouldn't rely solely on the tools you mention above to mitigate
his/her risk. He/she would protect themselves from getting into a high
risk position in the first place, through the behavior which you say is
not necessary if you are running *nix.

On the other hand, as noted, *nix users as a rule

don't even *use* AV software... because there's absolutely no need to.

I know Windows users who don't, either. They stay clear of high risk
behavior. Although, they can't afford the luxury of behavior lapses,
like you say *nix users apparently can.

 

[bobas007]

New names for each beta is confusing. My profile is still identified

under C:\WINDOWS\Application Data\Phoenix, which remains my favorite
in the name game.

AFAIK in near future this "THING" will be "Firefox" for good.
Even it`s profile name will migrate in new versions.

 

[null]

On Sat, 20 Mar 2004 22:20:07 -0800, Kelsey Bjarnason

That's partly true. However, the fact is I simply do not *need* to
worry that simply reading an email might be enough to infect my machine.
I don't *need* to worry that browsing a web page may infect my machine.
Such things are virtually impossible to do in *nix, BSD, etc... yet are
comparatively trivial to do in Windows. It's not the user base, either.
The smartest Windows user, replete with AV tools and the like, is still
at moderately high risk - all that needs happen is a new strain come out
before his AV software is updated to protect the machine and voila;
instant infection.

I have to take issue with this. I've been running Win 98 and more
recently Win ME since 1999 without any realtime av or firewall. Never
been hit with any virus or other malicious code. If I was at
"moderately high risk" wouldn't I have been hit by now?

Your assumption that AV software is required protection for "the
smartest" Windows users is way off base.


Art
http://www.epix.net/~artnpeg

 

[Don]

Saddam was paying off the U. N. for ten years and we just found out about
it.

D. W.

Black Dog wrote:
[snip]

Also, like lots of people, I sometimes suspect the AV vendors and vxers are
in cahoots.

there's no way to keep something like that secret - if it were
happening you'd have heard about it...

I remember the days with John Macaffee was like
Mister-John-Wayne-anti-vxer, giving away his solutions to these pesky little
programs polluting floppies and boot sectors. Now he is a major
corporation.

no, now he is a major pariah... he (essentially) paid for new
viruses... he is the closest thing to what you suspect of av companies
in general... it's a darn good thing for the company that he's not a
part of it anymore (and hasn't been fore a good long time)...

--
"we're the first ones to starve, we're the first ones to die
the first ones in line for that pie in the sky
and we're always the last when the cream is shared out
for the worker is working when the fat cat's about"

 

[kurt wismer]

JT wrote: [snip]

A general purpose computer means a machine that can be programed for
virtualy unlimited purposes. That doesn't mean that every program on the
machine should have unlimited access to that capability.

no, but it does mean that if the virus is acting in the context of a
user who has that capability it should...

Even there it can be restricted by program as much as by user.

treating programs as principles in their own right is not a reasonable
security measure (it creates a huge overhead for granting and
maintaining authority for programs) *and* it still leaves some programs
with sufficient permission for any infection they might carry to spread
(in other words it only reduces the number of possible successful
spreading points)...

the "user" in many security models is not assumed to be a human. Take the
user running a webserver or mail server on a Unix like machine.

i never said the user had to be human, only that the user-based
security context is how most, if not all, multi-user OSes do things -
including unix... if you were to start the webserver from an
interactive logon session you'd have to go through extra steps to have
it run in the context of a user other than the one you logged in as
(whether in *nix or nt based OSes)...

I am saying that the extension alone should not be enough to make a program
executable.

yeah, as if issuing a chmod and/or chown call is really all that
different...

One way to do that is by having a separate execute permission,
as well as read, write, etc. as you have in Linux.

you haven't looked all that closely at the permissions afforded by the
ntfs file system, have you...

Copy it all you want.
rename it to anything you want. If it wasn't executable before, it won't be
because of the act of renaming it.

chmod is not inherently different, from a security perspective, from ren...

[snip]

Look at different OS's that have been developed. Forget extensions for a
second.

please don't take this the wrong way but forget about telling me to
forget about extensions - i'm not hung up on extensions, it just
happens to be the context that most people here will understand... i'm
quite familiar with the unix equivalents since that's the environment i
did my formal comp.sci. education in...

my dos command example was simply to illustrate that it's not trivial
to crack down on the generation of executable content...

For a step in the right direction, but not a full solution, look at
how Linux treats interpreted scripting languages like perl. A script
language that part of an office package should be limited in what it can
access and change in the system, just like the rest of the office package
software. Using a part of the file name (like the extension) to determine
if a file is executable was replaced on many OS's years ago. Look at Unix,
VMS, Apples OS's, etc.. In most of them, the extension is there to help
the human recognize the file, and to aid exchange of files with other OS's.
Critical attributes, such as whether the program is executable is protected
from simple program or human error or malace. Gross human error, or major
malace is probably not possible to protect against.

i think you totally lost my point about script files - there is no way
for the operating system to know that they represent executable content
and therefore no way for the operating system to prevent their
creation... your arguments are essentially running afoul of the limits
of computability - it is not possible to define what data is executable
(technically all data is executable but most of it won't do anything
particularly interesting or useful) and therefore no way to limit the
creation of executable content...

 

[kurt wismer]

[snips]
(e-mail address removed) says...

there are a number of possibilities - maybe you understand that using a
niche market OS makes you a less palatable target to virus writers - or
maybe you're just one of those morons who thinks *nix is immune...

Or maybe I understand *why* viruses propagate. Hint: it requires a
brain-dead security model. Such as that in Windows.

false - please refer to the mountains of academic material on computer
viruses... specifically fred cohen's works - his initial experiments
were in a pre-existing unix and maintained unix system and his
conclusion was that they can operate successfully even in such a system...

No, it's not.

If a piece of code cannot be executed _at all_ unless manual steps are
taken by the user of the machine, then a virus *dies* almost instantly;

false - please refer to the technical details of w32/bagle.p (as an
example)...

[snip]

Actually, I have.

you may have been reading it but you certainly haven't been
understanding it... otherwise you wouldn't be so hung up about
autoexecuting worms and how it just couldn't happen on unix - the
current crop do not autoexecute and are still very successful...

Virus after virus, worm after worm... and virtually
all for Windows machines. Not BSD boxes or Linux boxes or Macs. Hell,
IIS has been attacked repeatedly and done extensive damage despite being
*less* popular than Apache for internet web serving. Not that Apache
hasn't had its share of attacks; it has... they just die out quickly.

because there are (comparatively) so few bsd/linux/mac boxes...

That's partly true.

it's entirely true...

However, the fact is I simply do not *need* to
worry that simply reading an email might be enough to infect my machine.

the current crop of email worms don't infect simply by being read -
they are being sent in encrypted archives that the user has to
extract... in some cases the password for the archive is contained in
an image (a rudimentary CAPTCHA system) to prevent automated scanning
of the contents...

I don't *need* to worry that browsing a web page may infect my machine.

sure... you don't *need* to worry.. you don't *need* to go to work each
day either... the only things you really *need* to do are eat, drink,
breath, and sleep...

Such things are virtually impossible to do in *nix, BSD, etc... yet are
comparatively trivial to do in Windows.

and back to the original point - even if the bugs went away the viruses
would not...

It's not the user base, either.

yes it is.. ultimately it is the user who executes programs not knowing
that they are infected, and thus allowing the viruses to spread.... the
user is the weakest link in any security system...

The smartest Windows user, replete with AV tools and the like, is still
at moderately high risk - all that needs happen is a new strain come out
before his AV software is updated to protect the machine and voila;
instant infection.

?? totally false... apparently you've never heard of safe hex...

On the other hand, as noted, *nix users as a rule
don't even *use* AV software... because there's absolutely no need to.
The security model used by *nix makes viruses so helllishly difficult to
design that it simply is not a real threat.

and there we have the crux of the issue... i said before one of the
possibilities was that you were one of those morons who thought unix
was immune - apparently i wasn't far off...

i shall repeat, for the umpteenth time, please refer to the mountains
of academic material on viruses - specifically the work of fred
cohen... if you need a more definite pointer try
http://www.all.net/books/virus/part5.html ...

This kind of twaddle is exactly what's wrong with the whole Windows user
mindset. Apache is *more* popular than IIS... yet it's IIS, not Apache,
that has caused endless damage. Based on the popularity argument, the
opposite should be true. Yet it's not. Poof goes that little bit of
tripe.

except i'm not making a popularity argument... in the sample of one
that is me linux is more popular than windows, and yet i'm still using
windows...

also, we're talking operating systems, not webservers... there are more
windows boxes than unix boxes by orders of magnitude, period... the
windows userbase is much, much larger than the unix userbase - the
windows userbase has surpassed the critical mass necessary to sustain
naturally occurring infections, the unix userbase has not...

 

[kurt wismer]

[snips]

false

I'll stop you right there. I'll point out to you a couple of simple
facts.

1) Checking C.O.L.A. and other such groups, you'll discover quickly that
there's a very real, if not necessarily very large, anti-linx and indeed
anti-OSS grouping of users, mostly Windows users.

red herring - you said viruses are more than just programs someone has
written - you said they rely on security holes in order to propagate -
the fact that there are people who don't like linux in no way supports
that contention...

2) Virus writing "howtos" exist, publicly, for Linux; the information on
how to infect, say, an ELF file is readily available.

3) Given the two items above, one would think it inevitable that a Linux
virus would be created.

they have been created... the very first virus operated on a unix system...

4) No viable Linux virus has yet been identified.

false, there have been linux viruses *in the wild*...

Now, we can conclude a couple things from this. We could assume that
the entire group of anti-linux types are completely incompetent boobs.
Or we could conclude that despite their very active and very vocal
attempts to deride Linux, they really don't care. Or perhaps we can
conclude they're unable to perform simple web searches.

None of those seem particularly likely. Yet no such virus has ever been
identified.

your facts are in error... try your own medicine - google for "linux
virus in the wild"...

On the other hand, the people who _have_ tried to write such viruses,
even where the code and methods were publicly accessible such that they
could be improved upon, enhanced, refined and so forth, have failed,
miserably, to produce viable Linux viruses.

false... you obviously have not been doing your homework... there are a
number of linux viruses that were viable at the time of their release...

[snip]

Let's take a look at Cohen's concepts a bit, though. His definition of
a virus, "a program that can 'infect' other programs by modifying them
to include a possibly evolved version of itself", is telling. How does
it infect other programs? Oh, right - it *absolutely requires* that the
underlying OS either allows non-admin users to overwrite executables, or
allow "root exploits".

false - it requires that it be executed in the context of a user who
has write access to at least one as yet uninfected executable...

Both are failures in the OS.

users having write access to an executable is not in general a failure
of the os... the user may have made the executable...

Note that the
*default* Windows installation has the user running as "root" with full
privileges to do exactly this, and not so much as a hint that this is a
bad idea. While this may be an install-time design oversight, it
remains a flaw in the OS, one which has critical impact on system
security.

i've installed linux on a number of occasions... it's never forced me
(or even asked me) to create a user other than root...

We might also note that according to Cohen it is apparently trivial to
write a virus for *nix based systems.

since he did it himself, i guess he should know...

Odd, then, that despite the
popularity of such systems, such viruses simply _do not appear to
exist_.

this is a false statement...

No, it's not a question of popularity; *nix systems have been
running for decades in everything from desktops to supercomputers and
everything in between and more.

just because they've been running for a long time doesn't mean the
number of windows boxes doesn't dwarf the number *nix boxes...

There have, quite possibly, been more
*nix users in the history of *nix than there have been Windows users.

nice claim, try and prove it...

Yet in all that time, with all those systems and all those users... a
lot of whom were, let's be honest, college and university students who
have, historically, been well known for performing exactly this kind of
mischief if given half a chance... not *one* *nix virus has been
detected in the wild as a successful virus - "successful" here implying
infection of a non-trivial number of machines by whatever means.

this is a false statement... see my google reference earlier in this
post...

[snip]

That's *one* as compared to some 70,000 viruses and variants for
Windows. And you expect me to buy that this is somehow *not* related to
the fact that Windows is a sieve?

given that you're under the delusion that there are more *nix boxes
than windows boxes i don't expect you to believe much of anything i say...

That it's mere coincidence that the
systems which effectively have no security or are riddled with
vulnerabilities are the ones that get infected?

it's a coincidence that the more insecure (out of the box) OS is the
virus magnet - but it is not a coincidence that the more populous (not
popular) OS is the virus magnet...

[snip]

Feel free to prove me wrong, though. Say by providing a Linux-based
virus that a) will somehow automagically execute on the victim's machine
without the user needing to make it, explicitly, executable

auto-execution is not a requirement for a virus...

and b) will
merrily propagate to other executables and other systems *without*
relying on flaws in the OS's security mechanisms - no using root
exploits, for example, that would be relying on an OS flaw and would
invalidate the premise you're trying to establish.

linux/bliss was found *in the wild* 7 years ago...

 

[FromTheRafters]

If a piece of code cannot be executed _at all_ unless manual steps are
taken by the user of the machine, then a virus *dies* almost instantly;
by definition, a virus has to execute in order to do its thing.

A virus will execute because the user desires the host program
to be executed. If the virus successfully "infects" another host
program, then that new host will likely be executed in a similar
manner - recursively. A virus doesn't need to use any trick to
set the new host as executable - that can be left as a trivial
excercise for the user.

If the virus can't find any worthy host to infect, it might just be
programmed to activate. You don't want to execute such a
program (just in case it can do some damage), so you would
want to have some sort of anti-virus procedure to utilize.

In Windows-land, this is often accomplished by trickery: pretending to
be an image, for example. That sort of thing simply _does not work_ in
other OSen.

Just because many worms (or viruses) use trojan horse tactics
doesn't mean that it is a must that they do so. In fact, many
viruses will not make any such attempt - they "know" that
they will be executed when the user executes the host program.

A good security model will keep OS "programs" well away
from user application level "programs" so that the OS won't
be the one running infected hosts, but that still leaves users
without clue the ability to allow "infection" within their own
purview.

....and if someone with higher permissions borrows an "infected"
host program file - he or she can execute it with their permission
set - thus possibly "infecting" more program files (more deeply
infiltrated into the security model).

If the file _is_ an image, it will display. If not, it
will simply be treated harmlessly, such as loading it in a text editor.
Neither of these actions results in anything useful from the virus's
point of view.

This kind of "pretending" to be something other than what it is
is more a trojan property than a virus property. Although a
virus or worm may find such trickery useful, it is not something
a virus *must* do to exist - and as such is really irrelevant to
the discussion at hand.

Windows sucks - Microsofts security record is abysmal, but
they did make computering more popular by making their
OS "user friendly" and allowing any idiot to go online. They
had a lot to do with computer sales in general and the growth
of the internet. Yes, we are now plagued by Windows based
worms and viruses partly because of userbase cluelessness,
market share of those platforms, and the utter lack of "default"
security measures.

....but making Windows go away (or all software design or
code flaws) will not negate the usefulness of AV programs.

It requires the "everything is executable" or some equivalent
which renders the process of getting executed equally simple
in order to act.

Only if it wants to autoexecute its next iteration - which is not
something it is likely to want anyway.

[snip]

Excellent point!

That's partly true. However, the fact is I simply do not *need* to
worry that simply reading an email might be enough to infect my machine.

That depends both on the e-mail application software and the OS.
Your choice of client, and your knowledge of kernel version upgrade
path - it comes right back to being *you* not strictly the Linux OS
that allows such warm fuzzies.

I don't *need* to worry that browsing a web page may infect my machine.

Same as above applies.

[snip]

The smartest Windows user, replete with AV tools and the like, is still
at moderately high risk - all that needs happen is a new strain come out
before his AV software is updated to protect the machine and voila;
instant infection.

I sometimes go for months without updating my AV program - it
doesn't really matter anyway because it is never asked to intervene
in what I am doing. I am much more concerned with vulnerabilities
being patched or applying appropriate "work-arounds" than I am
with getting the definitions set updated for worms that *require*
that idiot users execute them.

On the other hand, as noted, *nix users as a rule
don't even *use* AV software... because there's absolutely no need to.
<sigh>

[snip]

because linux machines are not nearly as numerous in comparison to
windows boxes... because the *nix user base hasn't reached the critical
mass necessary to sustain naturally occurring infections...

This kind of twaddle is exactly what's wrong with the whole Windows user
mindset.

It is true, but it is only part of the picture.

Apache is *more* popular than IIS... yet it's IIS, not Apache,
that has caused endless damage. Based on the popularity argument, the
opposite should be true. Yet it's not. Poof goes that little bit of
tripe.

Explain how they so often get rooted (or at least hacked through)
if they are so impervious due to their near perfect security model.

It was only fairly recently that Windows rootkits came on the scene,
does that mean that Windows is more secure - of course not. Their
popularity as servers <gasp> has increased - so they become a
more popular target.

 

[kurt wismer]

JT wrote:
[snip]

Started that way in the early MSDOS and AppleII days when virus were young.
The exploits that have happened recently against other OS such as Linux and
Apples OS/X have been exploits of software or security configuration
errors.

the only thing viruses depend on is the ability it write executable or
interpretable code to disk...

That is a weakness of the security model. It should not be easy for just
any program to write an executable. It doesn't need to be that way. It is a
design flaw.

that is inherent in general purpose computing...

General purpose computing platforms exist without that requirement. It is
common in the most popular one on the market right now, but it is not a
universal requirement.

since distinguishing executable or interpretable code from data is not
computable, it is not possible to prevent the writing of executable or
interpretable code to disk...

only on a special purpose computer, where the form of such code is
precisely defined and not extendable could such a preventative measure
be put into place...

Boot infectors on modern machines/os's infect the boot record because of a
weakness in the os that let them infect the bootsector in the first place.

did you not read what i wrote? the OS doesn't let it happen, the OS
hasn't loaded yet, it can't prevent anything when it's not even running...

In very early days of home computers, when you had to boot off of floppy
disks, then an infected disk could boot up and hide a program in memory.
Bios protection against boot infectors has been out there for about 12
years. Turning off floppy boot also eliminates that threat.

the boot record write protection often got turned off due to false
alarms when installing or re-installing OSes... changing the boot
sequence was a good one though, but sometimes one still wishes to boot
from a floppy (even in linux)...

Much of stoned
and its siblings success depended on propogation through an OS with
inadequate design in the first place.

false... most bootsector infectors operate perfectly well in the
absence of any OS on either the source or destination media...

Kids ran an infected program off of a
disk they shared with friends. Used to clean up a lot of machines infected
with them.

?? yes, as i suspected, you don't understand boot infectors very
well... boot infectors aren't programs that kids run... they execute
during bootup, before the operating system - and they aren't files that
the user can select and run, they aren't files at all, they're outside
the filesystem...

Writing to a file and giving it some name with special qualities, like the
extension in MS os's is not enough to make a program executable in many
OS's. In Unix or Linux, for example, a program isn't an executable unless a
special permission bit is set, no matter what the name is. Other OS's do it
with extended attributes that are, again, not part of the name and easily
set by just righting a file and giving it a magic name

right, like chmod is so magically different than ren...

writing an arbitrarily named file in dos and renaming it to an exe is
no different than writing an arbitrarily named file in unix and
chmoding it to an executable...

surely you are able to recognize these and equivalent...

By default, the current directory and the users home directory are not in
the execution path.

which means precisely nothing... surely you don't think users are never
going to install their own programs in their own space?

[snip]

On a non-windows system like linux, it normally depends on the installer
used. It takes special efforts to install a Linux app where the average
user can write.

sometimes yes, sometimes no... like you said, it depends...

Actually, no it doesn't. A script program in linux is no different than any
other program in that it needs to go through the permissions process.

no it doesn't... i've run scripts on linux, solaris, and bsd without
setting any execute bits... you do so by executing the interpreter with
the script's filename as a command parameter...

heck, never set the execute bit for my scripts... what a pain in the
arse that would be...

If
it is going to be a straight executable, such as a batch file in MSDOS
would be, it needs to have the execute bit set. Huge amounts of bash and
perl scripts do this. If it is interpreted by something like perl or python
or open office, it still is limited by the permissions of the user account,
so it is still limited.

the same is true in windows... at least in the nt based versions of it...

Just putting a perl script file in a directory and
naming it something like myprogram.pl doesn't make it "executable".

actually it does... it's just that the process of executing it is a
little more involved...

Virus replication still requires the os to replicate.

no it doesn't... see bootsector viruses...

There are ways for an
OS to do internal integrity checks to reduce the odds of a pre startup
program running.

the OS cannot prevent something from running if the OS itself is not
running...

You could make a case for boot sector virus making use
of a legacy flaw in the bios,

? flaw in bios? what flaw would that be?

and proper BIOS setup can pretty much
eliminate that as a threat.

yeah, like those settings can't be changed in code...

There is a reason there are so few boot sector
virus still propagating in the wild.

certainly - people don't use floppy disks nearly as much as they used
to... also no new ones are being produced because it's become a lost
art and the old ones all get caught by anti-virus products...

If you boot up off of a floppy (or cdrom) that is infected, and your bios
doesn't block it, then a stoned virus could infect a linux box. it might
crash or at least interfere with the boot process.

if the floppy itself isn't a bootdisk then it will give the "non-system
disk" error... at which point you'll pull the disk out and hit a key
and continue booting as normal but you're mbr will be infected... you
might at that point remember to change your boot sequence back so that
it doesn't boot from floppies anymore...

It wouldn't propagate.

sure it could... after you change the boot sequence back so that it
doesn't boot from floppies what makes you think that when you perform
your next reboot with a floppy in the drive that that floppy won't get
infected the moment the infected hard disk mbr executes? there's
certainly no way to prevent it (other than write protecting your floppy)...

Without the flaws in MS OS, they can't propogate. Stoned, and similar virus
require the MS os's to spread.

sorry, but ... no they don't...

 

[FromTheRafters]

[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".

Of course - the names are irrelevant.

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.
Okay.

Now, how do we get this on to the victim machine and get it executed?

It doesn't matter to a virus, it "knows" that it will execute when
the user executes the formerly legitimate host file's program. Say
that the virus infected a file named "hexedit" which (as the name
suggests) is a hex editor. It doesn't have to do anything except
sit there dormant until someone goes through all that is necessary
to execute the host - when the host is scheduled, so is the viral
code.

In this sense, viruses are trojans - because the "hexedit" program
now has a hidden agenda. It will not generally be called a trojan
because it now self-replicates and it is more important to address
its viral capabilities because of the way self-replicators proliferate.

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".

User error - - Error # ID10t

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.

I want some applications that make this damned OS more user
friendly - there is just too much one has to do to infect oneself.

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.

Hmmm - maybe a nice script will suffice. Maybe I could write
one that checks a filenames suffix for ".run" and feeds that file
to the loaders with the "executeable" bit set. Then all I would
have to do would be to rename "virus" to "virus.run" and call
the script with it as an argument - SWEET!

How do I do that? Ah, yeah, attributes... set mode +x.
Now run it. *zot*.

User error - - Error # 5TuP1d ID10t

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.

Never underestimate the depths to which SE can mine for idiocy.

....and as I said, "viruses" have the best SE because they hide
within a program the user *does* want to run and will stop
at nothing to attain this goal.

So we need other means.

Not for a virus we don't, it will run when the host program does.

....and the host program will run because the user really wants it
to (unaware that it now has a hidden agenda).

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.

Irrelevant, you are clearly not talking about "viruses" but rather
exploits of vulnerabilities - of course this requires flaws, and I
know of no OS completely without flaws.

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.

Not systems, programs. You are thinking more of worms which are
another story. Despite the fact that some will insist that all viruses are
worms, and others will insist that all worms are viruses, there is a real
difference in their behavior that you seem unaware of.

How's it going to do this?

Hitch a ride on a worm? Maybe just wait until someone
borrows or otherwise uses the program file it is hiding in?

Remember, it has to automatically overcome those obstacles
on the secondary target machine.

No it doesn't, it relies on the fact that the user (borrower)
also really does want to execute that host program.

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.

Do you mean a binary? An executable may still need a loader
to interpret the header and set up a suitable machine state in
the virtual memory (executable image) for scheduling purposes.

If one can somehow trick the system into
executing the code, that's all she wrote.

A virus already has this obstacle behind it - it *is* running
because the user *wanted* its host file's original function
to happen. The added function was unbeknownst to the
user because he thought he didn't need to worry about
viruses and didn't scan the file with AV before executing
its contents.

[snip]

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 can get add-on utilities for Windows too, don't confuse
the OS with the applications and utilities that came with it or
were added on later.

[snip]

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;

Then why did you insist that AV is not needed? Just because the threat
is diminished is no reason to assume that threat countermeasures are
not needed at all. The *only* way to keep viruses out without any
other virus countermeasures is isolationism - i.e. not letting *any*
programs in. If you want to let programs in, then you have to have
a way of assuring yourself that they aren't viral *or* otherwise
dangerous to your system (or others').

Executing un-trusted third-party code without so much as a warning is
"user friendly"?

Sure, they were going to do it anyway weren't they? It wouldn't
be very user friendly to pop up dialog box after dialog box saying
that the HTML engine needs to be registered to view this e-mail
- followed by one for the scripting engine - then the ActiveX etc...

Of course I'm talking about "user friendly" in the sense that it
was a way to get idiots interested in purchasing a computer
and going online. The protocol bindings of default Windows
installations is another example of "user friendly" and also
may have been a "service call reduction" feature which may
amount to the same thing. They had no real way of deciding
what configuration a system was destined for - so they made
everything bind to everything (like steel wool) so that the user
wouldn't get too frustrated trying to do this "e-mail" thing that
everyone was talking about.

Sure, if the users are virus writers. To anyone else,
it is nothing more than another completely unnecessary security risk.

"Friendly" to those that have no idea what "security" is or when
told - couldn't care any less about it. These were the targeted
market - not users who would know how to start with a stripped
down OS and configure everything themselves.

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."

....and they will - - and you know they will. You just can't seem to
imagine that Linux will eventually be user friendly too - with all that
goes with user friendliness.

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.

HTML e-mail is a bad idea, why do you suppose that it is
even supported in such a security conscious OS? Exactly!
They are trying to be friendly to those users that wish to act
without regard to security considerations.

....and here they come.

[snip]

Actually, you're letting your WIndows conditioning come through here. A
file *is* safe, period, unless made to be unsafe.

Not true, a file contains information (data) that can be used by
a program in any way it deems fit. You can feed the contents of
a file containing textual data to a scripting engine or command
interpreter.

Let's not nit-pick - I could just as easily argue that "files" don't
exist and are only abstractions to allow data to be referenced
by I-nodes. Many "files" on a computer are really only multiple
index references to the same data in storage.

So let's just assume that by "file" I mean the contents thereof
and not the descriptor that provides clues to the OS.

You see, there *is no* "executable file type" in Linux;

AOUT, ELF, and script are not executable filetypes? That's
news to me. Did you know that Linux can run PE files too?
All that is needed is the proper loader. It would *still* be
Linux despite the fact that a PE filetype was used to create
the executable image. Linux can support other filesystems
too, but they are actually abstractions used by the virtual file
system.

as a result, it is
virtually impossible to have an "unsafe file" unless you, yourself, take
steps to *make* it unsafe.

You are confusing filetype with windows extension, and "file"
with filesystem descriptor tables. It is the content that is most
important - not the LDT, GDT, or UID etc...

It is "unsafe" to have if it can be made to execute.

It's only in Windows-land that one has to worry about the file name.

Names mean nothing - but extensions in Windows provide
clues to the OS (rightly or wrongly). Microsoft has a problem
in that they are inconsistant in what they use for clues about
how to handle files.

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.

Really, if it has the extension .exe, .com, .pif, or .bat (among others)
the OS "knows" to treat it as an "exefile", "comfile", "piffile", or "batfile"
because of the classes defined in the registry and handles the file as
instructed in the system registry under those names. Although I haven't
tried, I'm relatively sure that the registry can be edited so that all of the
extensions can default to some editor and be as user unfriendly as you
desire.

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.

Same with Windows I think, if you likewise cripple it. Maybe
I will experiment on one of my machines to see what happens
if I use regedit to replace occurences of "%1" %* with some
other thing so that they don't get run up the flagpole.

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.

So will the lack of extension - it then checks the header to
see if there is an OLE2 clue and opens an OLE2 capable
application if it finds such a clue. The result "could" be the
execution of embedded macros.

Umm... no. Viruses aren't invited; they invite themselves.

No, not viruses. Viruses are invited - and no exploit is needed
other than the fact that infected program files sort of "act" like
a trojan because they seem to be as they were prior to infection.

....it is these that are invited (like the original Trojan Horse) into
the computer and executed by the user.

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.

You are *not* describing a virus here, but rather a worm. A virus can
arrive via e-mail (it *is* after all a program file that can be attached),
but a virus doesn't "send itself" anywhere except to another "program".

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_,

With regard to viruses, "activation" refers to the payload being
triggerd (same for worms I believe), but I know what you meant.

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.

....but that's not how it works.

A better scenario would be for you to let me modify one or
more of the programs that you use from day to day with a
nefarious function without letting you know I have done so.
You *will* run the host file because you want to today just
like you wanted to yesterday - and the modified code will
do its thing today and then pass control to the original code
so that you still have the original function of the program as
well.

[snipped nice story about exploit code and Linux - that was
mostly irrelevant to "viruses"]

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.

Yes, diversity is bad for programs that rely on such conformity.

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.

But viruses don't require the use of exploits.

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.

A fraction of a fraction of a fraction is *still* not a totally gone thing.

Plus, you would still have the viruses to deal with.

Who is to blame for all this, if not MS?

I didn't say anyone was to blame, and I'm not defending MS.
I said viruses don't depend on software flaws - anybody's -
so that includes Microsoft's software. I agree that the problems
we now have in this area is largely due to MS software and
its popularity, but viruses would exist anyway even without
crappy software populating the internet.

Viruses rely on these vulnerabilities to propagate and infect

No, they don't. Most other malware does to some extent, but
not viruses.

... 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.

....then "totally" wasn't the right word to use after all, and
viruses don't depend on software flaws.

 

[FromTheRafters]

Boot infectors on modern machines/os's infect the boot record because of a
weakness in the os that let them infect the bootsector in the first place.

The boot code executes before the OS is loaded, so how
is it held responsible for something it cannot affect?

[snip]

Writing to a file and giving it some name with special qualities, like the
extension in MS os's is not enough to make a program executable in many
OS's. In Unix or Linux, for example, a program isn't an executable unless a
special permission bit is set, no matter what the name is. Other OS's do it
with extended attributes that are, again, not part of the name and easily
set by just righting a file and giving it a magic name

Irrelevant to viruses in general.

Also irrelevant - consider a virus that when run searches for
source code files and places its functional code as source
code in the (text?) filetype. When in the natural course of
events the "program" gets compiled and the objects linked
by the developer - the file is executed in an environment
that contains another source code file - this recursive self-
replicating entity is what?

You guessed it - a "virus".

Are you going to consider a text filetype with the descriptor
allowing both read and write to be a software flaw?

[snip]

 

[Norman L. DeForest]

JT wrote: [snip]

In very early days of home computers, when you had to boot off of floppy
disks, then an infected disk could boot up and hide a program in memory.
Bios protection against boot infectors has been out there for about 12
years. Turning off floppy boot also eliminates that threat.

the boot record write protection often got turned off due to false
alarms when installing or re-installing OSes... changing the boot
sequence was a good one though, but sometimes one still wishes to boot
from a floppy (even in linux)...

[snip]

The BIOS options on all the computers I have seen do *not* have a setting
that stops you from booting off a floppy disk. They only have a setting
that tries other drives *first*. If, for some reason, those drives don't
respond during the POST, you can still have your computer boot from a
floppy disk even when you have told the BIOS to try C: first.

The one time I got a virus infection on one of my computers, I was in the
middle of typing an "f-prot" command to check a floppy disk when the AC
power failed for about one second and then came back on, rebooting the
computer. Because of the sudden stop and start of the hard drive, it
failed the POST test and the computer booted from the floppy instead of
the hard drive even though the BIOS setting was set to try the C: drive
first.[1] The floppy *did* turn out to be infected with a boot-sector
virus (stoned if my memory is correct). By the time the virus got loaded,
the hard drive had recovered enough that a write to it was now successful
and the virus infected the hard drive and trashed the boot loader on the
drive.

Because the boot loader had a drive manager on it to provide access to a
larger drive than supported by the BIOS and the backup for it wasn't
available to me (the machine had only recently been given to me and
the backup of the boot loader wan't in the disks I got with it) I ended
up having to re-install the drive manager (which wiped out the entire
original partition) and then re-install everything. (At least I had the
original system disks and backups of the other software. I did lose a
lot of data files, however.)

[1] In fact, to boot from a floppy, I normally booted from the hard drive
to get the drive manager loaded and then hit a key when prompted by
the drive manager during the boot process in order to continue the
boot process from a floppy with the drive manager loaded as a BIOS
extension. That way the hard drive was accessible even when booting
from a floppy.

 

[kurt wismer]

the boot record write protection often got turned off due to false
alarms when installing or re-installing OSes... changing the boot
sequence was a good one though, but sometimes one still wishes to boot
from a floppy (even in linux)...

[snip]

The BIOS options on all the computers I have seen do *not* have a setting
that stops you from booting off a floppy disk.

ok, i have... i've seen where you can select "A:, C:", "C:, A:", or "C:"...

They only have a setting
that tries other drives *first*.

must be a machine dependent thing then... or rather a bios dependent
thing... different strokes for different manufacturers...

If, for some reason, those drives don't
respond during the POST, you can still have your computer boot from a
floppy disk even when you have told the BIOS to try C: first.

yeah, or if you fail to boot normally you can just go in and change the
boot sequence - which you'd have to do anyways when you're trying to
perform a clean boot...

 

[David W. Hodgins]

The BIOS options on all the computers I have seen do *not* have a setting
that stops you from booting off a floppy disk. They only have a setting
that tries other drives *first*. If, for some reason, those drives don't
respond during the POST, you can still have your computer boot from a
floppy disk even when you have told the BIOS to try C: first.

Your knowledge is a little out of date.

On my system I have options for the first,second, and third devices to
search for a boot record. Each of those can be set to one of 29 possible
values, and I can also specify whether or not to search the remaining
possible boot sources, if none of the three work.

All of these include the option "disable". If I disable all three boot
devices, and the search other devices, then I either get an error message,
stopping the boot, or have to press f8, to go to a boot menu.

If I don't have the floppy in one of the options, and have the search
remaining disabled, it will not boot from a floppy.

I currently have IDE-3 (linux on my third hd) as the only option. If I
want to boot ide-0 (windows), cdrom, or floppy, I either have to change
the cmos settings, or use the builtin boot menu.

The one time I got a virus infection on one of my computers, I was in the
middle of typing an "f-prot" command to check a floppy disk when the AC
power failed for about one second and then came back on, rebooting the

The only time I was hit, was when I bought a new hd, that came complete
with the ripper, boot sector virus.

My current system is an ECS L7VMM3 motherboard, with AMI bios dated
2003-12-25.

Regards, Dave Hodgins

 

[FromTheRafters]

i've installed linux on a number of occasions... it's never forced me
(or even asked me) to create a user other than root...

Apparently some newer distros are attempting to force idiots
to do less idiotic things while installing and setting up Linux.

On my system, the prompt is how I know I am the root user, but
evidently some newer versions make the screen background red
so people who are prompt-blind can still tell.

Maybe they could learn something from Microsoft's "safe mode"
written in each corner of the screen - "DANGEROUS MODE"
w/blinking or flashing text should do. That way even complete
and utter idiots who are colorblind can use Linux too. :O)

 

[kurt wismer]

Apparently some newer distros are attempting to force idiots
to do less idiotic things while installing and setting up Linux.

On my system, the prompt is how I know I am the root user, but
evidently some newer versions make the screen background red
so people who are prompt-blind can still tell.

as far as i can tell that still doesn't equate to forcing or even
asking the user to create a non-administrative account...

and if the red background happens to be on a redhat distro then the
user is probably going to think it's normal...

Maybe they could learn something from Microsoft's "safe mode"
written in each corner of the screen - "DANGEROUS MODE"
w/blinking or flashing text should do. That way even complete
and utter idiots who are colorblind can use Linux too. :O)

maybe...

 

[Baruch.]

This is an open question, because I am genuinely curious, and because I
work with a lot of creators of Free/Libre and Open Source software....

It seems that many, many people who can afford computers and other
software want or expect to get a really good anti-virus product for
free. Why? Why should AV be free when almost everything else costs
money? Or do the folk who ask about a free AV also use free/libre and
open source software like OpenOffice (which, btw, I can highly
recommend)?

One of the main reasons is that much commercial software - maybe even all of
it - has licensing agreements that say, basically, that the software you get
belongs to the company (you don't own it); if it doesn't work or if it's
buggy, you may have no recourse; if it trashes your machine, you can only
get a refund, not payment for damage it causes; if you make copies for other
machines, you are breaking the law; and so on.

Often, the free software is created by people who simply love to program.
They take pride in what they do, enjoy it, and take the time to make it
right. Commercial software has huge competitive pressures - they *must*
ship it NOW, even if it's not ready, if it's still buggy. They can't afford
to fix it if it's buggy - there just isn't enough time, if they are to
survive.

For some insight into this concept (free software, Open Source, etc.), try
the Free Software Foundation at www.gnu.org. Here they mean "free as in
speech, not free as in beer", but often it's beer-free as well.