CVE-2022-21657— Envoy 信任管理问题漏洞

X.509 Extended Key Usage and Trust Purposes bypass in Envoy

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:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N

证书验证不恰当

Envoy 信任管理问题漏洞

Envoy是一款开源的分布式代理服务器。 Envoy 存在信任管理问题漏洞，该漏洞源于Envoy 不会将它从对等方（作为 TLS 客户端或 TLS 服务器）接受的证书集限制为仅包含必要的扩展密钥使用（id-kp-serverAuth 和 id-kp-clientAuth，分别为 ）。 这意味着对等点可以提供电子邮件证书（例如 id-kp-emailProtection），作为叶证书或链中的 CA，并且将被 TLS 接受。 当与拉取请求 #630 中描述的问题结合使用时，这尤其糟糕，因为它允许仅用于 S/M

N/A

N/A