l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
September 2: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
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...

<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@cowan.name
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
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:
O'Reilly and Associates
For numerous book donations.