Incorrect checking in _assertUserHasEnoughGiantLPToClaimVaultLP #382
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
M-25
primary issue
Highest quality submission among a set of duplicates
satisfactory
satisfies C4 submission criteria; eligible for awards
selected for report
This submission will be included/highlighted in the audit report
sponsor confirmed
Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Lines of code
https://github.com/code-423n4/2022-11-stakehouse/blob/4b6828e9c807f2f7c569e6d721ca1289f7cf7112/contracts/liquid-staking/GiantPoolBase.sol#L93-L97
Vulnerability details
Impact
The batch operations of
withdrawDETH()
in GiantSavETHVaultPool.sol andwithdrawLPTokens()
in GiantPoolBase.sol are meaningless because they will fail whenever more than one lpToken is passed.Each user can perform
withdrawDETH()
orwithdrawLPTokens()
with one LPToken only once a day.Proof of Concept
Both the
withdrawDETH()
in GiantSavETHVaultPool.sol andwithdrawLPTokens()
in GiantPoolBase.sol will callGiantPoolBase._assertUserHasEnoughGiantLPToClaimVaultLP(lpToken, amount)
andlpTokenETH.burn(msg.sender, amount)
:There is a require in
_assertUserHasEnoughGiantLPToClaimVaultLP()
:At the same time,
lpTokenETH.burn(msg.sender, amount)
will updatelastInteractedTimestamp[msg.sender]
to latest block timestamp in_afterTokenTransfer()
of GiantLP.sol.So, a user can perform
withdrawDETH
orwithdrawLPTokens
of one LPToken only once a day, others more will fail by_assertUserHasEnoughGiantLPToClaimVaultLP()
.Tools Used
VS Code
Recommended Mitigation Steps
The LPToken being operated on should be checked for lastInteractedTimestamp rather than lpTokenETH.
The text was updated successfully, but these errors were encountered: