[M-02] Replay Attacks on SpokePoolPeriphery Possible

[mrice32]

Open question: can we avoid having a separate nonce by piggybacking on the permit nonce? I think we can, but this would mean we would have to require that the permit call succeed, which would open up frontrun griefing attacks. However, I'm not sure how big a deal those are in practice (private mempools and no profit opportunity).

The SpokePoolPeriphery contract enables users to deposit or swap and deposit tokens into a SpokePool. In order to do that, the assets are first transferred from the depositor's account, then optionally swapped to a different token and finally deposited to a SpokePool.

Assets can be transferred from the depositor's account in several different ways, including approval followed by the transferFrom call, approval through the ERC-2612 permit function followed by transferFrom, transfer through the Permit2 contract and transfer through the ERC-3009 receiveWithAuthorization function. The last three methods require additional user's signatures and may be executed by anyone on behalf of a given user.

However, the data to be signed for deposits or swaps and deposits with ERC-2612 permit and with ERC-3009 receiveWithAuthorization does not contain a nonce, and as such, the signatures used for these methods once can be replayed later.

The attack can be performed if a victim signed data for a function relying on the ERC-2612 permit function and wants to deposit tokens once again using the same method and token within the time window determined by the depositQuoteTimeBuffer parameter. In such a case, an attacker can first approve tokens on behalf of the victim and then call the swapAndBridgeWithPermit function or the depositWithPermit function providing a signature for deposit or swap and deposit from the past, which included less tokens than the approved amount. As a result, the tokens will be deposited and potentially swapped before, using the data from an old signature, forcing the victim to either perform an unintended swap or to bridge tokens to a different chain than intended. Furthermore, since the attack consumes some part of the permit approval, it will not be possible to deposit tokens on behalf of a depositor using the new signature until the full amount of tokens is approved by them once again.

A similar attack is also possible for the functions relying on the ERC-3009 receiveWithAuthorization function, but it requires the amount of token to be transferred to be identical to the one from the past.

Consider adding a nonce field into the SwapAndDepositData and DepositData structs and storing a nonce for each user in the SpokePoolPeriphery contract, which would be incremented when a signature is verified and accepted.