search

code-423n4 / 2022-02-tribe-turbo-findings

1 stars 0 forks source link

Gibber can take any amount from safes #62

Open code423n4 opened 2 years ago

code423n4 commented 2 years ago

Lines of code

https://github.com/code-423n4/2022-02-tribe-turbo/blob/66f27fe51083f49f7935e3fe594ab2380b75dee8/src/TurboSafe.sol#L335

Vulnerability details

Impact

Although Gibber is supposed to behind governance timelock, there are still significant "rug risk" when such privillaged user can remove all fund from a vault unconditionally.

Proof of Concept

https://github.com/code-423n4/2022-02-tribe-turbo/blob/66f27fe51083f49f7935e3fe594ab2380b75dee8/src/TurboSafe.sol#L335

function gib(address to, uint256 assetAmount) external nonReentrant requiresLocalOrMasterAuth {
        emit SafeGibbed(msg.sender, to, assetAmount);

        // Withdraw the specified amount of assets from the Turbo Fuse Pool.
        require(assetTurboCToken.redeemUnderlying(assetAmount) == 0, "REDEEM_FAILED");

        // Transfer the assets to the authorized caller.
        asset.safeTransfer(to, assetAmount);
    }

Recommended Mitigation Steps

Limit gib to certain collateral ratio

Joeysantoro commented 2 years ago

This is intended behavior. There will be an extended immutable timelock behind the gibber, so Turbo users will have notice to less and withdraw. The only scenario where they can't is when the boosted strategy is insolvent, which is intended behavior

GalloDaSballo commented 2 years ago

While there's something to be appreciated about a simple architecture, I believe that the flexibility of the Fuse Pool would allow to account for insolvency in a trustless way through the Fuse Liquidation code.

Additionally, while the code may be put behind timelock, we can only review the code that is in scope and that we can prove behaves in a certain way.

In this case the warden has identified that the system admin can move funds at any time, without limitation.

Because this type of exploit is contingent on a malicious admin, I believe Medium Severity to be appropriate.

The sponsor intends on using an immutable timelock so for end users of the protocol I highly recommend to verify that statement.