[vox-tech] Re: [vox] Linux viruses?

[Jeff Newmiller]

On Mon, 14 Jun 2004, Micah J. Cowan wrote:

[...]

> I have also felt that the very low market-share of Mac OS (in
> comparison to Winblows) simply kept the attention of virus-writers off
> of it.

I used to be a Mac-phile back in Mac128 and MacPlus days.  I used to
collect lots of Mac software off of USENET binary distributions
newsgroups.  Virus problems were much worse in that OS than under DOS,
because with code stored in the structured Resource Fork, adding
pre-execution code was relatively easy.  Also, DOS didn't really seem to
offer as much attraction to virus writers.  This situation reversed over
the next few years, and for awhile there were some nasty DOS viruses
running around infecting boot blocks on the new hard disks people were
using.  I find it amusing that Mac people these days feel superior because
they don't have virus problems.  They may well be better off because they
offer fewer interoperable network services (openings to exploit), or
because they now run with memory management hardware (Apple had a hell of
a time with compatibility introducing MMUs), or because virus writers
don't care to make the effort, or because they have such a small installed
base, but not because their OS is better.

> Also, IIRC (which I may not), the stack on at least the older
> Macs runs in the /reverse/ of Windows and typical Unix OSses, so that
> buffer overruns tend to be far less fruitful, as the return pointer
> resided /behind/ local variables on the stack, in the opposite
> direction that string access and the like would take place. But I'm
> not sure of this.

You probably recall the graphical presentation of stacks described in the
Motorola vs. Intel documentation... for no reason I could figure out, the
Intel documentation always put address 0 at the bottom of the diagram,
while Motorola always put it at the top.  In both cases, the stack pointer
value is decreased when data is added to the stack.  I am told some
mainframe architectures grew the stack with increasing addresses, but I
never worked on any.

As for your assertion that if this were the case it this would somehow
make the OS or its applications less vulnerable, I don't think that
washes.  Logically, the heap has to be at one end of the available data
space, and the stack has to be at the other end.  There are some
architectures that put the stack in its own special memory, but this is
logically equivalent to putting it in a larger address space with memory
protection between the stack and the heap, which is the accepted practice
these days. (If you split the memory, and grow both the stack and heap
upward in an unprotected environment, the stack will roll over the top
onto the bottom of the heap anyway.)

MacOS did traditionally partition memory into separate pools for each
application (I haven't reviewed MacOS memory management updates for years;
but this is inherent in legacy Mac apps), which could prevent stack
overflow from affecting OTHER applications, but since wayward pointers in
a non-memory-managed environment were/are still the most common bug, you
could not gamble on that feature providing any kind of effective
protection.

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil at dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------