Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In fact the mitigations have been so effective that in practice stack smash attacks are mostly historical at this point. But yes: having the direction of "natural memory copies" be the same direction as "back into the caller memory on the stack" was clearly a really bad mistake in hindsight.

I actually don't know where it came from. It was true in original PDP-11 Unix for sure: you had the program text followed by a grows-up heap, with the grows-down stack placed at the top of the program segment. Interestingly PDP-11 addressing was general enough to have implemented a grows-up stack, so this is clearly a mistake Unix could have corrected. I just don't know if this was the original use of the convention or if it inherited it from elsewhere.



Interestingly, per my reading of [1], these attacks are now easily available again in WASM due to misplaced confidence in the security of the language. It's a fantastic paper.

[1] https://www.unibw.de/patch/papers/usenixsecurity20-wasm.pdf


I THINK that the reason is: 8086 inherited it from the 8085 which inherited it from the 8080. The next parent in line would be the 8008, but that has a small call stack in the CPU registers rather than RAM, so the ancestor would be the 8080.

The 8080 had 64KB address space. I bet the rationale was to partition memory so that classic memory usage goes upwards from 0000 to FFFF and the stack goes downwards from FFFF to 0000. This removes the need to define a boundary between the two beforehand.

Of course this is totally speculation on my part, I might be super wrong.


The 8008 instruction set was not designed by Intel IIRC, so the lineage ends at the 8080.

Independently the 6502 also had a downward stack. I think the only modern machine with am upward-growing stack is the HP PA-RISC.


Stack smashing is still possible if you have a way to leak data (specifically, the cookie) beforehand.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: