Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Nginx Exploit

github.com

Post reply on HN
Print view View original

91–100 of 116 posts

Re: New Nginx Exploit

#91

Post by staticassertion »

nicce wrote: post #58
RagingCactus wrote: post #27

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 mak…

> 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…

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?

Re: New Nginx Exploit

#92

Post by jeroenhd »

RagingCactus wrote: post #27

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 mak…

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.

Re: New Nginx Exploit

#93

Post by nicce »

l23k4 wrote: post #89
zrobotics wrote: post #86

Earlier quoted context omitted.

Bold claim without any provided source. Do you have a link to back up that ASLR is a complete non-factor?

I'm deliberately refraining from giving a ready LLM prompt. History shows that "meh, ASLR mitigates this" is a vastly bolder claim anyway, so I don't feel much need to defend my position here. Edit: Even the authors of this poc seem to agree with me https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

> History shows that "meh, ASLR mitigates this" is a vastly bolder claim anyway, so I don't feel much need to defend my position here.

Obviously you need to defend, that is quite generalization there. You need to prove how the vulnerability itself reduces the entropy of ASLR.

The authors don't really give support for that. They just say that they can brute-force it without crashing the whole Nginx. But they don't say how the entropy is reduced. They have zero information where the child process even starts, whether they hit the child, or if it even is the same child. So you should provide us technical and precise reasoning why it is not mitigating?

Re: New Nginx Exploit

#94

Post by l23k4 »

nicce wrote: post #93
l23k4 wrote: post #89

Earlier quoted context omitted.

I'm deliberately refraining from giving a ready LLM prompt. History shows that "meh, ASLR mitigates this" is a vastly bolder claim anyway, so I don't feel much need to defend my position here. Edit: Even the authors of this poc seem to agree with me https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

> History shows that "meh, ASLR mitigates this" is a vastly bolder claim anyway, so I don't feel much need to defend my position here. Obviously you need to defend, that is quite generalization there. You need to prove how the vulnerability itself reduces the entropy of ASLR. The authors don't really give support for that. They just say that they can brute-force it without crashing the whole Nginx. But they don't say…

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.

Re: New Nginx Exploit

#95

Post by saagarjha »

nicce wrote: post #58
RagingCactus wrote: post #27

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 mak…

> 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…

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.

Re: New Nginx Exploit

#96

Post by GoblinSlayer »

ptx wrote: post #50
dgellow wrote: post #39

Earlier quoted context omitted.

Any software used at the scale of Apache and nginx will have a history of vulnerabilities. The fact they both survived with their market share for so long is a good sign

Right, that's essentially what I'm thinking. On the one hand Apache and Nginx are mature and proven but, being written in C, they will always suffer from memory-safety issues like this one and the recent Apache vulnerabilities. On the other hand, the alternatives are perhaps not as mature and perhaps not implemented as securely as they could be, given that e.g. Caddy had multiple vulnerabilities in its request parsin…

LDAP feature can be removed from log4j, but buffers can't be removed from nginx. Technically, bounds checking can be implemented, but presumably nginx has no plans for it, because it's anathema.

Re: New Nginx Exploit

#98

Post by nicce »

l23k4 wrote: post #94
nicce wrote: post #93

Earlier quoted context omitted.

> History shows that "meh, ASLR mitigates this" is a vastly bolder claim anyway, so I don't feel much need to defend my position here. Obviously you need to defend, that is quite generalization there. You need to prove how the vulnerability itself reduces the entropy of ASLR. The authors don't really give support for that. They just say that they can brute-force it without crashing the whole Nginx. But they don't say…

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 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.

Additionally, for RCE, you need to find libc base and that is randomized alone. Authors just ignored in the post how they got that address. For that, you most likely need the information leak from second vulnerability, even if you can brute force the actual vulnerability.

Re: New Nginx Exploit

#99

Post by nicce »

staticassertion wrote: post #91
nicce wrote: post #58

Earlier quoted context omitted.

> 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…

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?

Re: New Nginx Exploit

#100

Post by GoblinSlayer »

tredre3 wrote: post #60
jhatemyjob wrote: post #41

tl;dr If you don't use ngx_http_rewrite_module, you're fine Honestly it's such a weird feature, if you're doing complicated redirects like this in nginx where PCRE is necessary, you should do it in your application code. And if you need speed use ngx_http_lua_module.

Your opinion is that if, for a godforsaken reason, someone needs to rewrite URLs in their web server, they should avoid PCRE (something designed for string manipulation) because it's overkill, and they should use Lua (a full programming language) instead? Am I understanding you correctly?

Because lua supports string manipulation without buffer overflows.
Post reply on HN