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 [EMAIL PROTECTED] _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
