Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ideal Mitigation Strategy for Rapid Reset CVE-2023-44487 #10726

Closed
schaefer-dev opened this issue Dec 6, 2023 · 6 comments
Closed

Ideal Mitigation Strategy for Rapid Reset CVE-2023-44487 #10726

schaefer-dev opened this issue Dec 6, 2023 · 6 comments
Labels

Comments

@schaefer-dev
Copy link

Hello,
we are currently uncertain to which extend grpc-java may still be vulnerable to rapid-reset attacks (CVE-2023-44487) and under which conditions, regarding the grpc configuration.
Since last week, the NVD reports all versions up to and including 1.59.2 as vulnerable (in cpe:2.3:a:grpc:grpc:*:*:*:*:*:-:*:*).

  • We saw that grpc core 1.60.0 lists some release notes which seem to introduce additional mitigations for rapid-reset. E.g. #34637, #34639, #34640.
    However, many of these points are not listed in the release notes for grpc-java 1.60.0. Does that mean they are not implemented in grpc-java? We are generally unsure to which extend grpc core and grpc-java are related and to which degree feature-parity exists.

  • Which versions of grpc-java do you currently consider sufficiently protected against rapid reset? Do we need to rely on configuration through "NettyServerBuilder.maxRstFramesPerWindow()"?

@ejona86
Copy link
Member

ejona86 commented Dec 6, 2023

Since last week, the NVD reports all versions up to and including 1.59.2 as vulnerable (in cpe:2.3:a:grpc:grpc::::::-::*).

I'm not great at reading cpe's but that has a - for the language/software, not *, which I figure probably means it is talking about C core. To my knowledge there was no mention of grpc-java specifically. You might ping https://groups.google.com/g/grpc-io/c/cLSPkme9kcY to see if someone can update the CVE to have a "fixed" version.

NettyServerBuilder.maxRstFramesPerWindow() can help mitigate. But you do have to configure it with your service in mind. For reference, this was the only change made to upstream Netty (although I think they enabled it by default).

Some of the changes in C didn't go into Java because "meh." Compared to maxRstFramesPerWindow() they contributed much less or are too hard to configure. We do want something like 34639, but that is a longer-term change. But we really want it to improve legitimate traffic, outside of any attack.

@schaefer-dev
Copy link
Author

I'm not great at reading cpe's but that has a - for the language/software, not *, which I figure probably means it is talking about C core. To my knowledge there was no mention of grpc-java specifically.

This part also confused me a lot. But I am not sure, why the - character should indicate C core specifically? Using our CVE scanner (dependency check) the given cpe definitely matches on everything grpc related (including grpc-java) with the highest possible confidence.

So if I understood your point correctly you are suggesting to use maxRstFramesPerWindow for now, as upgrading to 1.60.0 grpc-java alone (without using said configuration) might not be a sufficient mitigation against rapid reset attacks?

@ejona86
Copy link
Member

ejona86 commented Dec 7, 2023

But I am not sure, why the - character should indicate C core specifically?

It means N/A. So it seems quite clear it isn't for java, which is java in that field. What it does mean...

- does not include java (and those pre-releases definitely look like c core):
https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Agrpc%3Agrpc%3A1.44.0%3A*%3A*%3A*%3A*%3A-%3A*%3A*

But * does:
https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Agrpc%3Agrpc%3A1.44.0%3A*%3A*%3A*%3A*%3A*%3A*%3A*

(And yes, I chose an old version. Newer versions didn't have entries in the database for Java.)

And if you look at CVEs impacting grpc-java 1.44.0, you only find one which should have been c core but they improperly used *. Notice no rapid reset:
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&isCpeNameSearch=true&seach_type=all&query=cpe:2.3:a:grpc:grpc:1.44.0:*:*:*:*:java::

So it definitely seems your CVE scanner is incorrect.

So if I understood your point correctly you are suggesting to use maxRstFramesPerWindow for now

Yes. If untrusted clients connect directly to your grpc-java backends, then configuring maxRstFramesPerWindow is good.

@schaefer-dev
Copy link
Author

schaefer-dev commented Dec 8, 2023

I don't think this interpretation is correct. The cpe 2.3 spec (NIST Interagency Report 7695) defines the language tag as follows:

Values for this attribute SHALL be valid language tags as defined by [RFC5646], and SHOULD be used
to define the language supported in the user interface of the product being described. Although any valid
language tag MAY be used, only tags containing language and region codes SHOULD be used.

and RFC5646 even explicitly mentions that programming languages are not to be used here:

Language tags are used to help identify languages, whether spoken,
written, signed, or otherwise signaled, for the purpose of
communication. This includes constructed and artificial languages
but excludes languages not intended primarily for human
communication, such as programming languages.

So I think the - in this CPE is simply a mistake. At least I can't really explain why they would use it instead of *.

Thanks for the advice regarding the configuration, we will make sure to configure our server using maxRstFramesPerWindow to make sure we are not negatively affected by rapid reset.

@ejona86
Copy link
Member

ejona86 commented Dec 8, 2023

The cpe 2.3 spec (NIST Interagency Report 7695) defines the language tag as follows:

I don't think the tag in discussion is language, but is target_sw. This has it decoded: https://nvd.nist.gov/products/cpe/detail/9B6EAFAD-8446-4BFF-8BCE-9D353C021C5C .

@ejona86
Copy link
Member

ejona86 commented Dec 8, 2023

Seems like this is resolved. If not, comment, and it can be reopened.

@ejona86 ejona86 closed this as completed Dec 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants