Add CVE directory and documents

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, [email protected], [email protected]) 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: [email protected], [email protected]"), 
+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.

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.

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.

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)