Exploiting Gmail’s ARC implementation flaws

In my thesis I performed several tests on the Mail Transfer Agents (MTAs) of popular mail providers. Doing this, I found two flaws in Gmail’s Authenticated Received Chain (ARC) implementation. These flaws can be turned into two denial of service (DoS) attacks, which will be described in this post. My report was accepted by Google and rewarded with a bug bounty.

Background

ARC (Authenticated Received Chain) is a relatively new email authentication protocol that enables intermediate MTAs to sign the original authentication results. This can be useful for mail that is forwarded as it allows the final receiving MTA to validate the original authentication results.

The process looks like this:

• The first receiving MTA receives the email and performs authentication checks like SPF, DKIM and DMARC

• The MTA then appends a ARC signature with the results to the email headers before forwarding it to the next MTA

• The final receiving MTA validates the ARC signature to so it knows the original authentication results. Validating the ARC signature includes performing a DNS query to retrieve the public key of the intermediate MTA.

In the above example there was only one intermediate MTA, but ARC allows for multiple intermediate MTAs, also called a chain. If an intermediate MTA wants to append an ARC signature to the chain it first has to validate all the previous signatures. This validation process is described in RFC 8617 section 5.2. Note these specifications:

1. The maximum number of ARC Sets that can be attached to a message is 50. If more than the maximum number exist, the Chain Validation Status is “fail”, and the algorithm stops here.

2. Validate each AS beginning with the greatest instance value and proceeding in decreasing order to the AS with the instance value of 1. If any AS fails to validate, the Chain Validation Status is “fail”, and the algorithm stops here.

Findings

When testing Gmails MTA I found that its validator does not adhere to the previously described specifications:

1. Gmail does not have a limit on the amount of ARC signatures it is validating
2. Gmail does not stop validating after seeing an invalid ARC signature

Below are some benchmarks when sending a large amount of valid ARC signatures with a 1024 bit key. Time is measured from first to last ARC DNS query and therefore shows the time the ARC validation process takes.

Note that the mail with 15.000 signatures was rejected because of a size limit, but the ARC validation was still executed and therefore can still be used in the attacks described below.

Exploitation

Attackers could exploit flaws in Gmail’s ARC implementation to launch a DoS attack against Gmail’s infrastructure itself (A1), or to carry out a reflected DoS attack targeting a victim’s authoritative nameserver (A2). Furthermore, attackers can escalate the DoS attack to potentially perform a spoofing attack (A3) on a domain that enforces a strict DMARC policy

A1. DoS attack on Gmail MTA An attacker can craft a mail with a large amount (thousands) of self-signed ARC signatures, and send them many times to Gmail. If every signature uses a different subdomain, it takes a significant amount of time from the MTA to perform the large amount of DNS queries. On top of that, it will take significant amount of load on the CPU to verify them all, especially if large keys (8192 bits) were used for signing.

A2. Reflected DoS attack through Gmail MTA An attacker can craft a mail with a large amount (thousands) of ARC signatures seemingly signed by a victim’s domain and send them many times to Gmail. Every signature will be invalid, but Gmails MTA will not stop after a failed validation and will therefore continue to perform a large amount of DNS queries to the victim’s authoritative nameserver.

A3. (Theoretical) DMARC policy bypass With A2, an attacker can make Gmails DNS resolvers flood the authoritative nameserver of a victims domain. As a result, the victim’s authoritative nameserver might temporary rate-limit the IP address(es) of Gmails resolvers. If an attacker now sends a mail with a spoofed From: header with the victim’s domain, Gmail cannot retrieve the DMARC policy anymore because of the rate-limit. Therefore the default DMARC policy of “none” is assumed and the mail will land in the Inbox, even if the domain actually had a strict DMARC policy.

See the video for a demonstration of attack A1:

Mitigation

1. Stop the ARC validation if there are more than 50 signatures, as stated in the RFC.
2. Stop the ARC validation after seeing a failed check, as stated in the RFC. This not only reduces wasted resources on the MTA, but also prevents reflecting attacks like A2
3. Optional: Mails with a huge amount of signatures are now first validated, and then rejected because of a size limit (MaxSizeError). Consider to first do a size limit check before starting the validation process to reduce wasted resources on the MTA. This would also reduce the effectiveness of attacks A1 and A2

Timeline