Why Free?

On Sat, 20 Mar 2004 11:23:16 -0500, "FromTheRafters" <!0000@nomad.fake>
wrote:

>
>"BoB" <me.TakeThisOut@privacy.net> wrote in message news:3teo50d706a48qp63kei0luom6sv09i6pp@4ax.com...
>> On Fri, 19 Mar 2004 20:23:48 GMT, null.TakeThisOut@zilch.com wrote:
>>
>> >On Fri, 19 Mar 2004 14:45:30 -0500, BoB <me.TakeThisOut@privacy.net> wrote:
>> >
>> >>On Fri, 19 Mar 2004 06:24:16 -0500, Cathrine Lowther
>> >><janusNOSAP.TakeThisOut@PLEASEmagma.ca> wrote:
>> >
>> >>>Don't get me wrong -- for years, I was a happy user of F-Prot for DOS,
>> >>>which was and is free. Now I am an equally happy user of F-Prot, for
>> >>>which I pay a really small annual sum, compared to the cost of any
>> >>>other commercial software on my machine(s).
>> >>
>> >>Are you saying that you now use F-Prot for windows? Some malware can
>> >>destroy all windows based AV's. I hope you also retained F-Prot for DOS.
>> >
>> >She may be using Win XP.
>>
>> Not being an XP user, I won't even ask why. It is nice to hear a
>> positive statement about XP.
>
>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
 >> Stay informed about: Why Free? 

On Sat, 20 Mar 2004 20:02:01 -0500, kurt wismer <kurtw.TakeThisOut@sympatico.ca>
wrote:

>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
 >> Stay informed about: Why Free? 

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.

> The security model used by *nix makes viruses so helllishly difficult to
> design that it simply is not a real threat.
>
>
 >> Stay informed about: Why Free? 

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

--
Pozdro
bobas007
 >> Stay informed about: Why Free? 

JT wrote:
> On Sat, 20 Mar 2004 18:48:34 -0500, kurt wismer <kurtw.DeleteThis@sympatico.ca> wrote:
>>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)...

>>>Most programs
>>>should be limited in what they can access and the functions they perform.
>>
>>most security treats programs as agents of a user or principle and so
>>those limits are based on the limits of what that user can do...
>>
>>if we decide to additionally treat the programs themselves as
>>principles then there will still be some programs that have the
>>authority required by a virus to do it's dirty deed... and we'll have
>>increased the complexity of maintaining the security of the system
>>tremendously since each and every program will need to be assigned the
>>kinds of permissions we would normally only have to worry about for
>>users...
>
> 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)...

>>>Having system files read only or execute only doesn't reduce their
>>>usability. Memory protection, which limits the memory a program can use, is
>>>necessary for multiprogramming systems. Making parts of the file system off
>>>limits to average programs does not reduce the ability of a machine to be
>>>useful. Limiting the capability of generating an executable to a very
>>>limited set of programs and circumstances doesn't limit the ability of user
>>>to run programs.
>>
>>so are you saying that there should be a crack-down "ren xzy.dat xyz.exe"?
>
>
> 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]
>>and what about file types that are outside the system's preconceived
>>notions of what an executable is but are no less executable in some
>>manner (say interpreted scripts, for example)?...
>
>
> 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...

--
"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"
 >> Stay informed about: Why Free? 

JT wrote:
> On Sat, 20 Mar 2004 18:48:34 -0500, kurt wismer <kurtw.TakeThisOut@sympatico.ca> wrote:
>>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)...

>>>Most programs
>>>should be limited in what they can access and the functions they perform.
>>
>>most security treats programs as agents of a user or principle and so
>>those limits are based on the limits of what that user can do...
>>
>>if we decide to additionally treat the programs themselves as
>>principles then there will still be some programs that have the
>>authority required by a virus to do it's dirty deed... and we'll have
>>increased the complexity of maintaining the security of the system
>>tremendously since each and every program will need to be assigned the
>>kinds of permissions we would normally only have to worry about for
>>users...
>
> 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)...

>>>Having system files read only or execute only doesn't reduce their
>>>usability. Memory protection, which limits the memory a program can use, is
>>>necessary for multiprogramming systems. Making parts of the file system off
>>>limits to average programs does not reduce the ability of a machine to be
>>>useful. Limiting the capability of generating an executable to a very
>>>limited set of programs and circumstances doesn't limit the ability of user
>>>to run programs.
>>
>>so are you saying that there should be a crack-down "ren xzy.dat xyz.exe"?
>
>
> 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]
>>and what about file types that are outside the system's preconceived
>>notions of what an executable is but are no less executable in some
>>manner (say interpreted scripts, for example)?...
>
>
> 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...

--
"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"
 >> Stay informed about: Why Free? 

Kelsey Bjarnason wrote:

> [snips]
>
> In article <hO57c.27118$Eb6.917623@news20.bellglobal.com>,
> kurtw.DeleteThis@sympatico.ca says...
>
>
>>>No, they're more than that. They are programs that rely on security
>>>holes in the OS that allow them to propagate and do damage.
>>
>>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...

--
"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"
 >> Stay informed about: Why Free? 

Kelsey Bjarnason wrote:

> [snips]
>
> In article <hO57c.27118$Eb6.917623@news20.bellglobal.com>,
> kurtw.DeleteThis@sympatico.ca says...
>
>
>>>No, they're more than that. They are programs that rely on security
>>>holes in the OS that allow them to propagate and do damage.
>>
>>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...

--
"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"
 >> Stay informed about: Why Free? 

JT wrote:
> On Sat, 20 Mar 2004 19:52:38 -0500, kurt wismer <kurtw.RemoveThis@sympatico.ca> wrote:
>>JT wrote:
>>>On Sat, 20 Mar 2004 17:20:04 -0500, kurt wismer <kurtw.RemoveThis@sympatico.ca> wrote:
>>>>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...

>>>>>As an exercise, find a Virus or worm (not a phishing/human
>>>>>engineering exploit that tricks a user into running a program that erases
>>>>>his hard disk thinking it was a free game) that does not exploit such a
>>>>>weakness in all the online virus information. Just get me a couple out of
>>>>>the thousands that are out there. Something recent would be nice, but I am
>>>>>not picky
>>>>
>>>>stoned.empire.monkey (or rather, most boot infectors)... cascade (or
>>>>rather, most file infectors)...
>>>
>>>Weakness in that the OS lets code directly talk to hardware.
>>
>>i'm guessing you don't really understand viruses here... boot infectors
>>execute before the operating system has even has a chance to load...
>>the operating system can't do bugger all about viruses like
>>stoned.empire.monkey...
>
> 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...

>>>Shouldn't do
>>>that except is special cases. OS should not let executable files be
>>>written to that easily either. It is a flaw in the design concept there.
>>
>>that easily? the same thing is possible in any OS...
>
> 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...

>>>In Linux (and most Unix like OS's such as Apples OS/X) executable files
>>>are not kept in the users home directory with a few exceptions.
>>
>>the standard system executables aren't, but there are plenty of
>>executables that aren't standard system executables...
>>
>
> 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]
>>>All system
>>>executables, and most regular application executables are in directorys
>>>where the average user can't write.
>>
>>that depends entirely on who installed the application...
>
> 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...

>>and it totally ignores the possibility of script viruses...
>
> 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...

>>>The disk is also protected from direct
>>>disk writes by all but a few privileged programs.
>>
>>only while the OS is running...
>
> 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...

>>>The virus's you mentioned
>>>exploit flaws in the DESIGN of most MS operating systems. Ones that are
>>>not there in other OS's.
>>
>>then why can stoned.empire.monkey (and most other boot infectors)
>>infect linux boxes?
>
> 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...

--
"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"
 >> Stay informed about: Why Free? 

JT wrote:
> On Sat, 20 Mar 2004 19:52:38 -0500, kurt wismer <kurtw RemoveThis @sympatico.ca> wrote:
>>JT wrote:
>>>On Sat, 20 Mar 2004 17:20:04 -0500, kurt wismer <kurtw RemoveThis @sympatico.ca> wrote:
>>>>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...

>>>>>As an exercise, find a Virus or worm (not a phishing/human
>>>>>engineering exploit that tricks a user into running a program that erases
>>>>>his hard disk thinking it was a free game) that does not exploit such a
>>>>>weakness in all the online virus information. Just get me a couple out of
>>>>>the thousands that are out there. Something recent would be nice, but I am
>>>>>not picky
>>>>
>>>>stoned.empire.monkey (or rather, most boot infectors)... cascade (or
>>>>rather, most file infectors)...
>>>
>>>Weakness in that the OS lets code directly talk to hardware.
>>
>>i'm guessing you don't really understand viruses here... boot infectors
>>execute before the operating system has even has a chance to load...
>>the operating system can't do bugger all about viruses like
>>stoned.empire.monkey...
>
> 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...

>>>Shouldn't do
>>>that except is special cases. OS should not let executable files be
>>>written to that easily either. It is a flaw in the design concept there.
>>
>>that easily? the same thing is possible in any OS...
>
> 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...

>>>In Linux (and most Unix like OS's such as Apples OS/X) executable files
>>>are not kept in the users home directory with a few exceptions.
>>
>>the standard system executables aren't, but there are plenty of
>>executables that aren't standard system executables...
>>
>
> 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]
>>>All system
>>>executables, and most regular application executables are in directorys
>>>where the average user can't write.
>>
>>that depends entirely on who installed the application...
>
> 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...

>>and it totally ignores the possibility of script viruses...
>
> 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...

>>>The disk is also protected from direct
>>>disk writes by all but a few privileged programs.
>>
>>only while the OS is running...
>
> 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...

>>>The virus's you mentioned
>>>exploit flaws in the DESIGN of most MS operating systems. Ones that are
>>>not there in other OS's.
>>
>>then why can stoned.empire.monkey (and most other boot infectors)
>>infect linux boxes?
>
> 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...

--