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.
References
Link Resource
https://github.com/envoyproxy/envoy/pull/630 Patch Third Party Advisory
https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g Issue Tracking Third Party Advisory
History

No history.

cve-icon MITRE Information

Status: PUBLISHED

Assigner: GitHub_M

Published: 2022-02-22T22:30:12

Updated: 2022-02-22T22:30:12

Reserved: 2021-11-16T00:00:00


Link: CVE-2022-21657

JSON object: View

cve-icon NVD Information

Status : Analyzed

Published: 2022-02-22T23:15:11.277

Modified: 2022-03-07T15:25:59.863


Link: CVE-2022-21657

JSON object: View

cve-icon Redhat Information

No data.

CWE