Malicious users can DoS honest user redemptions utilizing throttles and flashloans

[c4-bot-3]

Lines of code

https://github.com/code-423n4/2024-07-reserve/blob/main/contracts/p1/RToken.sol#L105 https://github.com/code-423n4/2024-07-reserve/blob/main/contracts/p1/RToken.sol#L183 https://github.com/code-423n4/2024-07-reserve/blob/main/contracts/p1/RToken.sol#L121-L122 https://github.com/code-423n4/2024-07-reserve/blob/main/contracts/p1/RToken.sol#L199-L200

Vulnerability details

Description

RTokens have supply throttles, which should restrict the system to organic behavior; one is used for net issuance, and the other for net redemption. The throttles recharge over one hour with the parameters set by governance. This influences the number of RTokens that can be issued and redeemed per hour and can give the RTokens some protection. However, this protection also allows malicious users to prevent honest users from redeeming their tokens by leaving the throttles empty.

Proof of concept

When a user wants to issue new RTokens, they can only issue as many RTokens as the issuanceThrottle allows. Same when they want to redeem, they can only redeem as much as the redemptionThrottle allows. On issuance, the issuanceThrottle is decreased by the amount of issued token and the redemptionThrottle is increased by the amount of issued token, while on the redeem it is the other way around. Since there is no restriction on how often users can issue and redeem RTokens, a malicious user can DoS honest users by emptying the throttles with flashloans.

Consider the following scenario:

1. Alice wants to redeem her tokens after some time, so she submits a redeem tx.
2. Bob, a malicious user, sees the tx and quickly sends a transaction, which
   1. Loans the necessary amount of tokens for an issuance via flashloan
   2. Issues the whole available amount of RToken
   3. Redeems all the RTokens (this will increase the issuance throttle and decrease the redemption throttle)
   4. Return the flashloan

Now, the throttle is at zero, and Alice is unable to redeem her RTokens. Note that the griefer can front-run all redeem transactions this way.

Impact and likelihood

The attacker gains nothing from this attack, lowering the likelihood. The cost of such an attack would only be gas, meaning it is less likely on Ethereum mainnet but very likely on L2s. Considering this, the likelihood should be set at MEDIUM. The attack would prevent honest users from redeeming their tokens. Since this is not a permanent DoS, the funds would not be lost, the attack would need to be maintained, and if something like that were to happen, the governance could act and change the parameters of throttle, the impact of this attack should be set at MEDIUM as well, hence MEDIUM severity of the issue.

Recommendation

Consider enforcing a minimum hold period after issuance. This would not affect honest users, who are expected to hold the token, and would mitigate a flashloan issue-redemption problem.

Assessed type

DoS

[akshatmittal]

This is a known issue, people can flashloan to consume (partial) throttles. Even more so, we have it in our docs that the redemption throttle needs to be higher than issuance throttle for this very reason.

[c4-judge]

thereksfour marked the issue as unsatisfactory: Out of scope