Blacklisted user can burn tokens during WHITELIST_ENABLED state

[c4-bot-9]

Lines of code

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

Vulnerability details

Finding description and impact

Blacklisted user can burn tokens during WHITELIST_ENABLED state. This breaks the main invariant from the README. This could become an issue when the admin tries to redistribute the blacklisted user's UStb balance using redistributeLockedAmount() but the blacklisted user frontruns it with a burn.

Proof of Concept

According to the comment here, it is possible for an address to be whitelisted and blacklisted at the same.

During the WHITELIST_ENABLED state, the code block below is checked when burning tokens to ensure only whitelisted addresses can burn their tokens. But since blacklisted users also have the whitelisted role as per the comment above, the condition evaluates to true and allows the blacklisted address to burn tokens.

File: UStb.sol
208:             } else if (hasRole(WHITELISTED_ROLE, msg.sender) && hasRole(WHITELISTED_ROLE, from) && to == address(0)) {
209:                 // whitelisted user can burn

Recommended mitigation steps

Add the conditions !hasRole(BLACKLISTED_ROLE, msg.sender) and !hasRole(BLACKLISTED_ROLE, from) to the check.

[c4-judge]

0xEVom marked the issue as duplicate of #3

[c4-judge]

0xEVom marked the issue as satisfactory

[mcgrathcoutinho]

Hi @0xEVom, could you please select this report as the primary selected for report?

Other than specifying what the primary issue mentions, this issue also includes an additional scenario in the impact section where the blacklisted user can frontrun the admin's restributeLockedAmount() call, effectively depriving the admin from redistributing the tokens to a non-blacklisted address to serve its intended purpose.

Thank you for your time!

[0xEVom]

@mcgrathcoutinho agree that this could be seen as an additional impact. The DEFAULT_ADMIN_ROLE cannot immediately sidestep this and mint tokens to the recipient of the redistribution, but is forced to coordinate with the MINTER_ROLE.

[c4-judge]

0xEVom marked the issue as selected for report