Althea Liquid Infrastructure - Tigerfrake's results

Lines of code

https://github.com/code-423n4/2024-02-althea-liquid-infrastructure/blob/main/liquid-infrastructure%2Fcontracts%2FLiquidInfrastructureERC20.sol#L127-L146

Vulnerability details

Impact

The _beforeTokenTransfer() Implements the lock during distribution and adds to to the list of holders when needed.

It checks if the recipient (to) already holds a balance. If not, it adds the recipient to the list of holders. However, this approach might not be foolproof because a recipient could receive rewards meant for another holder if they haven't been added to the list of holders yet.

Proof of Concept

    function _beforeTokenTransfer(
        address from,
        address to,
        uint256 amount
    ) internal virtual override {
        require(!LockedForDistribution, "distribution in progress");
        if (!(to == address(0))) {
            require(
                isApprovedHolder(to),
                "receiver not approved to hold the token"
            );
        }
        if (from == address(0) || to == address(0)) {
            _beforeMintOrBurn();
        }
@>        bool exists = (this.balanceOf(to) != 0);
        if (!exists) {
            holders.push(to);
        }
    }

The line in question is:

bool exists = (this.balanceOf(to) != 0);

This line checks whether the recipient (to) already holds a balance of the token. If the balance is non-zero, it implies that the recipient is already a holder, and no action is taken. However, if the balance is zero, it's assumed that the recipient is a new holder, and they are added to the list of holders:

if (!exists) {
    holders.push(to);
}

While this approach seems reasonable at first glance, it has a potential flaw: it assumes that any recipient not currently in the list of holders is indeed a new holder.

However, this assumption may not always hold true. Here are some scenarios where this assumption might fail:

1. Transfer to an existing holder: If a token holder transfers some of their tokens to themselves, the recipient (to) will already be in the list of holders. However, because the balance check only considers whether the balance is zero or not, it will incorrectly assume that the recipient is a new holder and attempt to add them to the list again.
2. Transfer to a holder not yet added to the list: Suppose a holder receives tokens for the first time, but they haven't been explicitly added to the list of holders yet. In this case, the balance check will return zero, and the recipient will be incorrectly identified as a new holder, leading to their addition to the list.

In both scenarios, the consequence is that the recipient might receive rewards that were actually intended for another holder. This discrepancy can potentially lead to inaccuracies in reward distribution and could undermine the fairness and integrity of the system.

Tools Used

Manual Review

Recommended Mitigation Steps

To mitigate this issue, a more robust approach to tracking holders and their balances could be implemented. This might involve maintaining a comprehensive list of all token holders and their corresponding balances, ensuring that each recipient is correctly identified and handled during transfers. Additionally, stricter validation could be enforced to verify the identity of recipients before distributing rewards to them.

Assessed type

Error