Tribe Turbo contest - asgeir's results

A new DeFi primitive that allows any token to become productive and provide FEI liquidity at no cost to the markets that need it most.

General Information

Platform: Code4rena

Start Date: 17/02/2022

Pot Size: $75,000 USDC

Total HM: 7

Participants: 23

Period: 7 days

Judge: GalloDaSballo

Total Solo HM: 2

Id: 92

League: ETH

Tribe

Findings Distribution

Researcher Performance

Rank: 20/23

Findings: 1

Award: $215.57

🌟 Selected for report: 0

πŸš€ Solo Findings: 0

Findings Information

🌟 Selected for report: csanuragjain

Also found by: 0x1f8b, Dravee, IllIllI, Picodes, Ruhum, WatchPug, asgeir, catchup, cmichel, defsec, hyh, kenta, nascent, pauliax, robee, samruna

Awards

215.5687 USDC - $215.57

Labels

bug
QA (Quality Assurance)
disagree with severity

External Links

Lines of code

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

Vulnerability details

Impact

The safe owner can call gib function in TurboSafe.

In other words, the creator of a safe can impound (or steal) any amount of the underlying token available (and transfer it to any address).

The reason is that the requiresLocalOrMasterAuth modifier in the TurboSafe contract skips all auth checks if the msg.sender is the owner.

Proof of Concept

  1. Create a safe via the TurboRouter's createSafe function.
  2. Let users have time to deposit (the owner can even set a new authority that allows anybody to deposit)
  3. The owner calls gib and transfers all the underlying to themselves.

Tools Used

Manual review.

One way of mitigating the issue is for the gib function to not rely on the requiresLocalOrMasterAuth modifier but instead have its own modifier-auth-check to check if the msg.sender is allowed to call the gib function.

#0 - transmissions11

2022-02-21T09:33:06Z

i agree this is not desired behavior but dispute the severity, whats the issue? they still cant withdraw without repaying their debt

#1 - Joeysantoro

2022-02-25T00:18:27Z

Disputing to low

#2 - GalloDaSballo

2022-03-12T17:00:38Z

The warden showed how the owner can break the accounting of safe by using gib, this is contingent on them doing it to their own safe so Medium severity would be more appropriate.

However, impact is further reduced as the function redeemUnderlying by the cToken will still protect against withdrawing an undercollateralized amount.

This, paired with the fact that the owner is basically breaking their own stuff, leads me to agree with a Low Severity

#3 - GalloDaSballo

2022-03-20T15:08:25Z

Judging as QA Report, 3/10

#4 - CloudEllie

2022-03-25T03:37:26Z

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 "The safe owner can steal the safe's collateral."

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax Β© 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter