> From: Mouse > As for buffer overruns, the point there is that a buffer overrun > clobbers memory addressed higher than the buffer. If the stack grows > down, this can overwrite stack frames and/or callers' locals.
Oh, right. Duhhhh! Buffers typically grow upward, no matter which direction the stack grows. So the two directions for stack growth aren't purely a convention. Of course, in Multics, especially with AIM (Access Isolation Mechanism), stack buffer attacks are much less dangerous. E.g. even without AIM, the attacker can't load code into the stack, and return to it - generally the stack segment had execute permission turned off. And AIM really limits what 'bad' code can get up to. I keep ranting about it's pointless to expect programmers to write code without security flaws, it needs to be built in to the low levels of the system (one of Multics' many lessons - it wasn't _really_ secure until the 6180 moved the ring stuff into hardware, instead of simulating it in software, as on the 645). And so as long as we continue to allow Web pages to contain 'active' content (i.e. code), so that random code from all over the planet gets loaded into our computers and run, browsers will neve be secure; they need to be run in an AIM box. Noel