🥾Omitted Approval for Contract Interactions Within a Protocol
A recurring vulnerability in smart contract programming is the omission of approval when one contract within a protocol needs to interact with another. The ERC20 token standard requires a contract or an account to grant permission ("approval") to another contract or account to spend its tokens. However, this crucial approval step is sometimes overlooked, leading to failures in contract interactions.
Consider three case examples where the approval was overlooked:
Case 1: The BasicSale contract was making a vest() function call to the VestLock contract, but it forgot to set the approval for the VestLock contract. This oversight led to a failure in the function call, rendering the BasicSale contract useless as the main tokens sent to it would become irretrievable.[H-01] Contract BasicSale is missing an approve(address(vestLock), 2**256-1) call (Bug Bounty)
Case 2: In the setZapConfig function of the SettToRenIbbtcZap contract, the curvePool or token was updated, but the token was not approved for the curvePool. This oversight caused a malfunction in the contract and broke the minting process.[M-02] Missing _token.approve() to curvePool in setZapConfig (Bug Bounty)
Case 3: The liquidateDai() function was meant to swap Dai to ETH using Uniswap’s swapExactTokensForETH, but the FSD contract (acting as msg.sender) hadn't approved UniswapV2 with an allowance for the tokens being attempted to swap. This caused the swap to fail.[M-02] Call to swapExactTokensForETH in liquidateDai() will always fail (Bug Bounty)
Last updated