Assessment reports>Bond Protocol>Threat Models>_handleTransfers

Function _handleTransfers(uint256 id_, uint256 amount_, uint256 payout_, uint256 feePaid_) internal

INTERNAL FUNCTION

  1. Intended behavior.

    • Handles transfer of funds from user and market owner/callback

  2. Negative behavior.

    • Shouldn’t allow sending to an address different than market owner/ callback.

    • Shouldn’t allow users to transfer CRAFTED tokens (via a malicious market for example) and retrieve useful tokens.(as payout ). This could happen in markets from BondBaseSDA.

  3. Preconditions.

    • msg.sender should approve to transfer amount_ value of the quoteToken tokens to Teller contract.

    • That the quote tokens supplied by the msg.sender are perfectly fine, and they have been whitelisted/ accepted before, and that there is no way to supply dummy tokens in exchange for legitimate payout tokens.

    • owner of the market should approve transferring payout value of the payoutToken tokens to Teller contract.

  4. Postconditions.

    • The quoteToken.balanceOf[msg.sender] should be depleted by amount, and the quoteToken.balanceOf[callback OR owner of market] should increase by amount after fees.

    • The payoutToken.balanceOf[callback OR owner of market] should be depleted by payout_ and the payoutToken.balanceOf[address(this)] should increase by payout_

  5. Inputs.

    • uint256 id_ - controlled

    • uint256 amount_ - controlled, if caller approved not enough tokens transaction will be rejected.

    • uint256 payout_ - uncontrolled, if the market owner approves not enough tokens transaction will be rejected.

    • uint256 feePaid_ - uncontrolled

  6. Examine all function calls the function makes.

    a. Call to aggregator.getAuctioneer(id).getMarketInfoForPurchase(id_);

    • What is controllable? (callee, params, return value): (address owner, address callbackAddr, ERC20 payoutToken, ERC20 quoteToken, , ) - it's not really controllable since it’s supposedly whitelisted in the getAuctioneer function from the aggregator

    • If return value controllable, how is it used and how can it go wrong? uncontrolled

    • What happens if it reverts or tries to reenter? No problem

    b. Call to quoteBalance = quoteToken.balanceOf(address(this))

    • What is controllable? (callee, params, return value): uncontrolled

    • If return value controllable, how is it used and how can it go wrong? even if the caller controls the token and can manipulate with return value, this doesn't affect any users. In the case of using legitimate token address caller cannot manipulate this value.

    • What happens if it reverts or tries to reenter? No problem

    c. Call to quoteToken.safeTransferFrom(msg.sender, address(this), amount_)

    • What is controllable? (callee, params, return value): caller controls amount_ value

    • If return value controllable, how is it used and how can it go wrong? There is no return value.

    • What happens if it reverts or tries to reenter? if the caller approved not enough tokens or the caller doesn’t have enough tokens, then the transaction will be rejected

    d. Call to IBondCallback(callbackAddr).callback(id_, amountLessFee, payout_);

    • What is controllable? (callee, params, return value): it’s supposed to handle the payoutTokens via the callback function back to the caller(BondBaseTeller); the id_ and payout_ params are directly controllable, being supplied through the _handleTransfers function.

    • If return value controllable, how is it used and how can it go wrong? There is no return value.

    • What happens if it reverts or tries to reenter? if this reverts, there are no payoutTokens transferred from the callback, and thus, the transaction itself fails.

Zellic © 2024Back to top ↑