3 ms·
ASLR is a pretty hackish solution to the main problem, which is that the function call stack and parameter stack are combined. The problems that ASLR mitigates
by hyc_symas 12y ago
ASLR is a pretty hackish solution to the main problem, which is that the function call stack and parameter stack are combined. The problems that ASLR mitigates don't exist in languages like Forth, where there are two separate stacks - a call stack and a separate parameter stack.
- StillBored 12y agoThis is really an ABI issue, more than a language one. I'm not sure anything in C requires a combined stack. Plus, processor arches like ARM and POWER use link registers rather than a stack to store the return address. Its the ABI that then chooses to put the LR on the parameter stack. Even on x86 SP could be dedicated as a function stack and separated from BP (or pick another x86_64 register) as the parameter stack. Of course being an ABI issue, probably makes it really hard to solve, and hence hacky solutions abound. (actually its probably pretty easy to solve given LLVM, just impossible to get anyone to accept).
- hyc_symas 12y agoHm, you may be right that nothing in C requires it. But things like POSIX pthreads do - e.g. pthread_attr_setstack() only lets you set a single stack address and size. So yes, you'd have to create a new runtime from the ground up, not just a new ABI for an existing API.
- q3k 12y agoARM does store the return PC in a link register, but unless you're in a leaf function, it will still be pushed into the stack and can be overwritten by overflows.
- q3k 12y agoIt's foolish to think ASLR only prevents stack smashes - it also prevents unlink-style attacks via heap overflows and use-after-frees, data overflows into pointers and other segments, and many other vectors. Yes, it is a mitigation strategy that wouldn't exist in an ideal world. But we have to do best with what we have, and security takes a very pragmatic approach at this.