Platform: Code4rena
Start Date: 21/04/2022
Pot Size: $100,000 USDC
Total HM: 18
Participants: 60
Period: 7 days
Judge: gzeon
Total Solo HM: 10
Id: 112
League: ETH
Rank: 7/60
Findings: 2
Award: $4,019.43
🌟 Selected for report: 1
🚀 Solo Findings: 1
🌟 Selected for report: Ruhum
3860.1163 USDC - $3,860.12
The CvxCrvRewardsLocker contract swaps tokens through the CRV cvxCRV pool. But, it doesn't use any slippage checks. The swap is at risk of being frontrun / sandwiched which will result in a loss of funds.
Since MEV is very prominent I think the chance of that happening is pretty high.
Here's the swap: https://github.com/code-423n4/2022-04-backd/blob/c856714a50437cb33240a5964b63687c9876275b/backd/contracts/CvxCrvRewardsLocker.sol#L247-L252
none
Use a proper value for minOut
instead of 0
.
#0 - gzeoneth
2022-05-07T19:18:35Z
According to C4 Judging criteria
Unless there is something uniquely novel created by combining vectors, most submissions regarding vulnerabilities that are inherent to a particular system or the Ethereum network as a whole should be considered QA. Examples of such vulnerabilities include front running, sandwich attacks, and MEV.
However since there is a configurable minOut
that is deliberately set to 0, this seems to be a valid issue. I am judging this as Med Risk.
🌟 Selected for report: IllIllI
Also found by: 0v3rf10w, 0x52, 0xDjango, 0xkatana, Dravee, Funen, Kenshin, Ruhum, StyxRave, Tadashi, TerrierLover, TrungOre, antonttc, berndartmueller, catchup, csanuragjain, defsec, dipp, fatherOfBlocks, hake, horsefacts, hubble, jayjonah8, joestakey, kebabsec, kenta, m4rio_eth, oyc_109, pauliax, peritoflores, rayn, remora, robee, securerodd, simon135, sorrynotsorry, sseefried, z3s
159.3125 USDC - $159.31
When depositing to the liquidity pool or redeeming from it, the contract allows the user to provide a slippage check. But, the way the LP token shares work, there is no risk of being sandwiched or anything like that. Even if somebody frontruns your transaction to deposit a large amount of funds, you still get the same shares as you normally would.
Relevant code:
call()
instead of transfer()
when transferring ETHtransfer()
only provides a set amount of gas for the transaction. It can cause issues for contracts that have some form of logic in their receive()
function if gas costs of opcodes change in the future.
Relevant links:
Relevant code: