You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Honour - burnFrom requires unBlacklisting a blacklisted address , a malicious actor can backrun the unBlacklist call to transfer tokens causing the burn to fail
#272
burnFrom requires unBlacklisting a blacklisted address , a malicious actor can backrun the unBlacklist call to transfer tokens causing the burn to fail
Summary
Usd0, Usual and UsualS have a burnFrom function that allows an adress with the burn role to burn tokens of another address.The issue is that if the address is blacklisted the burn will fail and unblacklisting the address will allow the user to frontrun the burn by transferring the tokens to another address, causing the burn to fail in this case too.
Root Cause
In the _update function in Usd0UsualUsualS the operation reverts if the from or to address is blacklisted. This function is called during a burnFrom (burnFrom -> _burn -> _update) , this means a permissioned actor(i.e. with the burn role) cannot burn from a blacklisted address and unblacklisting the address to burn the tokens will allow the malicious actor to backrun the unblacklisting or frontrun the burn by trandferring their tokens to another address causing the burn to revert due to insufficient tokens.
Internal pre-conditions
Address to be burned from must be blacklisted
External pre-conditions
No response
Attack Path
No response
Impact
Medium - broken functionality, the burner (actor with the burn role) should be able to burn from any and all addresses
PoC
No response
Mitigation
This can be mitigated by skipping the blacklist check on burn oprations ( i.e. when _update is called with to == address(0)).
Example:
function _update(addressfrom, addressto, uint256amount)
internalvirtualoverride(ERC20PausableUpgradeable, ERC20Upgradeable)
{
Usd0StorageV0 storage $ =_usd0StorageV0();
if (to !=address(0) && ($.isBlacklisted[from] || $.isBlacklisted[to])) {
revertBlacklisted();
}
super._update(from, to, amount);
}
The text was updated successfully, but these errors were encountered:
sherlock-admin4
changed the title
Lively Coffee Fish - burnFrom requires unBlacklisting a blacklisted address , a malicious actor can backrun the unBlacklist call to transfer tokens causing the burn to fail
Honour - burnFrom requires unBlacklisting a blacklisted address , a malicious actor can backrun the unBlacklist call to transfer tokens causing the burn to fail
Nov 19, 2024
Honour
Medium
burnFrom
requires unBlacklisting a blacklisted address , a malicious actor can backrun theunBlacklist
call to transfer tokens causing the burn to failSummary
Usd0, Usual and UsualS have a burnFrom function that allows an adress with the burn role to burn tokens of another address.The issue is that if the address is blacklisted the burn will fail and unblacklisting the address will allow the user to frontrun the burn by transferring the tokens to another address, causing the burn to fail in this case too.
Root Cause
In the
_update
function in Usd0 Usual UsualS the operation reverts if thefrom
orto
address is blacklisted. This function is called during aburnFrom
(burnFrom -> _burn -> _update) , this means a permissioned actor(i.e. with the burn role) cannot burn from a blacklisted address and unblacklisting the address to burn the tokens will allow the malicious actor to backrun the unblacklisting or frontrun the burn by trandferring their tokens to another address causing the burn to revert due to insufficient tokens.Internal pre-conditions
Address to be burned from must be blacklisted
External pre-conditions
No response
Attack Path
No response
Impact
Medium - broken functionality, the burner (actor with the burn role) should be able to burn from any and all addresses
PoC
No response
Mitigation
This can be mitigated by skipping the blacklist check on burn oprations ( i.e. when
_update
is called withto == address(0)
).Example:
The text was updated successfully, but these errors were encountered: