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

31–40 of 116 posts

Re: New Nginx Exploit

#31

Post by [deleted] »

jcalvinowens wrote: post #29
linkregister wrote: post #23

Earlier quoted context omitted.

Worker processes are forked from the master, which means they receive the same memory layout. You get unlimited crashes against the worker. There's probably a way to exploit that to get a read oracle. At the very least this is a reliable denial of service. Depth First's full writeup: https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

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.

[deleted]

Re: New Nginx Exploit

#32

Post by ptx »

Is there a good alternative to Apache and Nginx that's written in a memory-safe language and not full of security holes? I briefly looked at Jetty (written in Java) and Caddy (written in Go) but they seem to have a history of vulnerabilities of other types (e.g. shell injection in Jetty) so I'm not sure they would be any better.

Re: New Nginx Exploit

#34

Post by embedding-shape »

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…

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

Re: New Nginx Exploit

#35

Post by embedding-shape »

ptx wrote: post #32

Is there a good alternative to Apache and Nginx that's written in a memory-safe language and not full of security holes? I briefly looked at Jetty (written in Java) and Caddy (written in Go) but they seem to have a history of vulnerabilities of other types (e.g. shell injection in Jetty) so I'm not sure they would be any better.

Caddy been a breeze to use, bit sucky model with "we have thousands of binaries depending on what combination of plugins you want" instead of a proper plugin system, but if you're building it from source, it's pretty nifty and simple anyways.

Re: New Nginx Exploit

#37

Post by iririririr »

panzi wrote: post #24

Does Debian 12 have this patched? But I guess I'm not affected if I don't use `rewrite` or `set` anywhere?

I find it very unlikely that anyone using nginx does NOT use `set` at least.

Most nginx use cases are to end tls and then pass the request to node/php/go/etc. So, I bet you have at least one set with attacker controller data on a line like 'proxy_set_header X-Host $host;'

edit: nvm. aparently named captures are not affect. Unless you have a $1 somewhere, it should be fine.

Re: New Nginx Exploit

#39

Post by dgellow »

ptx wrote: post #32

Is there a good alternative to Apache and Nginx that's written in a memory-safe language and not full of security holes? I briefly looked at Jetty (written in Java) and Caddy (written in Go) but they seem to have a history of vulnerabilities of other types (e.g. shell injection in Jetty) so I'm not sure they would be any better.

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

Re: New Nginx Exploit

#40

Post by gavinsyancey »

jcalvinowens wrote: post #29
linkregister wrote: post #23

Earlier quoted context omitted.

Worker processes are forked from the master, which means they receive the same memory layout. You get unlimited crashes against the worker. There's probably a way to exploit that to get a read oracle. At the very least this is a reliable denial of service. Depth First's full writeup: https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

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.
Post reply on HN