l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2004 Jun 18 00:41

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Re: [vox] Linux viruses?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


> > 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
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.