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

[Micah J. Cowan]

On Tue, Jun 15, 2004 at 02:43:30PM -0700, Jeff Newmiller wrote:
> > > 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...

How did I misunderstand you? I also said "much worse than for
DOS". Referring to virus problems, not anything regarding Resource Forks...

<snip>

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

How so? The constructed exploit can't generally affect how the buffer
index gets used, and unless the code is written with a decrementing
index, then nothing you write is going to get at a return pointer that
/precedes/ the buffer, unless I'm missing something...

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

I got very used to hitting the restart button... ;-)

Thank God for virtual memory.

Of course, IIRC, Mac's first attempt at "virtual memory" still did
nothing to help: they weren't separate memory spaces...

-- 
Micah J. Cowan
micah at cowan.name