Would this apply to non-Linux builds too, i.e. FreeBSD / OpenBSD...?
New Nginx Exploit
101–110 of 116 posts
Re: New Nginx Exploit
#102As a security person it is tiring to see so many people here either directly claim or at least allude to the claim that this is somehow much less scary because the _published_ exploit does not bypass ASLR. The writeup claims there is a way to reliably bypass ASLR with this attack. And that is a good default assumption I would be willing to believe without evidence. ASLR is a defense-in-depth technique intended to mak…
So the PoC works on MIPS out of the box. Tons of Linux/MIPS running around (Loongson64 seems to have KASLR on Linux).
Re: New Nginx Exploit
#103It seems that Snyk isn't picking this up on our docker images. They have a vulnerability published for the nginx binary itself.
https://security.snyk.io/vuln/SNYK-UNMANAGED-NGINX-16679754
But they've not released any vulnerability for the Alpine or Debian packages.
Does anyone know what's happening here? Seems concerning that there's a 2 day old RCE not being picked up.
Re: New Nginx Exploit
#104As a security person it is tiring to see so many people here either directly claim or at least allude to the claim that this is somehow much less scary because the _published_ exploit does not bypass ASLR. The writeup claims there is a way to reliably bypass ASLR with this attack. And that is a good default assumption I would be willing to believe without evidence. ASLR is a defense-in-depth technique intended to mak…
I'm with you, once an RCE is known, it's usually just a matter of time before it gets script-kiddied and easy to run. Don't put yourself through the pain, just upgrade nginx.
I just finished upgrading a weird embedded box that required compiling a static nginx binary and moving it over. It's more annoying than apt update;apt upgrade or whatever your OS distribution needs, but it's still not that hard.
Re: New Nginx Exploit
#105Earlier quoted context omitted.
There are heaps of literature on this exact topic. https://www.researchgate.net/publication/292156221_How_to_Ma... > You need to prove how the vulnerability itself reduces the entropy of ASLR Not really? Looks like we have a controlled-length overflow on a fork-based server, a situation where ASLR is known to not be very useful.
> Not really? Looks like we have a controlled-length overflow on a fork-based server, a situation where ASLR is known to not be very useful. It does not work like that - it has certain pre-condition requirements. You also need a reliable oracle which tells information when you actually hit the child process, whether child crashes and whether you are even in the same child. When you can retrieve this information, you…
>It does not work like that - it has certain pre-condition requirements. You also need a reliable oracle which tells information when you actually hit the child process, whether child crashes and whether you are even in the same child. When you can retrieve this information, you are then removing re-randomization between attempts. That reduces the entropy, but it only helps if remaining search space is small enough. They don't show that they have oracle.
Why are you assuming there's any re-randomization going on? There isn't. That's a proposed mitigation to address this known problem with fork-based servers.
Re: New Nginx Exploit
#106This one's pretty bad but there are some preconditions. Requires a "rewrite" directive with a questionmark in the replacement string, and then a subsequent "set" directive that references a regex capture group (e.g. set $var $1). Also the POC assumes ASLR is disabled.
I think "rewrite" is rarely used nowadays? Isn't it something from old days of PHP and Apache?
PHP? You mean that little language behind WordPress?
Re: New Nginx Exploit
#107Earlier quoted context omitted.
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…
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 w…
Apache actually has had multiple modules for its concurrency for many years. The event and worker multi-processing modules use threading rather than forking.
Re: New Nginx Exploit
#108As a security person it is tiring to see so many people here either directly claim or at least allude to the claim that this is somehow much less scary because the _published_ exploit does not bypass ASLR. The writeup claims there is a way to reliably bypass ASLR with this attack. And that is a good default assumption I would be willing to believe without evidence. ASLR is a defense-in-depth technique intended to mak…
So the PoC works on MIPS out of the box. Tons of Linux/MIPS running around (Loongson64 seems to have KASLR on Linux).
Don't forget all the cheap WiFi routers with MT7688/MT7628/etc MIPS chips.
Re: New Nginx Exploit
#109Earlier quoted context omitted.
Information leaks are not uncommon at all. nginx seems like a good target for them as well (fork + exec == no re-randomize, so you have the ability to reexec your exploit a lot of times to improve stability). edit: Seems that there's already good work in this area, I kinda forgot about brop gosh I'm old https://www.scs.stanford.edu/brop/ I suppose to keep the password analogy together, people reuse passwords all the…
For this particular bug, for that to apply, you need some sort of oracle which tells that you are actually in the same child process that skips re-randomization before you can reduce the entropy. Based on this post, I cannot see that there is stable oracle to tell that?
I'm not making a claim about this bug, I'm saying that oracles and leaks are common and that nginx seems like a good target for them.
Re: New Nginx Exploit
#110Earlier quoted context omitted.
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.