I mean... you're missing the forest for the trees, but yes I meant "address space" generally not "stack" specifically. The nginx threads are forked, it would not be that terribly complex to set up a heap with a new random address base in each worker (the only real complexity is dealing with heap allocations which happened before fork()). But the stack matters too, generally moreso.
If the workers weren't forked, the entire process would die to the SIGSEGV, and when it restarted the heap would be at a new address because of ASLR. This exploit couldn't work against a threaded daemon for that reason (only one guess).
In a world where they are forked, having a randomized heap base in each worker would also defeat the brute force approach. Instead of just fork(), it could execve() itself with some arguments that tell it to be a worker and where to find its brain, that effectively do an ASLR for each worker.
I mean... you're missing the forest for the trees, but yes I meant "address space" generally not "stack" specifically. The nginx threads are forked, it would not be that terribly complex to set up a heap with a new random address base in each worker (the only real complexity is dealing with heap allocations which happened before fork()). But the stack matters too, generally moreso.
In your software, you set up a new heap for every pthread? I have never encountered this design pattern and would like to learn more.
If the workers weren't forked, the entire process would die to the SIGSEGV, and when it restarted the heap would be at a new address because of ASLR. This exploit couldn't work against a threaded daemon for that reason (only one guess).
In a world where they are forked, having a randomized heap base in each worker would also defeat the brute force approach. Instead of just fork(), it could execve() itself with some arguments that tell it to be a worker and where to find its brain, that effectively do an ASLR for each worker.