Front-Running Vulnerability in TransferRestrictor Contract's restrict Function

Summary

Potential Front-Running Vulnerability in the restrict Function of the TransferRestrictor Contract.

Vulnerability Detail

The restrict function in the TransferRestrictor contract is susceptible to front-running attacks. This function allows the contract owner to add an account to a blacklist, which restricts the account from sending or receiving tokens. The issue lies in the fact that once a transaction is broadcast to restrict an account, it is visible in the mempool where malicious actors can observe it before it's mined.

A user might be incentivized to front-run the restrict transaction with a transaction that mitigates the consequences of being blacklisted (e.g., moving their tokens to another address) by providing a higher gas fee, which would increase the likelihood of their transaction being mined before the restrict transaction.

Impact

A user could potentially avoid being blacklisted and continue to send or receive tokens even after a restriction has been attempted. This could lead to potential misuse or manipulation of the platform, and might result in undermining the control the owner has over token transfers.

Code Snippet

The vulnerability lies in the restrict function in the TransferRestrictor contract:

Link to code


function restrict(address account) external onlyOwner {
    blacklist[account] = true;
    emit Restricted(account);
}

Tool used

Manual Review

Recommendation

To mitigate front-running risks, consider employing a commit-reveal scheme or submit the restrict transaction as a private transaction via services such as Flashbots or similar relays. The latter bypasses the public mempool, preventing front-running by directly communicating with miners. As always, any new implementation should be thoroughly tested and audited.

Duplicate of #63

sherlock-audit / 2023-06-dinari-judging

dec3ntraliz3d - Front-Running Vulnerability in TransferRestrictor Contract's restrict Function #66