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
Comments
I'm not great at reading cpe's but that has a
Some of the changes in C didn't go into Java because "meh." Compared to |
This part also confused me a lot. But I am not sure, why the So if I understood your point correctly you are suggesting to use |
It means N/A. So it seems quite clear it isn't for java, which is
(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 So it definitely seems your CVE scanner is incorrect.
Yes. If untrusted clients connect directly to your grpc-java backends, then configuring maxRstFramesPerWindow is good. |
|
I don't think this interpretation is correct. The cpe 2.3 spec (NIST Interagency Report 7695) defines the language tag as follows:
and RFC5646 even explicitly mentions that programming languages are not to be used here:
So I think the 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. |
I don't think the tag in discussion is |
|
Seems like this is resolved. If not, comment, and it can be reopened. |
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()"?
The text was updated successfully, but these errors were encountered: