Is gRPC susceptible to CVE-2024-12176?

[Kate]

Hi all,

OpenSSL versions 3.4, 3.3, 3.2, 3.1, 3.0, 1.1.1 and 1.0.2 are susceptible to CVE-2024-13176.

As BoringSSL is forked from OpenSSL can you tell me if gRPC, which uses BoringSSL is affected by this vulnerability and if so is there a plan to fix it? 

Many thanks, 

Kate

[Kannan Jayaprakasam]

For gRPC-Java, if you are using grpc-netty-shaded, it uses netty-tcnative that has boringssl statically linked which is old (current gRPC-Java depends on io.netty:netty-tcnative-boringssl-static:2.0.65 that builds and links from boringssl chromium-stable dated Dec 2024). 

To use OpenSSL on your machine via dynamic linking, you should use grpc-netty and not grpc-netty-shaded. Using OpenSSL can have more initial configuration issues, but can be useful if your OS's OpenSSL version is recent and kept up-to-date with security fixes. Instructions here.

[Kate]

Hi Kannan,

Thank you for the reply. I forgot to say I am using gRPC C++ on Windows compiled with cmake.

Kate

[Matthew Stevenson]

Hi Kate,

The CVE in the email description (CVE-2024-12176) is different than the CVE from the email body (CVE-2024-13176). I'm assuming the question is about the latter, as it is the one that would apply to the SSL libraries.

BoringSSL is not affected by CVE-2024-13176.

As you point out, there are OpenSSL versions that are affected by CVE-2024-13176. If you choose to build gRPC-C++ with OpenSSL, then you may be affected, depending on your OpenSSL version.

Best,

Matt

[Kate]

Hi Matt,

Yes, that is a typo in the email description, I don't know how/if I can correct it. 

Luckily the email body is correct.

Thank you for your response, that is great news. we don't want to build gRPC with OpenSSL so if BoringSSL is not affected then we can continue as we are.

Thanks again,

Kate