4 ms·
> Apache used forked processes; I don't think that's unique or a particular issue. Of course it is... in a typical threaded daemon, the threads have randomized
by jcalvinowens 5mo ago
> Apache used forked processes; I don't think that's unique or a particular issue.
Of course it is... in a typical threaded daemon, the threads have randomized stack addresses. Exactly as you observed, you get unlimited tries because nginx dutifully restarts the worker process with the same literal stack address every time it segfaults. I'm willing to bet the ASLR break they claim to have relies on that, but I'd be happy to be proven wrong if they publish it :)
- linkregister 5mo agoThis a heap exploit. Threads share heap access with the main process.
- jcalvinowens 5mo agoI 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.
- linkregister 5mo agoIn your software, you set up a new heap for every pthread? I have never encountered this design pattern and would like to learn more.
- jcalvinowens 5mo agoIf 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.
- linkregister 5mo agoThat's a reasonable solution.