CVE-2023-44487

[He-Pin]

Description
A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack.

References
https://www.cve.org/CVERecord?id=CVE-2023-44487
https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/

I just read this, not sure if pekko-http is affected.
Netty's fix is netty/netty@58f75f6

@jrudolph cc

[jrudolph]

In my tests on my machine, you can load a core with about 8-10MB/s of network input using either just RST frames or HEADERS/RST. How bad is that? It means you already have to almost saturate a 100GBit link for this to become relevant.

On the other hand, the real cost might come from actually running requests that are already cancelled (see also #330). These are run in a stream with configurable parallelism, so there's no unlimited forking of work going on.

In perspective, this is probably not the best targeted attack you could do if you want to target a specific site (because you only target HTTP/2 infrastructure and not all the rest of the backend). On the other hand, it is unfortunate if you get hit by an easy drive-by attack.

One thing to consider is that it is not recommended to run Pekko HTTP on the public internet directly (as it is not recommended to run any web server on the public internet directly without the necessary precautions, you would much more likely put a more well-established web proxy like nginx etc in front of any real loads, especially if you have exposure). So, the real impact of this problem is probably negligible right now.

A solution will probably want to implement some kind of rate limiting. Unfortunately, this will introduce both a small performance penalty but also another knob that you have to tune, especially for high loads. This makes for an awkward position when choosing the default because there's little reason to enable the rate limit for a non-exposed load (= almost all) while when you are running it on the public internet you will have to tweak settings to enable the feature.

[atennapel]

I noticed that Pekko-http is not listed on the vulnerability page here: https://nvd.nist.gov/vuln/detail/CVE-2023-44487 (but Akka-http is). Do you know why that is?

[He-Pin]

@atennapel Maybe pekko-http is new, and @jrudolph is working on a PR for this.

[pjfanning]

@atennapel we have discussed this a little internally. We do intend to make some improvements but if anyone is interested in working on their own solution and submitting it, we will evaluate it.

We don't believe that Pekko HTTP based apps should be exposed to the public internet directly. We think Pekko HTTP behaves pretty well under most known Denial of Service attacks but that if you want the best security, you should use an enterprise grade routing solution (eg Cloudflare - but please research your own solutions). Even using a load balancing solution like an up to date version of Nginx would be safer than exposing Pekko HTTP based apps directly to the public internet.

I think you would find that most HTTP server libs are susceptible to brute force DOS / DDOS attacks.

[samueleresca]

I noticed that Pekko-http is not listed on the vulnerability page here: https://nvd.nist.gov/vuln/detail/CVE-2023-44487 (but Akka-http is). Do you know why that is?

NVD does not have control over the reference links associated with a CVE ID. The preferred method of having reference links added or edited for a CVE would be to update the CVE List entry. The CVE List is maintained by the CVE Assignment Team which can be reached at https://cveform.mitre.org/. I will proceed by submitting a request for adding the reference to this issue in the CVE List entry

[pjfanning]

@samueleresca we don't regard this as CVE worthy - please don't get this added to the Mitre CVE

Please read #332 (comment)