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

[Micah J. Cowan]

On Tue, Jun 15, 2004 at 09:32:39AM -0700, Jeff Newmiller wrote:
> 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.

So was I.

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

I don't see how that made it more easy than to add code to a DOS
executable, and remembering from those days, I'm surprised to hear you
say it was much worse than for DOS: my recollections are somewhat
different.

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

Gotcha.

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

Buffer overruns I'm acquainted with have no direct interaction with
the heap at all, at least not in the bootstrapping phase: they
generally work by overwriting the return pointer that the program uses
to remember where to return to after the function is finished
executing. The typical overrun for a string buffer works by causing
writes to the buffer to proceed past the end of the buffer, and into
the other local variables, including the return pointer (which
technically isn't a local variable, but precedes them on the stack,
which means it follows them in actual memory layout). It is only the
fact that the return pointer (may not be the right terminology, but I
think you know to what I refer) resides after the buffer that allows
the typical buffer overrun to work: if it resided before the buffer in
memory, an overrun would still be possible if there were a software
bug that allowed you to /decrease/ past the 0 index, but AFAICT these
bugs are far less common than those that allow you to /increase/ past
the end of a buffer.

But the heap generally doesn't enter into this at all AIUI.

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

Sure, I got plenty of "stack crashed into heap" errors when learning
to program on my Mac.

-- 
Micah J. Cowan
micah at cowan.name