Comment by RagingCactus
21 hours ago
As 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 make exploitation more difficult. In almost all cases it is only a matter of time and skill to also include an ASLR bypass. Both requirements continue being lowered by LLM agents every few weeks. It is only a matter of time (and probably not a lot of time) until a fully weaponized exploit is developed. It may be published, it may also be kept private.
It is straight up wrong to say "if you have ASLR enabled, you're not at any risk from this" and saying this is extremely harmful for anyone that trusts claims like that.
This wrong belief that you shouldn't care about security vulnerabilities because mitigations may make exploitation more difficult has already caused so much harm in the past. Be glad that modern mitigations exist, but patch your stuff asap. If you are a vendor, do not treat vulnerability reports as invalid because the researcher has not provided an ASLR bypass. Fix the root cause and hope mitigations buy you enough time to patch before you get owned.
No remotely reachable vuln should be taken lightly.
At the moment though, the preconditions look odd. I've been using nginx in various constellations for 10 years and never once combined rewrite and set.
There can be situations where you set some variables on top level and then override those in the location block with rewrite. These variables could be then used e.g. in log lines or in other "global" contexts.
Not extremely common, but it does happen.
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.
I think some people's comments are misinterpreted as well. When people say "the PoC requires ASLR to be disabled" that doesn't necessarily mean the exploit is useless, but it does mean that the risk of automated exploit bots downloading the PoC and pwning random servers is reduced for now.
It's a matter of time before this exploit is chained with an ASLR bypass, but it allows for a slightly wider patch window at the very least.
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.
> ASLR is a defense-in-depth technique intended to make exploitation more difficult. In almost all cases it is only a matter of time and skill to also include an ASLR bypass. Both requirements continue being lowered by LLM agents every few weeks. It is only a matter of time (and probably not a lot of time) until a fully weaponized exploit is developed. It may be published, it may also be kept private.
I disagree with this take, or I would at least phrase it differently. ASLR is like an extra password you need to guess. It has certain amount of entropy and it is usually stable. Unless vulnerability has a portion that leaks information, ASLR completely mitigates it - or you need a second vulnerability. And that is a different conversation. ASLR can completely mitigate individual vulnerability, but not possibly exploit chain.
I would use the argument of possible second vulnerability that leaks information for making people patch quickly anyway. But exploit chains are risk for all kinds of vulns.
The idea is that ASLR bypasses are comparatively cheap, so yes, a chain without this is useless, but it's not that hard to find one. Probably much easier than the bug described here.
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 time, timing attacks exist, etc?
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?
1 reply →
Anyone even vaguely familiar with exploiting nginx knows that ASLR is a complete non-factor here.
Bold claim without any provided source. Do you have a link to back up that ASLR is a complete non-factor?
5 replies →
Could you explain for those who are not? :)
> and saying this is extremely harmful for anyone that trusts claims like that.
Kind of feels like the burden is on the one who is reading it though, good luck stopping people from spreading misinformation on the internet, most of them don't even know they're wrong.
What's extremely harmful is trusting random internet comments stating stuff confidently. Get good at seeing through that, and it'll serve you well in security and beyond.
yeah when I read these RCE reports about public-facing software that I know about I usually upgrade them within minutes of reading the report that's why I read these reports and you really have to take them seriously because otherwise your machine gets compromised, sooner rather than later... it seems like lately there's been no advance notice on a lot of these RCE exploits that are publicly released, I mean come on guys at least give us a few minutes to upgrade our software before releasing the exploit, it feels like the late 1980s early 1990s when there was no guardrails on disclosure, i.e. all the remotely exploitable sendmail bugs. people who fail to read these reports or read them too late wind up having millions of machines being compromised because of it. currently nginx has about a 39% - 43% share of the public facing web server market today, so its pretty serious.
> It is straight up wrong to say "if you have ASLR enabled, you're not at any risk from this" and saying this is extremely harmful for anyone that trusts claims like that.
You can safely assume a 1:1 overlap between the people that claim "AI will solve cyber" (and they always say 'cyber') and the people saying this.