Closed code423n4 closed 2 years ago
Bad owner manipulation. But we must check that.
As stated in the contest, the contracts will be owned by a multisig behind a 7 day timelock, so there is no actual threat here. However, this finding does have some value since the 0 check does appear in setRoyaltiesWeight
and _addShareholder
so it makes sense to add it to updateShareholder
for consistency. So I am changing this to low severity.
Addressed this in the QA report #9. Closing here.
Lines of code
https://github.com/code-423n4/2022-02-nested/blob/main/contracts/FeeSplitter.sol#L134-L140
Vulnerability details
Impact
Under certain circumstances, Royalty owner can steal all fees funds which were meant for Stakeholders
Proof of Concept
Navigate to updateShareholder function in FeeSplitter.sol#L134-L140 and observe that there is no check to validate if newly updated weight!=0
This can have disaster impact as shown below
Assume owner has set one stakeholder X with the weight 1 and Royalty weight as 1
Owner uses the updateShareholder function and sets the stakeholder X weight to 0, which is success
This makes the final new totalWeights as 1 (Only Royalty weight)
Factory calls the sendFees function with amount 1000.
Since both totalWeights and royaltiesWeight is 1 so weight becomes 1-1 =0
Amount 1000 is transffered to this contract
_sendFees does nothing as stakeholder weight is 0 and also weights passed is 0
Finally contract has balance fees with no stakeholder able to claim
Now Factory owner calls sendFeesWithRoyalties with amount 100
Since totalWeights is equal to Royalty weight so _computeShareCount gives full shares of 100 to Royalty owner which also sets _tokenRecords.totalShares to 100 at _addShares function
Now Royalty owner has to simply call releaseToken which computes the amount using getAmountDue. Now getAmountDue considers full contract balance which currently is 1000+100=1100
Recommended Mitigation Steps
Add a new check in updateShareholder which does not allows the updated weight to be 0