From 542d033573951198d35a84fc2ac7c2d5f36b2d87 Mon Sep 17 00:00:00 2001 From: thegushi Date: Wed, 17 Mar 2021 19:44:36 -0700 Subject: [PATCH] Add CVE directory and documents --- SECURITY/CVE-2019-13678 | 61 +++++++++++++++++++++++++++++++++++++++++ SECURITY/CVE-2019-20970 | 38 +++++++++++++++++++++++++ SECURITY/CVE-2020-12272 | 15 ++++++++++ SECURITY/CVE-2020-12460 | 11 ++++++++ 4 files changed, 125 insertions(+) create mode 100644 SECURITY/CVE-2019-13678 create mode 100644 SECURITY/CVE-2019-20970 create mode 100644 SECURITY/CVE-2020-12272 create mode 100644 SECURITY/CVE-2020-12460 diff --git a/SECURITY/CVE-2019-13678 b/SECURITY/CVE-2019-13678 new file mode 100644 index 00000000..d847cf5a --- /dev/null +++ b/SECURITY/CVE-2019-13678 @@ -0,0 +1,61 @@ +CVE-2019-16378 - OpenDMARC through 1.3.2 and 1.4.x through 1.4.0-Beta1 is +prone to a signature-bypass vulnerability with multiple From: addresses, +which might affect applications that consider a domain name to be relevant +to the origin of an e-mail message. + +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. + +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 +applied. + +However, having 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 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. + +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. + +RFC7489 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. + +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. + +Resolution: + +Doing all 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"), +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). + +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 +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 diff --git a/SECURITY/CVE-2019-20970 b/SECURITY/CVE-2019-20970 new file mode 100644 index 00000000..80db1b59 --- /dev/null +++ b/SECURITY/CVE-2019-20970 @@ -0,0 +1,38 @@ + +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 +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. + +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. + +The OpenDMARC Authors formally suggest that whomever wrote that section +was smoking something that's only recently legal in Oregon. + +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. + +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 +further inside a network and not have access to the connection strings as +logged. + +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 +filters in the chain, but simply to compare their stated values and make +a weight-based judgement. \ No newline at end of file diff --git a/SECURITY/CVE-2020-12272 b/SECURITY/CVE-2020-12272 new file mode 100644 index 00000000..2a9084fe --- /dev/null +++ b/SECURITY/CVE-2020-12272 @@ -0,0 +1,15 @@ + +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 +by incorrect parsing and interpretation of SPF/DKIM authentication +results, as demonstrated by the example.net(.example.com substring. + +Link: https://nvd.nist.gov/vuln/detail/CVE-2020-12272 + +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 diff --git a/SECURITY/CVE-2020-12460 b/SECURITY/CVE-2020-12460 new file mode 100644 index 00000000..c4621189 --- /dev/null +++ b/SECURITY/CVE-2020-12460 @@ -0,0 +1,11 @@ +CVE-2020-12460 - OpenDMARC through 1.3.2 and 1.4.x through 1.4.0-Beta1 +has improper null termination in the function opendmarc_xml_parse that +can result in a one-byte heap overflow in opendmarc_xml when parsing a +specially crafted DMARC aggregate report. This can cause remote memory +corruption when a '\0' byte overwrites the heap metadata of the next +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