Tapioca DAO - glcanvas's results

Lines of code

https://github.com/Tapioca-DAO/tap-token-audit/blob/59749be5bc2286f0bdbf59d7ddc258ddafd49a9f/contracts/governance/twTAP.sol#L498-L520 https://github.com/Tapioca-DAO/tap-token-audit/blob/59749be5bc2286f0bdbf59d7ddc258ddafd49a9f/contracts/governance/twTAP.sol#L514 https://github.com/Tapioca-DAO/tap-token-audit/blob/59749be5bc2286f0bdbf59d7ddc258ddafd49a9f/contracts/tokens/BaseTapOFT.sol#L163-L196 https://github.com/Tapioca-DAO/tap-token-audit/blob/59749be5bc2286f0bdbf59d7ddc258ddafd49a9f/contracts/tokens/BaseTapOFT.sol#L198-L245

Vulnerability details

Vulnerability details

Impact

Possible to withdraw more expensive funds from twTAP contract. For, example, we observes that, pool rewards with shitcoin and USDT, then, we can make a request so that we extract all USDT from the contract. Due to incorrect validation

Proof of Concept

To process this exploit need to use TapOFT contract (which is implementation of BaseTapOFT).

• We lock a bit of tapOFT tokens on twTAP contract with function participate. -- We receive a tokenId
• We call claimRewards on TapOFT contract. This function implements cross-chain call with passed parameters. Please, note -- here we pass address[] memory rewardTokens, which just encode as it is, No any additional checks.
• Source contract calls _nonblockingLzReceive on destination chain. In turn, this decodes passed data and call _claimRewards.
• _claimRewards decodes passed payload --

(
....
           IERC20[] memory rewardTokens,
           ...
       ) = abi.decode(
               _payload,
               (
....
                   IERC20[],...
               )
           );

Note, we decodes IERC20[] memory rewardTokens,, then this array of tokens passed to twTap.claimAndSendRewards(tokenID, rewardTokens).

• Next, deeper in execution flow -- it calls _claimRewardsOn, this function accepts IERC20[] memory _rewardTokens as it was created on Source chain, without any checks.
• In _claimRewardsOn we at the first calls claimable -- uint256[] memory amounts = claimable(_tokenId); -- this returns array of tokens amount which might be claimed. (i.e. [100, 200, 300] -- means, you may receive 100 tokens for token which has index 0 in map rewardTokenIndex)
• Then we iterates over passed array of ERC20 tokens

uint256 len = _rewardTokens.length;
            for (uint256 i = 0; i < len; ) {
                uint256 claimableIndex = rewardTokenIndex[_rewardTokens[i]];
                uint256 amount = amounts[i];

                if (amount > 0) {
                    // Math is safe: `amount` calculated safely in `claimable()`
                    claimed[_tokenId][claimableIndex] += amount;
                    rewardTokens[claimableIndex].safeTransfer(_to, amount);
                }
                ++i;
            }

And here:

                uint256 claimableIndex = rewardTokenIndex[_rewardTokens[i]];
                uint256 amount = amounts[i];

We may chose which token use, but amount calculated by contract. Therefore, if for example, in contract registered:

• token 0 -- shitcoin
• token 1 -- USDT
• token 2 -- shitcoin

we can pass to TapOFT#claimRewards tokens like: [1, 1, 1] and in _claimRewardsOn token 1 will receive payments thee times a row, thats wrong and incorrect.

Please, note:

A similar attack can be made if we pass an array of non-existent tokens, then this: uint256 claimableIndex = rewardTokenIndex[_rewardTokens[i]]; will return us the index 0 because this is how the storage in EVM works and we can call the token transfer with the index 0 several times.

Tools Used

Manual review

Recommended Mitigation Steps

• Add uniqueness validation -- revert is any token passed more than once
• Add existing validation -- revert if token absent on twTAP contract

Assessed type

Access Control

Lines of code

https://github.com/Tapioca-DAO/tap-token-audit/blob/59749be5bc2286f0bdbf59d7ddc258ddafd49a9f/contracts/options/TapiocaOptionLiquidityProvision.sol#L276-L293 https://github.com/Tapioca-DAO/tap-token-audit/blob/59749be5bc2286f0bdbf59d7ddc258ddafd49a9f/contracts/options/TapiocaOptionLiquidityProvision.sol#L297-L329 https://github.com/Tapioca-DAO/tap-token-audit/blob/59749be5bc2286f0bdbf59d7ddc258ddafd49a9f/contracts/options/TapiocaOptionLiquidityProvision.sol#L126-L143

Vulnerability details

Vulnerability details

Impact

Possible to register assetID twice with different singularity.

Proof of Concept

In TapiocaOptionLiquidityProvision let's consider registerSingularity This function only validates singularity uniqueness. But do not validate assetID uniqueness.

So, we can call registerSingularity twice with same assetID. And singularities array will contains the same assetID twice.

When we decide to remove singularity we call unregisterSingularity and iterates over _singularities, And, therefore, we delete only first assetID occurrence, but the last one will be in this array. Moreover we can't call unregisterSingularity because singularity will be removed, and assetID will point out to zero element.

This lead to case, when someone calls getSingularityPools he may get pool information which contains zeros. Because this construction

pools[i] = activeSingularities[sglAssetIDToAddress[_singularities[i]]];

will be point out to zero memory.

Therefore, user may observe incorrect data, which will be impossible to fix.

Tools Used

Manual review

Recommended Mitigation Steps

Add uniqueness constraint to assetID

Assessed type

Invalid Validation

Lines of code

https://github.com/Tapioca-DAO/tap-token-audit/blob/59749be5bc2286f0bdbf59d7ddc258ddafd49a9f/contracts/option-airdrop/AirdropBroker.sol#L84 https://github.com/Tapioca-DAO/tap-token-audit/blob/59749be5bc2286f0bdbf59d7ddc258ddafd49a9f/contracts/option-airdrop/AirdropBroker.sol#L459-L461

Vulnerability details

Impact

Users participated in phase 3 of AirdropBroker will receive only 714 tokens. But at the same time Token has 18 decimals. So this phase is wrong.

Proof of Concept

This is typo, But it's critical typo, because on phase3 users will receive 714 tokens it's 1e16 times less than single token.

uint256 public constant PHASE_3_AMOUNT_PER_USER = 714;

uint128 expiry = uint128(lastEpochUpdate + EPOCH_DURATION); // Set expiry to the end of the epoch
uint256 eligibleAmount = PHASE_3_AMOUNT_PER_USER;
uint128 discount = uint128(PHASE_3_DISCOUNT);
oTAPTokenID = aoTAP.mint(msg.sender, expiry, discount, eligibleAmount);

Tools Used

Manual review

Recommended Mitigation Steps

Fix with: uint256 public constant PHASE_3_AMOUNT_PER_USER = 714 * 1e18;

Assessed type

Error