Open code423n4 opened 1 year ago
Seems valid but I have a doubt about this:
rToken issuance uses rounding mode CEIL when calculating how much a user has to pay. rToken redemption uses rounding mode FLOOR when calculating how much a user receives.
So I think there is a bit more cost involved than just gas and the attack needs to be renewed very often.
Also:
Might this be mitigated when the redemption limit is chosen significantly higher than the issuance limit?
Because then when the attack must be renewed and issue
is called, the redemption limit will be raised and not so much that it hits its limit.
So the result on redemption limit after redemption is then 0.
tbrent marked the issue as sponsor confirmed
@HollaDieWaldfee100 that's a really nice mitigation! I think that's exactly the thing to do. )
0xean marked the issue as satisfactory
0xean marked the issue as selected for report
Lines of code
https://github.com/reserve-protocol/protocol/blob/610cfca553beea41b9508abbfbf4ee4ce16cbc12/contracts/libraries/Throttle.sol#L66-L75
Vulnerability details
Impact
Attacker can deplete available issuance or redemption by first issuing and then redeeming in the same tx or vice versa. The available redemption/issuance will eventually grow back, but this temporary reduces the available amount. This can also use to front run other user who tries to redeem/issue in order to fail their tx.
Proof of Concept
In the PoC below a user is able to reduce the redemption available by more than 99% (1e20 to 1e14), and that's without spending anything but gas (they end up with the same amount of RToken as before)
Output:
Recommended Mitigation Steps
Mitigating this issue seems a bit tricky. One way is at the end of
currentlyAvailable()
to return the max ofavailable
andthrottle.lastAvailable
(up to some limit, in order not to allow to much of it to accumulate).