UStb can be minted to non-whitelisted users during WHITELIST_ENABLED state

[c4-bot-8]

Lines of code

https://github.com/code-423n4/2024-11-ethena-labs/blob/e93ee09b10f900bd3be385f392c80920898bf53e/contracts/ustb/UStb.sol#L191

Vulnerability details

Finding description and impact

UStb can be minted to non-whitelisted users even when whitelist mode has been enabled on UStb contract. This breaks the main invariant mentioned in the README.

Proof of Concept

The below code block is from the _beforeTokenTransfer() function(), which is called at the beginning of the ERC20 _mint() internal function. When the transferState is WHITELIST_ENABLED, it should only UStb to be minted to whitelisted users as mentioned under the main invariants in the README. But since the to address is not checked to have the WHITELISTED_ROLE as well, the call goes through.

```solidity
File: UStb.sol
198:             } else if (hasRole(MINTER_CONTRACT, msg.sender) && from == address(0) && !hasRole(BLACKLISTED_ROLE, to)) {
199:                 // minting

A coded proof of concept is recommended for high severity findings.

Recommended mitigation steps

Add hasRole(WHITELISTED_ROLE, to) in the check.

[c4-judge]

0xEVom marked the issue as satisfactory

[c4-judge]

0xEVom marked the issue as primary issue

[iethena]

The Minter has a special role in the protocol and it is seen as a non-issue that UStb can be minted to non-whitelisted addresses while whitelist mode is enabled because the beneficiary cannot transfer those minted tokens. Please note that “mint” functionality is intentionally not specified in the invariant being referenced as this scenario has already been considered.

It should be further noted that the Minter role can be revoked by the Admin if there is any non-compliant behavior. The Minter is bound by an off-chain contractual obligation to act benevolently with their power in that role.

Due to this we see the likelihood of this scenario being low. The impact of this scenario is also low as the collateral in the protocol is not affected and the position of other users is not affected. We argue this is not an issue as it does not break any of the main invariants, however we acknowledge that this scenario is accurate from an informational standpoint.

[c4-judge]

0xEVom marked the issue as unsatisfactory:
Invalid