pypolicyd-spf returns false result, which may be exploited by attackers

[Jianjun]

pypolicyd-spf returns 'Pass' results when MAIL FROM check is 'None' and HELO check is 'Pass', which can be exploited by attackers to bypass DMARC.

When an attacker sends the following message,

HELO: attacker.com
MAIL FROM: <email address hidden>
...
From: <email address hidden>
...

he can bypass the SPF and DMARC authentication in mail servers because it can pass both SPF check and DMARC alignment test.

[Scott Kitterman (kitterman)]

On Friday, August 2, 2019 3:41:40 PM EDT you wrote:
> *** This bug is a security vulnerability ***
>
> Private security bug reported:
>
> pypolicyd-spf returns 'Pass' results when MAIL FROM check is 'None' and
> HELO check is 'Pass', which can be exploited by attackers to bypass
> DMARC.
>
> When an attacker sends the following message,
>
> HELO: attacker.com
> MAIL FROM: <email address hidden>
> ...
> From: <email address hidden>
> ...
>
> he can bypass the SPF and DMARC authentication in mail servers because
> it can pass both SPF check and DMARC alignment test.

I think this is a bug in the DMARC processor. For you example, here's the
output the policy-server gives (using the most recent version):

Authentication-Results: mx.example.org; spf=pass (helo) smtp.helo=attacker.com

The DMARC processor should be looking at the smtp property and not using helo
results for DMARC.

Scott K

[Jianjun (whucjj)]

Yes, it could introduce ambiguity between SPF and DMARC processor.

What do you think is the correct result for this case at the specification level?

Per RFC 7208, if a "conclusive determination" can be made based on HELO check, MAIL FROM check can be avoided. Does that mean "Pass" is the correct result? I am not quite clear about that. Thanks.

[Scott Kitterman (kitterman)]

On Friday, August 2, 2019 4:49:33 PM EDT you wrote:
> Yes, it could introduce ambiguity between SPF and DMARC processor.
>
> What do you think is the correct result for this case at the
> specification level?
>
> Per RFC 7208, if a "conclusive determination" can be made based on HELO
> check, MAIL FROM check can be avoided. Does that mean "Pass" is the
> correct result? I am not quite clear about that. Thanks.

What that language was meant to support is the idea that if you were going to
reject the message due to SPF helo results there was no need to also check
MAIL FROM. By the letter of it's predecessor, RFC 4408, the MAIL FROM check
was always required.

If you look at https://tools.ietf.org/html/rfc7208#section-4.1 you can see
that both HELO and Mail From are treated as first class inputs to check_host().

From a specification perspective, the result needs to consider what identity it
relates to, which is why I think a DMARC processor that assumes any reported
SPF result relates to the Mail From of the message is buggy.

Scott K

[Scott Kitterman (kitterman)]

Additionally, if you look at https://tools.ietf.org/html/rfc7489#section-3.1.2 you'll see that for DMARC it is specified that the alignment for SPF needs to be based on the identifier that was authenticated. I think this confirms my belief that the issue here is a DMARC processor failing to do alignment validation correctly.

Closing the bug. Making it public too, since there's no security issue here.

I'd recommend following this up with the source of your DMARC processing software.

[Jianjun (whucjj)]

Thanks for the clarification. I will contact the DMARC vendors.

Can I keep this issue private? Because some vendors are not aware of this issue and it may be abused by real attackers.

[Scott Kitterman (kitterman)]

On Friday, August 2, 2019 6:05:20 PM EDT you wrote:
> Thanks for the clarification. I will contact the DMARC vendors.
>
> Can I keep this issue private? Because some vendors are not aware of
> this issue and it may be abused by real attackers.
>
> ** Information type changed from Public to Private Security
>
> ** Information type changed from Private Security to Private

OK. I'll leave it private.

Scott K