According to the versions of the grpc package installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects     between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS     attacks: - Unbounded memory buffering in the HPACK parser - Unbounded CPU consumption in the HPACK parser     The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because     that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected     by the client. The unbounded memory buffering bugs: - The header size limit check was behind the string     reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8     or 16kb. - HPACK varints have an encoding quirk whereby an infinite number of 0's can be added at the     start of an integer. gRPC's hpack parser needed to read all of them before concluding a parse. - gRPC's     metadata overflow check was performed per frame, so that the following sequence of frames could cause     infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3     etc (CVE-2023-33953)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

According to the versions of the grpc package installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects     between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS     attacks: - Unbounded memory buffering in the HPACK parser - Unbounded CPU consumption in the HPACK parser     The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because     that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected     by the client. The unbounded memory buffering bugs: - The header size limit check was behind the string     reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8     or 16kb. - HPACK varints have an encoding quirk whereby an infinite number of 0's can be added at the     start of an integer. gRPC's hpack parser needed to read all of them before concluding a parse. - gRPC's     metadata overflow check was performed per frame, so that the following sequence of frames could cause     infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3     etc (CVE-2023-33953)

  - Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible     platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number     of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go     are NOT affected. (CVE-2023-4785)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The remote SUSE Linux SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 / openSUSE 15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2024:0573-1 advisory.

  - When gRPC HTTP2 stack raised a header size exceeded error, it skipped parsing the rest of the HPACK frame.
    This caused any HPACK table mutations to also be skipped, resulting in a desynchronization of HPACK tables     between sender and receiver. If leveraged, say, between a proxy and a backend, this could lead to requests     from the proxy being interpreted as containing headers from different proxy clients - leading to an     information leak that can be used for privilege escalation or data exfiltration. We recommend upgrading     beyond the commit contained in https://github.com/grpc/grpc/pull/33005     https://github.com/grpc/grpc/pull/33005 (CVE-2023-32731)

  - gRPC contains a vulnerability whereby a client can cause a termination of connection between a HTTP2 proxy     and a gRPC server: a base64 encoding error for `-bin` suffixed headers will result in a disconnection by     the gRPC server, but is typically allowed by HTTP2 proxies. We recommend upgrading beyond the commit in     https://github.com/grpc/grpc/pull/32309 https://www.google.com/url (CVE-2023-32732)

  - gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects     between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS     attacks: - Unbounded memory buffering in the HPACK parser - Unbounded CPU consumption in the HPACK parser     The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because     that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected     by the client. The unbounded memory buffering bugs: - The header size limit check was behind the string     reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8     or 16kb. - HPACK varints have an encoding quirk whereby an infinite number of 0's can be added at the     start of an integer. gRPC's hpack parser needed to read all of them before concluding a parse. - gRPC's     metadata overflow check was performed per frame, so that the following sequence of frames could cause     infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3     etc (CVE-2023-33953)

  - The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation     can reset many streams quickly, as exploited in the wild in August through October 2023. (CVE-2023-44487)

  - Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible     platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number     of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go     are NOT affected. (CVE-2023-4785)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

An update of the grpc package has been released.

ID	Name	Product	Family	Published	Updated	Severity
188229	EulerOS 2.0 SP11 : grpc (EulerOS-SA-2023-3007)	Nessus	Huawei Local Security Checks	1/16/2024	1/16/2024	high
188927	EulerOS 2.0 SP9 : grpc (EulerOS-SA-2023-3300)	Nessus	Huawei Local Security Checks	1/16/2024	1/16/2024	high
190881	SUSE SLED15 / SLES15 / openSUSE 15 Security Update : abseil-cpp, grpc, opencensus-proto, protobuf, python-abseil, python-grpcio, re2 (SUSE-SU-2024:0573-1)	Nessus	SuSE Local Security Checks	2/22/2024	2/23/2024	high
188333	EulerOS 2.0 SP10 : grpc (EulerOS-SA-2024-1059)	Nessus	Huawei Local Security Checks	1/16/2024	1/16/2024	high
204231	Photon OS 5.0: Grpc PHSA-2023-5.0-0078	Nessus	PhotonOS Local Security Checks	7/24/2024	7/24/2024	high
188812	EulerOS 2.0 SP9 : grpc (EulerOS-SA-2023-3332)	Nessus	Huawei Local Security Checks	1/16/2024	1/16/2024	high
188141	EulerOS 2.0 SP10 : grpc (EulerOS-SA-2024-1083)	Nessus	Huawei Local Security Checks	1/16/2024	1/16/2024	high
188254	EulerOS 2.0 SP11 : grpc (EulerOS-SA-2023-3030)	Nessus	Huawei Local Security Checks	1/16/2024	1/16/2024	high

Detections

Analytics

Plugins Search

high

high

high

high

high

high

high

high