4 ms·
Hehe, when I heard about the attack a couple of days ago I was interested to know if Nginx was affected and did a search on Google for the CVE of that attack fo
by codetrotter 3y ago
Hehe, when I heard about the attack a couple of days ago I was interested to know if Nginx was affected and did a search on Google for the CVE of that attack followed by the name of Nginx.
I didn’t find anything relevant so I assumed that Nginx was not affected.
Turns out that was not a good assumption :p
- herpderperator 3y agoIf you read the article, you'll see that the default configuration is not affected.
- codetrotter 3y agoI know. But not everyone uses the default configuration.
- k_roy 3y agothe article literally points out the somewhat rare configuration you would have to have to be exploited by this. The way this headline is worded is pretty misleading, and you clearly sucked it up.
- codetrotter 3y agoHere’s the thing. I use Nginx. Some of the configurations in which I use Nginx were mostly copy-pasted from recommendations from third-parties. Hence, my initial assumption which had been that no action was needed when I didn’t find anything mentioning Nginx with this attack when I searched a few days ago, needed to be revisited. Because when I saw the op article it turned out that there was reason for me to have a closer look at my Nginx instances. To see if any of the configs that had been recommended by third-parties involved changing values that could lead to this attack being able to affect me. > you clearly sucked it up Clearly not. Or at least, not without reason.
- ziddoap 3y agoCVEs aren't restricted to only consider default configs.
- gshulegaard 3y agoThere is a difference between an application being innately vulnerable and a user configuration exposing a vulnerability. Interestingly enough, HAProxy seems to have the same mitigation: > Until HAProxy dips below the configured stream limit again, new stream creation remains pending—regular timeouts eventually apply and the stream is cut if the situation does not resolve itself. This can occur during an attack. https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-http-2-rapid-reset-attack-cve-2023-44487 https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-... That is, if I read it correctly, default configuration is safe and you can use configuration of stream limits to ensure you are not vulnerable, but they are saying HAProxy is not vulnerable...at least in the title. Later on they soften the language: > HAProxy remains resistant to HTTP/2 Rapid Reset
- hsbauauvhabzb 3y agoI think the important distinction is ‘a user may plausibly have this non default configure’ vs ‘this config is obscure almost nobody will be running it this way’
- gshulegaard 3y agoI am not sure I understand how stream limit configuration between two L4/L7 load balancers is meaningfully different. In my mind, either the configuration of stream limits is a vulnerability for all L4/L7 load balancers that offer that configuration or it's not for all of them. If one doesn't _offer_ configuration of stream limits and therefore is not susceptible to user misconfiguration, then I would get the distinction. But as I understand it both HAProxy and NGINX have the same configuration options which _could_ be vulnerable if configured poorly by the user. One is just putting a lot more positive spin on it.
- 3y ago
- deleted 3y ago[deleted]
- ahoka 3y agoI immediately thought I’m happy not having to operate anything with nginx in front of it.
- k_roy 3y agoSo you are operating every other product that was impacted by this? This headline is pretty misleading as the article outlines you would need a fairly non-standard config to be exploited like this. Versus many other products that the stock configs are vulnerable.
- otherme123 3y agoI did the same search a couple days ago with Duck, and this blog entry was the first or among the first results.