---

CVE-2019-20790 - log back

CVE-2019-20790 edited at 19 May 2021 11:16:30

Description

- OpenDMARC through 1.3.2 and 1.4.x before 1.4.1, when used with pypolicyd-spf 2.0.2, allows attacks that bypass SPF and DMARC authentication in situations where the HELO field is inconsistent with the MAIL FROM field. + OpenDMARC before 1.4.1, when used with pypolicyd-spf 2.0.2, allows attacks that bypass SPF and DMARC authentication in situations where the HELO field is inconsistent with the MAIL FROM field.

CVE-2019-20790 edited at 07 May 2021 16:58:24

Description

- OpenDMARC through 1.3.2 and 1.4.x, when used with pypolicyd-spf 2.0.2, allows attacks that bypass SPF and DMARC authentication in situations where the HELO field is inconsistent with the MAIL FROM field. + OpenDMARC through 1.3.2 and 1.4.x before 1.4.1, when used with pypolicyd-spf 2.0.2, allows attacks that bypass SPF and DMARC authentication in situations where the HELO field is inconsistent with the MAIL FROM field.

CVE-2019-20790 edited at 07 May 2021 16:58:09
Description	OpenDMARC through 1.3.2 and 1.4.x, when used with pypolicyd-spf 2.0.2, allows attacks that bypass SPF and DMARC authentication in situations where the HELO field is inconsistent with the MAIL FROM field. - - NOTE: the validity of this issue is disputed. According to the OpenDMARC developers: "It is the job of OpenDMARC to trust information provided to it by upstream filters. OpenDMARC itself can be configured to validate SPF, but there are use cases where OpenDMARC may be running further inside a network and not have access to the connection strings as logged. No standard exists for relaying the IP address of the client to inward systems when relaying occurs. It is the view of the OpenDMARC developers that this is working as designed, but if this behavior is undesirable, then any filter that adds a Received-SPF header field should not set a spf=pass result based solely on the HELO/EHLO string. It is not the job of OpenDMARC to second-guess other filters in the chain, but simply to compare their stated values and make a weight-based judgement."
References	https://github.com/trusteddomainproject/OpenDMARC/blob/develop/SECURITY/CVE-2019-20970 https://bugs.launchpad.net/pypolicyd-spf/+bug/1838816 https://sourceforge.net/p/opendmarc/tickets/235/ https://www.usenix.org/system/files/sec20fall_chen-jianjun_prepub_0.pdf https://github.com/trusteddomainproject/OpenDMARC/issues/49 https://github.com/trusteddomainproject/OpenDMARC/issues/158 + https://github.com/trusteddomainproject/OpenDMARC/commit/d72e1ec0ae6ed3a9827b31be4f268fc528232371 + https://github.com/trusteddomainproject/OpenDMARC/commit/9c0db8c12e4488fbf948afc27d8395d0c6bb53bd + https://github.com/trusteddomainproject/OpenDMARC/commit/5f980792546d11bc16dff7f875188ba81989ba33

CVE-2019-20790 edited at 07 Apr 2021 22:32:58
References	https://github.com/trusteddomainproject/OpenDMARC/blob/develop/SECURITY/CVE-2019-20970 https://bugs.launchpad.net/pypolicyd-spf/+bug/1838816 https://sourceforge.net/p/opendmarc/tickets/235/ https://www.usenix.org/system/files/sec20fall_chen-jianjun_prepub_0.pdf + https://github.com/trusteddomainproject/OpenDMARC/issues/49 + https://github.com/trusteddomainproject/OpenDMARC/issues/158

CVE-2019-20790 edited at 21 Mar 2021 16:36:12
Severity	- Medium + Low
Description	OpenDMARC through 1.3.2 and 1.4.x, when used with pypolicyd-spf 2.0.2, allows attacks that bypass SPF and DMARC authentication in situations where the HELO field is inconsistent with the MAIL FROM field. + + NOTE: the validity of this issue is disputed. According to the OpenDMARC developers: "It is the job of OpenDMARC to trust information provided to it by upstream filters. OpenDMARC itself can be configured to validate SPF, but there are use cases where OpenDMARC may be running further inside a network and not have access to the connection strings as logged. No standard exists for relaying the IP address of the client to inward systems when relaying occurs. It is the view of the OpenDMARC developers that this is working as designed, but if this behavior is undesirable, then any filter that adds a Received-SPF header field should not set a spf=pass result based solely on the HELO/EHLO string. It is not the job of OpenDMARC to second-guess other filters in the chain, but simply to compare their stated values and make a weight-based judgement."
References	+ https://github.com/trusteddomainproject/OpenDMARC/blob/develop/SECURITY/CVE-2019-20970 https://bugs.launchpad.net/pypolicyd-spf/+bug/1838816 https://sourceforge.net/p/opendmarc/tickets/235/ https://www.usenix.org/system/files/sec20fall_chen-jianjun_prepub_0.pdf

CVE-2019-20790 edited at 24 Feb 2021 14:53:00
Severity	- Unknown + Medium
Remote	- Unknown + Remote
Type	- Unknown + Authentication bypass
Description	+ OpenDMARC through 1.3.2 and 1.4.x, when used with pypolicyd-spf 2.0.2, allows attacks that bypass SPF and DMARC authentication in situations where the HELO field is inconsistent with the MAIL FROM field.
References	+ https://bugs.launchpad.net/pypolicyd-spf/+bug/1838816 + https://sourceforge.net/p/opendmarc/tickets/235/ + https://www.usenix.org/system/files/sec20fall_chen-jianjun_prepub_0.pdf

CVE-2019-20790 created at 24 Feb 2021 14:51:19
Severity	+ Unknown
Remote	+ Unknown
Type	+ Unknown
Description
References
Notes