Comment by jcalvinowens
20 hours ago
Sure, but I think the github README ought to make it more clear the POC as-is doesn't work against nginx on any current Linux distro.
20 hours ago
Sure, but I think the github README ought to make it more clear the POC as-is doesn't work against nginx on any current Linux distro.
So you're not vulnerable to script-kiddies running the published PoC. Still probably vulnerable to to a sufficiently-motivated attacker.
I doubt it: aslr is not as easy to break on modern Linux as everyone in this thread wants to pretend it is. And anybody who actually cares so much about security that a compromised web frontend is the end of the world should be doing other things which would additionally mitigate this...
I know they claimed they can bypass it: if that's true, they should publish it. The forking nature of nginx is uniquely bizarre and vulnerable, and I strongly suspect that's the only way they're pulling it off. I feel like that's the interesting thing here, not the buffer overrun.
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.
4 replies →