Hacker News Reader

Comment by linkregister | Hacker News Reader

Apache used forked processes; I don't think that's unique or a particular issue. NGINX uses async io to handle requests, which is a substantial upgrade from Apache; that's why it's performant.

Memory corruption vulnerabilities are possible whenever a language is used that performs copies of data across buffers without in-language guards.

This vulnerability does not require knowledge of the memory layout to generate worker crashes against a system with vulnerable configurations.

The vulnerability is not the end of the world. System administrators will upgrade nginx with the security patch when it's released across most distribution paths (right now it's available only on unstable Debian for example). In the meantime sysadmins will likely remove the vulnerable directives from nginx configs.

View on HN

> 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 :)

This a heap exploit. Threads share heap access with the main process.

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.

That's a reasonable solution.

Apache actually has had multiple modules for its concurrency for many years. The event and worker multi-processing modules use threading rather than forking.

Reply on news.ycombinator.com