Open code423n4 opened 2 years ago
It should be noted that the second example referring to _approveStakerVaultSpendingLpTokens()
is not an issue. This is neither a member variable that can be updated nor is it behind a time lock. Both the staker
and lpToken
can only be set once and hence the safeApprove
in the aforementioned function can only be called once.
Lines of code
https://github.com/code-423n4/2022-04-backd/blob/c856714a50437cb33240a5964b63687c9876275b/backd/contracts/actions/topup/TopUpAction.sol#L50 https://github.com/code-423n4/2022-04-backd/blob/c856714a50437cb33240a5964b63687c9876275b/backd/contracts/pool/LiquidityPool.sol#L721
Vulnerability details
OpenZeppelin's
safeApprove()
will revert if the account already is approved and the newsafeApprove()
is done with a non-zero valuehttps://github.com/OpenZeppelin/openzeppelin-contracts/blob/fcf35e5722847f5eadaaee052968a8a54d03622a/contracts/token/ERC20/utils/SafeERC20.sol#L45-L58
Impact
Customers can be prevented from
register()
ing the sametoken
/stakerVaultAddress
as another customer; and once changed away from, stakers and lptokens can't be used in the future.Proof of Concept
There are multiple places where
safeApprove()
is called a second time without setting the value to zero first.register()
callslockFunds()
for each user registration, and since users will use the same tokens and staker vaults, the second user'sregister()
call will fail:https://github.com/code-423n4/2022-04-backd/blob/c856714a50437cb33240a5964b63687c9876275b/backd/contracts/actions/topup/TopUpAction.sol#L36-L50
The changing of either the staker or an lp token is behind a time-lock, and once the time has passed, the changed variables rely on this function:
https://github.com/code-423n4/2022-04-backd/blob/c856714a50437cb33240a5964b63687c9876275b/backd/contracts/pool/LiquidityPool.sol#L717-L722
If a bug is found in a new
staker
orlpToken
and the governor wishes to change back to the old one(s), the governor will have to wait for the time-lock delay only to find out that the old value(s) cause the code to revert.I've filed the other more-severe instances as a separate high-severity issue, and flagged the remaining low-severity instances in my QA report
Tools Used
Code inspection
Recommended Mitigation Steps
Always do
safeApprove(0)
if the allowance is being changed, or usesafeIncreaseAllowance()