Improper Certificate Validation Affecting servicemesh-proxy package, versions *


Severity

Recommended
0.0
medium
0
10

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.05% (22nd percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-RHEL8-SERVICEMESHPROXY-4400398
  • published26 Mar 2023
  • disclosed23 Feb 2022

Introduced: 23 Feb 2022

CVE-2022-21657  (opens in a new tab)
CWE-295  (opens in a new tab)

How to fix?

There is no fixed version for RHEL:8 servicemesh-proxy.

NVD Description

Note: Versions mentioned in the description apply only to the upstream servicemesh-proxy package and not the servicemesh-proxy package as distributed by RHEL. See How to fix? for RHEL:8 relevant fixed versions and status.

Envoy is an open source edge and service proxy, designed for cloud-native applications. In affected versions Envoy does not restrict the set of certificates it accepts from the peer, either as a TLS client or a TLS server, to only those certificates that contain the necessary extendedKeyUsage (id-kp-serverAuth and id-kp-clientAuth, respectively). This means that a peer may present an e-mail certificate (e.g. id-kp-emailProtection), either as a leaf certificate or as a CA in the chain, and it will be accepted for TLS. This is particularly bad when combined with the issue described in pull request #630, in that it allows a Web PKI CA that is intended only for use with S/MIME, and thus exempted from audit or supervision, to issue TLS certificates that will be accepted by Envoy. As a result Envoy will trust upstream certificates that should not be trusted. There are no known workarounds to this issue. Users are advised to upgrade.

CVSS Scores

version 3.1