Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix multiple addresses in From vulnerability #48

Conversation

panpilkarz
Copy link

This PR fixes vulnerability that allows opendmarc to pass as example.com since spf and dkim were not example.com in the following example:

Input:

From: Support <support@example.com>, Support <support@thedomain.com>
Authentication-Results: mail.example.com; spf=pass smtp.mailfrom=notify@seconddomain.com
Authentication-Results: mail.example.com; dkim=pass (1024-bit key) header.d=thedomain.com header.i=@thedomain.com header.b=\"xxxx\""

Output:

Authentication-Results: mail.example.com; dmarc=pass (p=quarantine dis=none) header.from=example.com

@wioxjk
Copy link

wioxjk commented Sep 11, 2019

Thanks @panpilkarz

Let's hope that someone from trusteddomainproject is reacting to this,

@AntiFreeze

@Bluewind
Copy link

In light of https://tools.ietf.org/html/rfc7489#section-6.6.1 this looks way too simple. From a quick look I'd say that the proposed fix only parses the first domain and it does not parse/verify each domain as specified in the RFC.

uqs pushed a commit to freebsd/freebsd-ports that referenced this pull request Sep 15, 2019
- please note that it might only be a partial fix, see
  trusteddomainproject/OpenDMARC#48 (comment)

PR:		240505
Reported by:	protonmail
Approved by:	ports-secteam (delphij)
Obtained from:	trusteddomainproject/OpenDMARC#48
MFH:		2019Q3
Security:	https://protonmail.com/blog/bellingcat-cyberattack-phishing/


git-svn-id: svn+ssh://svn.freebsd.org/ports/head@512093 35697150-7ecd-e111-bb59-0022644237b5
uqs pushed a commit to freebsd/freebsd-ports that referenced this pull request Sep 15, 2019
mail/opendmarc: fix multiple addresses in From vulnerability

- please note that it might only be a partial fix, see
  trusteddomainproject/OpenDMARC#48 (comment)

PR:		240505
Reported by:	protonmail
Approved by:	ports-secteam (delphij)
Obtained from:	trusteddomainproject/OpenDMARC#48
Security:	https://protonmail.com/blog/bellingcat-cyberattack-phishing/
uqs pushed a commit to freebsd/freebsd-ports that referenced this pull request Sep 15, 2019
- please note that it might only be a partial fix, see
  trusteddomainproject/OpenDMARC#48 (comment)

PR:		240505
Reported by:	protonmail
Approved by:	ports-secteam (delphij)
Obtained from:	trusteddomainproject/OpenDMARC#48
MFH:		2019Q3
Security:	https://protonmail.com/blog/bellingcat-cyberattack-phishing/
Jehops pushed a commit to Jehops/freebsd-ports-legacy that referenced this pull request Sep 16, 2019
- please note that it might only be a partial fix, see
  trusteddomainproject/OpenDMARC#48 (comment)

PR:		240505
Reported by:	protonmail
Approved by:	ports-secteam (delphij)
Obtained from:	trusteddomainproject/OpenDMARC#48
MFH:		2019Q3
Security:	https://protonmail.com/blog/bellingcat-cyberattack-phishing/


git-svn-id: svn+ssh://svn.freebsd.org/ports/head@512093 35697150-7ecd-e111-bb59-0022644237b5
@kitterma
Copy link

I would recommend distros and others apply this (I'm about to do it in Debian).

I tested this by creating a DKIM signed multi-from message. The message was
signed by the second body From. An unpatched opendmarc will produce a DMARC
pass result (due to DKIM passed and aligned with a body From value), but will
show the unsigned domain from the other body From as the passed domain.

After patching, the result is DMARC fail for the first domain listed (same one
that showed pass before). This is not the full RFC7489 processing, but it is
enough to avoid the related security issue.

I did a code inspection and there is existing code to error out when more than one
body From is detected. I think this patch is sufficient for that to get triggered.

@carnil
Copy link

carnil commented Sep 17, 2019

CVE-2019-16378 was assigned for this issue.

@AdamWill
Copy link

AdamWill commented Oct 4, 2019

For the record I am applying this to the Fedora / EPEL package too; it will be in opendmarc-1.3.2-1 on Fedora / EPEL.

I think this is the same as https://sourceforge.net/p/opendmarc/tickets/235/ in the sourceforge tracker. I am unsure what status this github repo has and whether any maintainer is watching it.

@kitterma
Copy link

kitterma commented Oct 4, 2019 via email

cohomology added a commit to cohomology/OpenDMARC that referenced this pull request Dec 29, 2019
@martinbogo martinbogo added the CVE-security-issue CVE assigned security Issue label May 12, 2020
@mskucherawy
Copy link
Member

Background:

When OpenDMARC was written, the posture of the DMARC community was that this case is so rare that such messages should simply be rejected because, as the RFC says, the kinds of email DMARC aims to deal with never encounter this use case. Accordingly, the filter and library were written on the assumption that they would never see this use case.

Discussion:

As far as I can tell, this patch is really a no-op. The current value passed to this function contains the whole header field value, which is then parsed to find the domain. The patch proposes to pass just the domain, but it's the same domain, so nothing really changes.

Proposal:

If upstream MTAs are not rejecting multi-valued From fields as expected, we'll have to teach this filter to parse and process them.

@kitterma
Copy link

kitterma commented Jun 5, 2020

When this was posted, I tested opendmarc both with and without this patch and the behavior is different (see above: #48 (comment)), so for whatever reason it's not a no-op.

I tested passing mail through postfix and libmilter, so it was representative of what can happen on a live system, not an artificial test architecture.

I don't think 'fix all the MTAs' is a good solution, so I do think it needs addressing here. You already have code to error out in the multi-From case, I think it's enough to apply this change to get it triggered.

@martinbogo
Copy link
Contributor

@mskucherawy is working on a different fix to this issue. However, I am leaving this open as the patch is in the wild and will need to be conflict-merged in the future.

@sp-andwei
Copy link

It may be obvious, but since there seems to be some confusion about why the patch works (and it confused me as well), I just wanted to point out: The reason that it works (looking at opendmarc/opendmarc.c) is that at all places in the code where the From header value is used the dfc->mctx_fromdomain is used, which in turn is parsed by local code (dmarcf_mail_parse_multi) in opendamrc/parse.c. The only exception to that was passing the whole From header to libopendmarc in opendmarc_policy_store_from_domain, which is passed the whole header value which may or may not be parsed to the same domain (using a different parse function within libopendmarc).

Thus, when a DKIM PASS result is stored later and it matches with whatever was identified by libopendmarc as From domain but that does not agree with what was parsed by the local code, we get the wrong result.

In addition to patching any multi-From problems, I think it would be a good idea to use the actual From domain used by libopendmarc when reporting results, e.g., writing the AR-header (I added a function to do just this: #63.)

@mskucherawy
Copy link
Member

I made a different fix for this in commit bdcda9b.

We're already parsing the From field and extracting possibly multiple values, but currently we would quietly take the first one and continue. With the patch, messages with multi-valued From fields are ignored completely by the filter, though there is a new option to reject them instead if that's preferred. The latter provides strict compliance with the advice of RFC 7489 Section 6.6.1; the former is the less-disruptive alternative that also avoids making an inconsistent determination.

@celesteking
Copy link

Why don't you guys just use a 3rd party lib that parses rfc5322 fields instead of trying to reinvent the wheel?

@martinbogo
Copy link
Contributor

I know this has been "hanging around" for a while and I believe it is superceded by Murray's recent patch for the multi-from problem. I'm going to mark this wont patch as I think we have an effective solution now.

IF THIS IS IN ERROR -- we can always create a new PR against 1.4.x main branch and I'll have @thegushi review it.

-Martin ( patch guru )

@martinbogo martinbogo closed this Mar 8, 2021
@thegushi
Copy link
Collaborator

We also did apply the one-line patch that FreeBSD and OpenBSD have been using, here:

https://github.com/openbsd/ports/blob/master/mail/opendmarc/patches/patch-opendmarc_opendmarc_c

uqs pushed a commit to freebsd/freebsd-ports that referenced this pull request Apr 1, 2021
mail/opendmarc: fix multiple addresses in From vulnerability

- please note that it might only be a partial fix, see
  trusteddomainproject/OpenDMARC#48 (comment)

PR:		240505
Reported by:	protonmail
Approved by:	ports-secteam (delphij)
Obtained from:	trusteddomainproject/OpenDMARC#48
Security:	https://protonmail.com/blog/bellingcat-cyberattack-phishing/
@ztjuh
Copy link

ztjuh commented Jun 21, 2022

I am running v1.3.2-7 on Ubuntu 20.04, am I vulnerable?

EDIT: I found the answer on https://ubuntu.com/security/cves?q=&package=opendmarc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CVE-security-issue CVE assigned security Issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet