41–50 of 116 posts
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.
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.
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…
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.
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.
Does Debian 12 have this patched? But I guess I'm not affected if I don't use `rewrite` or `set` anywhere?
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.
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.
Does Debian 12 have this patched? But I guess I'm not affected if I don't use `rewrite` or `set` anywhere?
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.
# regex to split $uri to $fastcgi_script_name and $fastcgi_path
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
set $path_info $fastcgi_path_info;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
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 parsing this year and Jetty's shell injection vulnerability seems easily foreseeable and avoidable. Using a memory-safe language doesn't help much if you then (to take an unrelated but well-known example) implement arbitrary code execution as a feature in the logging library.