FairSide contest - leastwood's results

Handle

leastwood

Vulnerability details

Impact

The updateVestedTokens() function is intended to be called by the FSD.sol contract when updating a user's vested token amount. A check is performed to ensure that _user == beneficiary, however, as _user is a user controlled argument, it is possible to spoof calls to updateVestedTokens() such that anyone can arbitrarily add any amount to the vested contract. Additionally, there is no check to ensure that the call originated from a trusted/whitelisted source.

There are two main reasons as to why the beneficiary or an attacker would want to call this function:

• To increase the vested amount such that calculateVestingClaim() allows them to withdraw their entire vested amount without waiting the entire duration.
• An attacker wishes to block withdrawals from other vested contracts by preventing successful calls to claimVestedTokens() by the beneficiary account. This can be done by increasing the vested amount such that safeTransfer() calls fail due to insufficient token balance within the contract.

Proof of Concept

https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/token/FSDVesting.sol#L147-L161 https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/token/FSDVesting.sol#L100-L115 https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/token/FSDVesting.sol#L125 https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/token/FSDVesting.sol#L134

Tools Used

Manual code review. Discussions with dev.

Recommended Mitigation Steps

Ensure that the updateVestedTokens() function is only callable from the FSD.sol contract. This can be done by implementing an onlyFSD role.

Handle

leastwood

Vulnerability details

Impact

FSDVesting.claimTribute() attempts to claim staking rewards which are stored as tributes and generated through membership purchases by the FSD network. The FSDVesting.sol contract accrues a conviction score which generates a percentage claim over tributes locked in FSD.sol. However, this function does not directly call TributeAccrual.claimTribute() and as a result, will instead transfer the tribute directly out the contract's vested holdings. This reduces the vested amount in FSDVesting.sol, breaking the contract as the beneficiary account is unable to claim all vested tokens without their call failing.

Therefore, this issue is of high severity as any honest tribute claim will potentially result in locked vested tokens due to a bricked FSDVesting.sol contract.

Proof of Concept

https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/token/FSDVesting.sol#L212-L226 https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/dependencies/TributeAccrual.sol#L155-L168

Tools Used

Manual code review.

Recommended Mitigation Steps

Consider updating the FSDVesting.claimTribute() function to directly call TributeAccrual.claimTribute() and then transfer the tribute to the beneficiary account. This will ensure that the tribute amount is transferred to the FSDVesting.sol contract before being transferred to the beneficiary.

This could look like the following:

    function claimTribute(uint256 num) external onlyBeneficiary {
        uint256 tribute = fsd.availableTribute(num);

        fsd.claimTribute(num);

        fsd.safeTransfer(msg.sender, tribute);

        emit TributeClaimed(msg.sender, tribute);
    }

Handle

leastwood

Vulnerability details

Impact

Conviction scores are calculating by taking the user's balance and multiplying it by the time elapsed. This score is updated upon each token transfer, or alternatively by directly calling ERC20ConvictionScore.updateConvictionScore(). The availableTribute() and availableGovernanceTribute() functions calculate a user's share by calculating their percentage of the total conviction score to find the amount owed to them.

This is shown in the following statement where userCS is the user's conviction score and totalCS is the protocol's total conviction score:

return amount.mul(userCS).div(totalCS);

The tribute amount that can be successfully claimed disproportionally favours users who have updated their conviction score more recently and who are early to claim their allocated tribute.

Proof of Concept

Consider the following POC:

• Two users Alice and Bob both have a conviction score of 5 at time = 1.
• Time advances such that time = 2.
• Bob calls updateConvictionScore() which sets his conviction score to 5 * time = 10 where time = 2.
• Therefore, the total conviction score is now 15 and Alice and Bob's individual conviction scores are 5 and 10 respectively.
• Bob attempts to call claimTribute() where the tribute to claim is of size 15 tokens. As a result, Bob receives 10 tokens according to the calculation mentioned above ((15*10)/15).
• Alice updates her conviction score and also attempts to call claimTribute(), receiving 7.5 tokens in the process.
• As a result, a total of 22.5 tokens were transferred out despite the tribute amount being only 15 tokens in total.

As you can see from the above example, the amount of tokens transferred favours user's who claim early and update their conviction score. It is entirely possible that due to the finite amount of tokens stored in the contract, a number of user's won't be able to successfully claim their allocated tribute.

https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/dependencies/TributeAccrual.sol#L93-L112 https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/dependencies/TributeAccrual.sol#L117-L136 https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/dependencies/TributeAccrual.sol#L156 https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/dependencies/TributeAccrual.sol#L179 https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/dependencies/ERC20ConvictionScore.sol#L476-L479

Tools Used

Manual code review.

Recommended Mitigation Steps

There is no easy solution to the mentioned issue. Ideally, all users should have an up to date conviction score whenever claimTribute() or claimGovernanceTribute() are called, although this would be an incredibly gas intensive mitigation. Alternatively, the protocol's total conviction score can be calculated by tracking the total minted balance of FSD.sol's token and multiplying this by a running total of time elapsed. This will need to be adjusted whenever tokens are minted or burned and updated during tribute claims.