Tapioca DAO - 0xG0P1's results

Lines of code

https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/2286f80f928f41c8bc189d0657d74ba83286c668/contracts/markets/bigBang/BigBang.sol#L282-L288 https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/2286f80f928f41c8bc189d0657d74ba83286c668/contracts/markets/MarketERC20.sol#L99-L102 https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/2286f80f928f41c8bc189d0657d74ba83286c668/contracts/markets/MarketERC20.sol#L84-L91

Vulnerability details

Impact

A malicious actor can drain all collateral assets from a user's account and deposit them in the BigBang contract under their name, resulting in a complete loss of funds for the user.

Proof of Concept

In the BigBang.sol contract's addCollateral function, a vulnerability exists where an attacker can bypass the allowedBorrow(from, share) modifier. By providing the collateral amount via amount and setting share to zero, the condition if (allowanceBorrow[from][msg.sender] < share) can be deceived, as allowanceBorrow[from][msg.sender] will be zero and share is also zero, resulting in a false evaluation.

The attacker can specify an arbitrary from address they wish to drain. If the yieldBox holds authority over the funds of the specified from address, the attacker gains control over the collateral amount in their name without proper authorization. Consequently, this may lead to a complete depletion of the user's collateral assets. It is crucial to address and rectify this security flaw promptly.

function addCollateral(
    address from,//address that attacker want to drain the collateral
    address to,//attacker address
    bool skim,
    uint256 amount,//amount attacker want to deposit
    uint256 share // share will zero
) public allowedBorrow(from, share) notPaused { // share is passed to the modifier
    _addCollateral(from, to, skim, amount, share);
}



function _allowedBorrow(address from, uint share) internal {
    if (from != msg.sender) {
        if (allowanceBorrow[from][msg.sender] < share) { // 0 < 0 ---> False
            revert NotApproved(from, msg.sender);
        }
        allowanceBorrow[from][msg.sender] -= share;
    }
}

Tools Used

Manual review

Recommended Mitigation Steps

Convert the amount into share first if share == 0 and then check the allowance between from and msg.sender

Assessed type

Invalid Validation

Lines of code

https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/2286f80f928f41c8bc189d0657d74ba83286c668/contracts/markets/singularity/SGLLeverage.sol#L147-L187

Vulnerability details

Impact

User can get disproportional amount of collateral for supplied borrowed asset

Proof of Concept

In the SGLLeverage.sol contract, the buyCollateral function conducts the _allowedBorrow(from, collateralShare) check at the end of the process, which can lead to a situation where an address with very limited allowance is able to swap a substantial amount of borrowed assets for an inadequate amount of collateral within the uniswapv2 pool. This vulnerability can be exploited by manipulating the price of the collateral asset through a flash loan.

For instance, if Bob approves Alice for 100 tokens, and Alice executes a flash loan that significantly reduces the price of the collateral asset in the Uniswap v2 pool, she can then proceed to call the buyCollateral function using the variables:

address from ----> Bob
uint256 borrowAmount ----> 500
uint256 supplyAmount ----> 500
uint256 minAmountOut ----> 0 // slippage
ISwapper swapper ----> uniswapv2

In this scenario, Alice can swap 1000 tokens of borrowed assets for the collateral and receive only 90 tokens as collateral shares (collateralShare ----> 90 tokens). Since the slippage is set to 0, the trade will appear successful, and the _allowedBorrow(from, collateralShare) check will be passed.

This situation exposes Bob to significant losses in borrowed assets due to the mismatch between the amount borrowed and the minimal collateral received.

Tools Used

Manual review

Recommended Mitigation Steps

implement this check _allowedBorrow(from, borrowAmount + supplyAmount)

Assessed type

Invalid Validation

Lines of code

https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/2286f80f928f41c8bc189d0657d74ba83286c668/contracts/markets/bigBang/BigBang.sol#L769-L825 https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/2286f80f928f41c8bc189d0657d74ba83286c668/contracts/markets/bigBang/BigBang.sol#L698-L702

Vulnerability details

Impact

Users can't addCollateral if skim set to true

Proof of Concept

In the given scenario, an issue arises when attempting to add collateral under certain conditions. Initially, the BigBang contract contains 100 tokens of collateral, and the variable totalCollateralShare is set to 100 tokens. However, (for example) after an user gets liquidated, the protocol only holds 60 tokens of collateral, but the totalCollateralShare remains unchanged, leading to a discrepancy.

When a user attempts to add collateral with share set to 50 and skim set to true, the _addTokens function enforces a requirement:

require(share <= yieldBox.balanceOf(address(this), _tokenId) - total);

Let's consider the values of the variables involved:

• yieldBox.balanceOf(address(this)): 110 (total collateral after liquidation - 60 + 50)
• total (oldTotalCollateralShare): 100
• share: 50

The condition becomes: 50 <= 110 - 100, which evaluates to false.

As a result, users attempting to add collateral with the skim parameter set to true are unable to do so, even when they are eligible according to the protocol logic.

To address this issue, it is essential to update the totalCollateralShare during the liquidation process to reflect the correct total collateral held by the protocol. This ensures that users can add collateral as intended, regardless of whether they set the skim parameter to true.

Tools Used

Manual review

Recommended Mitigation Steps

consider updating totalCollateralShare during the liquidation process in the _updateBorrowAndCollateralShare function

Assessed type

DoS