Kirkeelee - AlchemicTokenV2Base.sol deviates from xERC20 (EIP-7281) standard in the implementation of the burn() function.

[github-actions]

Kirkeelee

medium

AlchemicTokenV2Base.sol deviates from xERC20 (EIP-7281) standard in the implementation of the burn() function.

Summary

The protocol aims to upgrade their alAssets contracts by implementing xERC20 (EIP-7281) standard with AlchemicTokenV2Base.sol while preserving the storage layout of the previous version (CrossChainCanonicalBase.sol). In doing so, the modified function burn(address account, uint256 amount) leads to deviation from the xERC20 and opens up attack vectors.

Vulnerability Detail

The rules around the burn function per the xERC20 are the following:

• burn MUST check that the caller's current available limit is greater than or equal to _amount
• burn MUST decrease the supply of the underlying ERC-20 by _amount and reduce the current available limit

Per the requirements of the xERC20 (EIP-7281) standard the function burn() "Can only be called by a bridge (whitelisted minter).
If you inspect the burn() function in AlchemicTokenV2Base.sol several issues arise:

function burn(address account, uint256 amount) external {
   if (msg.sender != account) {
     uint256 newAllowance = allowance(account, msg.sender) - amount;
     _approve(account, msg.sender, newAllowance);
   }

   // If bridge is registered check limits and update accordingly.
   if (xBridges[msg.sender].burnerParams.maxLimit > 0) {
     uint256 currentLimit = burningCurrentLimitOf(msg.sender);
     if (amount > currentLimit) revert IXERC20.IXERC20_NotHighEnoughLimits();
     _useBurnerLimits(msg.sender, amount);
   }

   _burn(account, amount);
 }

First, anyone with allowance(account, msg.sender)>=amount can call it and successfully burn the amount of tokens. The check if (xBridges[msg.sender].burnerParams.maxLimit > 0) will be skipped if the msg.sender is not registered/whitelisted since xBridges[msg.sender].burnerParams.maxLimit will be 0.

Secondly, the burnt amount is not registered (not deducted from the available limit) with burnerParams if the caller is not registered/whitelisted by skipping the xBridges[msg.sender].burnerParams.maxLimit > 0 check. These leads to possibility of the caller to avoid that limitation and may be used by attackers.

Overall whole concept of the xERC20 (EIP-7281) standard such as assigning/whitelisting certain bridges to mint/burn functions and limiting the amount that can be minted/burned per bridge(to set the limit to 0 in case the bridge contract is hacked or to have a certain balance of tokens in each side of the bridge) will be violated with the current implementation of the function burn().

Impact

Noncompliance with the EIP and possible loss of user funds depending on the other integrations of asset burning.

Code Snippet

https://github.com/sherlock-audit/2024-04-alchemix/blob/main/v2-foundry/src/AlchemicTokenV2Base.sol#L190-L204

Tool used

Manual Review

Recommendation

Add onlyWhitelisted modifier to the burn() function.

Duplicate of #102