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

[Jeff Newmiller]

On Tue, 15 Jun 2004, Micah J. Cowan wrote:

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

I thought the grammatical construction "that OS" followed by "than under
DOS" would have made my meaning clear.  Anyway, you apparently _did_
misunderstand me... DOS executables don't have structured resource forks
with relocatable code all over the place, so infecting DOS executables
required some tricky code alterations, and there wasn't much memory to
"hide" in.

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

Good point... I forgot about "buffers" among the stacks going different
ways.  Of course, since signed arithmetic is generally used for buffer
offsets, a _constructed_ "exploit" should be indifferent to the direction
the stack is going in any case. ;)

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

Indubitably.  I still think it likely that you got more pointer
dereferencing bugs than stack overrun bugs... and loose pointers can
damage other running apps, so my point that the placement of the stacks
had very little effect on the robustness of the system remains valid,
though a little off topic in a discussion of exploits.

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