Lines of code
<https://github.com/code-423n4/2023-11-canto/blob/335930cd53cf9a137504a57f1215be52c6d67cb3/1155tech-contracts/src/Market.sol#L226-L237&gt;

Vulnerability details

Impact

Assume a user buys some shares and mints it to an NFT and sends the shares to a cold wallet for safety. The following happens:

• A user buys 10 shares using buy() is called, the rewardsLastClaimedValue is updated to the latest holder rewards, the tokensByAddress is now equals 10.
• The user then mints 10 NFTs, this changes the tokensByAddress to zero. The reward is updated and sent to the user.
• The user then transfers the token to cold wallet for 6 months
• The user sends the NFT back to the main wallet for burning, they would receive 0 rewards when they burn the NFT. This is because the tokensByAddress is currently zero when accruing rewards using _getRewardsSinceLastClaim

Proof of Concept

    function _getRewardsSinceLastClaim(uint256 _id) internal view returns (uint256 amount) {
        uint256 lastClaimedValue = rewardsLastClaimedValue[_id][msg.sender];
        amount =
            ((shareData[_id].shareHolderRewardsPerTokenScaled - lastClaimedValue) * tokensByAddress[_id][msg.sender]) /
            1e18;
    }

As at the time of reward computation, tokensByAddress[_id][msg.sender] would be equal to zero. The value is only updated after the latest reward is updated.
In the burnNFT:

    uint256 rewardsSinceLastClaim = _getRewardsSinceLastClaim(_id);
        rewardsLastClaimedValue[_id][msg.sender] = shareData[_id].shareHolderRewardsPerTokenScaled;
        tokensByAddress[_id][msg.sender] += _amount;

Tools Used

Manual review.

Recommended Mitigation Steps

Keep the tokensByAddress constant except when transfers or burning occur.

Assessed type

Other

The text was updated successfully, but these errors were encountered:

All reactions