search

code-423n4 / 2021-11-fairside-findings

0 stars 0 forks source link

`FSDNetwork.getFSDPrice()` Is Vulnerable To Flash Loan Attacks #105

Open code423n4 opened 2 years ago

code423n4 commented 2 years ago

Handle

leastwood

Vulnerability details

Impact

The FSD token price is calculated using spot price directly on the curve. These price results are useful when calculating the membership fee which is distributed to protocol users and in calculating the bounty amount upon opening Cross Share Requests (CSRs). Spot prices can be easily manipulated by well-funded individuals or via flash loan attacks to generate increased membership and claim fees for the recipient users.

This issue is of medium severity as its possible for user's to extract increased fees from membership purchases.

Proof of Concept

https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/network/FSDNetwork.sol#L178-L189 https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/network/FSDNetwork.sol#L268 https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/network/FSDNetwork.sol#L365

Tools Used

https://shouldiusespotpriceasmyoracle.com/ Manual code review

Recommended Mitigation Steps

Consider avoid using spot price and adhere to the guide mentioned above in order to avoid price manipulation via flash loans. It could be useful to implement a TWAP oracle which avoids using the current block in its calculations. This should limit flash loan attacks and make it increasingly costly for well-funded individuals to manipulate the token price (assuming token liquidity is substantial). A useful TWAP flash-loan resistant implementation can be found here.

YunChe404 commented 2 years ago

There is no viable vulnerability by the exhibit described due to the flashloan fees/curve exit tributes.

pauliax commented 2 years ago

Based on official recommendations, I think this issue falls under the non-critical category: "Unless there is something uniquely novel created by combining vectors, most submissions regarding vulnerabilities that are inherent to a particular system or the Ethereum network as a whole should be considered non-critical. Examples of such vulnerabilities include front running, sandwich attacks, and MEV. One important caveat to all of the above: unless otherwise specified by the contest sponsor or intended to be handled by the code. For example, flash loans are generally unavoidable, but since MarginSwap had a safeguard against them, we considered these findings relevant in their contest."

However, because lately we have seen some major hacks related to price manipulation (e.g. Rari Fuse VUSD pool), where even TWAP was exploited, I would like to leave this issue with a low severity score, as a reminder that spot prices and oracles are a subject of manipulation and need special attention.