search

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

1 stars 0 forks source link

QA report #31

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#L339

Vulnerability details

Impact

The TurboGibber.impound function calls TurboSafe.gib with the assetAmount parameter and tries to redeem the cAsset. However, the TurboSafe owner can frontrun this transaction and withdraw as much cAssets such that only assetAmount - 1 is able to be redeemed. The impound then fails and impoundAll must be used.

Recommended Mitigation Steps

Generally, either impound or impoundAll should always be a private transaction sent through something like flashbots. Because, if the safe owner sees that their collateral will be stolen, they will frontrun it and redeem everything.

Joeysantoro commented 2 years ago

This is a known issue, and is the reason impoundAll was included. Given that the gibber has a lot of power, its economically in the best interest of the safe holder to not engage in adversarial behavior or risk impoundAll being called subsequently.

Disputing to a low severity issue and will acknowledge but not fix

GalloDaSballo commented 2 years ago

I believe the finding to be valid, but also believe that its reduced economic scope should warrant a Low Severity.

If this type of frontrunning grief were to happen, it would ultimately result in a loss of gas and not any leakage of value

GalloDaSballo commented 2 years ago

Judging as QA report, 3/10

CloudEllie commented 2 years ago

Since this issue was downgraded to a QA level, and the warden did not submit a separate QA report, we've renamed this one to "QA report" for consistency.

The original title, for the record, was "TurboGibber.impound can be frontrun."