An attacker could front-run the ERC20Airdrop.claimAndDelegate function, thereby preventing the user from claiming their funds

[c4-bot-3]

Lines of code

https://github.com/code-423n4/2024-03-taiko/blob/f58384f44dbf4c6535264a472322322705133b11/packages/protocol/contracts/team/airdrop/ERC20Airdrop.sol#L71

Vulnerability details

The ERC20Airdrop contract provides only the claimAndDelegate function to claim funds from the contract. The issue arises from the fact that an attacker could front-run the user by calling IVotes.delegateBySig function directly with the signature from the user's transaction. In this case, the user's transaction will revert and the user won't be able to claim their funds. The attacker might do this constantly, effectively preventing the user from claiming funds. This issue becomes even more severe because of these facts:

1. The user's transactions to claim funds are more costly than the attacker's transactions to prevent it since the revert of the user's transactions happens almost at the end of the execution
2. The token in question has voting functions so the attacker might have an indirect incentive to perform such an attack. In some cases even delaying claiming might be favorable to an attacker.

It's worth mentioning that users can still protect themselves from this attack by utilizing protected RPC but it requires some additional steps and costs more for the user.

Impact

An attacker might front-run a user's transactions, effectively preventing the user from claiming their funds, or at least delaying the process.

Proof of Concept

-

Tools Used

Manual Review

Recommended Mitigation Steps

Consider separating claiming and delegating processes by implementing the claim function that doesn't involve the delegating part.

Assessed type

DoS

[c4-pre-sort]

minhquanym marked the issue as primary issue

[c4-pre-sort]

minhquanym marked the issue as sufficient quality report

[dantaik]

I think this a valid report but the severity of this bug is minor. I've created a PR to address this issue: taikoxyz/taiko-mono#16622

[c4-sponsor]

dantaik (sponsor) confirmed

[c4-sponsor]

dantaik marked the issue as disagree with severity

[adaki2004]

@dantaik I'd agree with the severity. The audited version a person could setup a server and a node, frontrunnig every transaction, theoretically blocking the whole system. (I know it is fixed, but i'd accept medium).

[c4-sponsor]

adaki2004 marked the issue as agree with severity

[0xean]

downgrading to QA, these hypothetical DOS attacks have no economic incentive to the attacker and I have yet to see proof of them occurring in the wild.

[c4-judge]

0xean changed the severity to QA (Quality Assurance)

[c4-judge]

0xean marked the issue as grade-b