Re:How security flaws work: the buffer overflow
by scott_s on Wednesday August 26, 2015 @10:17AM
(#10122995)
Yes. Why would you think not?
If you're thinking that memory for the program is less likely to be contiguous, then, yes, that is a way it may end up being less likely. But there are already techniques that do exactly that for systems with virtual memory (see https://plasma.cs.umass.edu/emery/diehard.html). But as long as you have a stack frame contiguous with a previous stack frame, you're susceptible to buffer overflows, and I think that will be likely even without virtual memory. (That is, the stack frames are not that large, and are likely to be well within the contiguous block size for the memory system.)
Re:How security flaws work: the buffer overflow
by pyre on Wednesday August 26, 2015 @10:02AM
(#10122871)
As long as you have the ability to address memory directly, I would say that it's possible. I'm not 100% sure about how memory is allocated though. Outside of virtual memory, are the actual chunks of memory sequential, or would overflowing an offset get you a chunk of another process? (I imagine the answer might be implementation dependent)
Re:How security flaws work: the buffer overflow
by shanemhansen on Wednesday August 26, 2015 @11:52AM
(#10123755)
It's more important to have bounds checked access and to disallow pointer arithmetic. If you do that, pointers (addresses) are fine.
I know how I would answer this question but I am curious how others would answer it.
EDIT: s/possible/known to occur