diff --git a/SECURITY/CVE-2019-13678 b/SECURITY/CVE-2019-13678 index d847cf5..c2679c8 100644 --- a/SECURITY/CVE-2019-13678 +++ b/SECURITY/CVE-2019-13678 @@ -7,34 +7,36 @@ Link: https://nvd.nist.gov/vuln/detail/CVE-2019-16378 Background Details: -When implemented, the DMARC RFC (RFC7489) assumed that emails with multiple -From: fields would be rejected by the receiving MTA (Section RFC7489 section -6.6.1), and that emails containing such a header would be rare in practice. +When it was written, the DMARC RFC (RFC 7489) assumed that emails with multiple +addresses in the From: field would be rejected by the receiving MTA +(Section RFC 7489 section 6.6.1), and moreover that emails containing such +a header field would be rare in practice. In the case where such a message is received, the RFC recommends (in the -same section) that both domains be tested, and the strictest policy be +same section) that all domains be tested, and the strictest policy be applied. -However, having two distinct administrative domains in the same From: +However, having even two distinct administrative domains in the same From: header (for example, a@gmail.com, b@hotmail.com) leads to an issue: -For SPF, mail can only be delivered to a receiving system from one IP. -Unless that IP address is (coicidentally or intentionally) in both -domains' spf records (or the domains include: each other), then the SPF -check will fail (forged HELO's notwithstanding). +* For SPF, mail can only be delivered to a receiving system from one IP + address. Unless that IP address is (coicidentally or intentionally) in both + domains' SPF records (or the domains "include:" each other), then the SPF + check will fail (forged HELO's notwithstanding). -For DKIM, there can only be one selector/domain in a given DKIM-Signature, -referencing a single "From:" header. So in the case where either domain -specifies a dmarc policy of either p=reject or p=quarantine, the result -will be a failure. +* For DKIM, there can only be one selector/domain in a given DKIM-Signature, + referencing a single "From:" header. So in the case where either domain + specifies a DMARC policy of either p=reject or p=quarantine, the result + will be a failure. The message would have to bear valid signatures + from both domains. In practice, citing the example above, a message cannot have been signed as being delivered to a receiving system immediately after originating from both gmail.com and hotmail.com. While it's possible to have a message relayed *through* one system via another, this is not what DMARC attempts -to solve, and is what ARC is for. +to solve, and is what ARC (RFC 8617) is for. -RFC7489 Also states (section 3.1.1): Note that a single email can contain +RFC 7489 also states (Section 3.1.1): Note that a single email can contain multiple DKIM signatures, and it is considered to be a DMARC "pass" if any DKIM signature is aligned and verifies. @@ -42,15 +44,22 @@ The behavior of a case of there being multiple distinct domains does not appear to have been considered by this section, as it seems to apply to multiple signing agents inside a single administrative domain. +There are additional concerns. A filter that attempts to perform a full +DMARC evaluation of every domain found in a multi-valued From could be used +to amplify a denial of service attack either against the system running +the filter or against other nameservers by intentionally listing a large +number of domains in the From field. The specification does not +provide guidance to mitigate such abuse. + Resolution: -Doing all the DMARC checks for every domain in the From: of a message adds +Doing all of the DMARC checks for every domain in the From: of a message adds additional complexity, and opens a vector for abuse. In the case where a message contains two or more From: addresses from the -same domain: (For example, "From: professor@science.edu, student@science.edu"), +same domain (for example, "From: professor@science.edu, student@science.edu"), both processed and signed by science.edu's mail server, these messages will -be processed as normal, so long as there is only one unique domain). +be processed as normal, so long as there is only one unique domain. For all other cases, OpenDMARC has added an option to outright reject messages containing a multi-valued From: field. If set, messages can be rejected at @@ -58,4 +67,4 @@ receipt-time. If unset, messages will be ignored by the filter. (They will not pass, but they will not fail). The Authentication results field added in this case will have a result of -dmarc=permerror. \ No newline at end of file +dmarc=permerror. diff --git a/SECURITY/CVE-2019-20970 b/SECURITY/CVE-2019-20970 index 5222c3f..351fcca 100644 --- a/SECURITY/CVE-2019-20970 +++ b/SECURITY/CVE-2019-20970 @@ -1,4 +1,3 @@ - CVE-2019-20790 - 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 @@ -6,30 +5,37 @@ with the MAIL FROM field. Link: https://nvd.nist.gov/vuln/detail/CVE-2019-20790 -Details: While the SPF RFC (RFC7208) says that entities MUST check -the "Mail From" header during an SPF check (RFC7208 section 2.4). - -Section 2.3 says and that checking the HELO/EHLO string is RECOMMENDED. +Details: While the SPF RFC (RFC 7208) says that entities MUST check +the envelope sender during an SPF check (Section 2.4), Section 2.3 also +says that checking the HELO/EHLO string is RECOMMENDED. -It further states (section 2.3): +It further states (Section 2.3): -If a conclusive determination about the message can be made based on -a check of "HELO", then the use of DNS resources to process the typically -more complex "MAIL FROM" can be avoided. + If a conclusive determination about the message can be made based on + a check of "HELO", then the use of DNS resources to process the typically + more complex "MAIL FROM" can be avoided. The HELO string is trivially forgeable and can be set to any value by anyone delivering mail to a system. It does not depend on the hostname -of the transmitting system. +of the transmitting system. There is no guarantee that the HELO value +will be validated by the receiving system. Moreover, RFC 5321 (the +current SMTP specification) says: + + An SMTP server MAY verify that the domain name argument in the EHLO + command actually corresponds to the IP address of the client. + However, if the verification fails, the server MUST NOT refuse to + accept a message on that basis. Resolution/Workaround: 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 +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. +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 which adds -a received-spf header 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 +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. \ No newline at end of file +a weight-based judgement. diff --git a/SECURITY/CVE-2020-12272 b/SECURITY/CVE-2020-12272 index 2a9084f..5c4dbd7 100644 --- a/SECURITY/CVE-2020-12272 +++ b/SECURITY/CVE-2020-12272 @@ -1,9 +1,8 @@ - CVE-2020-12272 - OpenDMARC through 1.3.2 and 1.4.x allows attacks that inject authentication results to provide false information -about the domain that originated an e-mail message. This is caused +about the domain that originated an e-mail message. This is caused by incorrect parsing and interpretation of SPF/DKIM authentication -results, as demonstrated by the example.net(.example.com substring. +results, as demonstrated by the "example.net(.example.com" substring. Link: https://nvd.nist.gov/vuln/detail/CVE-2020-12272 @@ -11,5 +10,5 @@ Resolution: OpenDMARC has added checking to validate that the domain element in both SPF and DKIM headers being inspected argument contains only valid domain name characters. This has been fixed as of OpenDMARC 1.4.1 (March 2021). While not mentioned in the CVE, fixes -are in a soon-to-be released branch of OpenDKIM as well to not put such a -malformed header in place. \ No newline at end of file +are in a soon-to-be released branch of OpenDKIM as well so that a +signature bearing such a domain will be considered invalid. diff --git a/SECURITY/CVE-2020-12460 b/SECURITY/CVE-2020-12460 index c462118..7a6cf4a 100644 --- a/SECURITY/CVE-2020-12460 +++ b/SECURITY/CVE-2020-12460 @@ -8,4 +8,4 @@ chunk and its PREV_INUSE flag. Link: https://nvd.nist.gov/vuln/detail/CVE-2020-12460 Resolution: OpenDMARC has repaired the function in question, as of -OpenDMARC 1.4.0 (January 2021) \ No newline at end of file +OpenDMARC 1.4.0 (January 2021).