Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

redhat логотип

CVE-2022-21657

Опубликовано: 23 фев. 2022
Источник: redhat
CVSS3: 6.8

Описание

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.

A flaw was found in envoy. This issue occurs when it does not restrict the set of certificates it accepts from the peer, either as a TLS client or a TLS server, and only to those certificates that contain the necessary extendedKeyUsage (id-kp-serverAuth and id-kp-clientAuth, respectively).

Затронутые пакеты

ПлатформаПакетСостояниеРекомендацияРелиз
OpenShift Service Mesh 2openshift-service-mesh/proxyv2-rhel8Not affected
OpenShift Service Mesh 2.0servicemesh-proxyAffected
OpenShift Service Mesh 2.1servicemesh-proxyWill not fix

Показывать по

Дополнительная информация

Статус:

Moderate
Дефект:
CWE-295
https://bugzilla.redhat.com/show_bug.cgi?id=2057272envoy: X.509 Extended Key Usage and Trust Purposes bypass

6.8 Medium

CVSS3

Связанные уязвимости

CVSS3: 6.8
nvd
почти 4 года назад

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.

CVSS3: 6.8
debian
почти 4 года назад

Envoy is an open source edge and service proxy, designed for cloud-nat ...

6.8 Medium

CVSS3