Foundry DeFi Stablecoin CodeHawks Audit Contest
Cyfrin
DeFiFoundry
15,000 USDC
View results
Previous Next
Submission Details
Severity: medium
Valid

Public `burnFrom()` function can cause serious unintended behaviour of the system

warRoom

Summary

The burn() function in DecentralizedStableCoin.sol has onlyOwner() modifier indicating that it should only be called by DSCEngine.sol. According to this design, a owner of the token should not be allowed to burn the tokens by any other means than via DSCEngine.sol.

This design is challenged by the burnFrom() function in Openzeppelin's ERC20Burnable implementation as it is public by default.

Vulnerability Details

A malicious user can self-approve and use the burnFrom() functionality to burn his/her token.

function burnFrom(address account, uint256 amount) public virtual {
_spendAllowance(account, _msgSender(), amount);
_burn(account, amount);
}

It is important to note here that approve function of Openzeppelin ERC20 do allow self-approval. Hence, basically allowing users to burn directly.

function _approve(
address owner,
address spender,
uint256 amount
) internal virtual {
require(owner != address(0), "ERC20: approve from the zero address");
require(spender != address(0), "ERC20: approve to the zero address");
​
_allowances[owner][spender] = amount;
emit Approval(owner, spender, amount);
}

Impact

  1. Serious integration concerns. Any protocols/products building on top of DSCStablecoin might not have the idea of holders being able to burn DSC tokens directly and not via DSCEngine.

  2. The protocol remains in profit in these type of burn events - as the malicious user will incur the loss of his tokens/deposit. But it's safe to conclude that it is not the intended behaviour.

Tools Used

Manual Review

Recommendations

  • Override burnFrom() function with suitable access modifier via DSCEngine or revert the function - - as per system design decisions.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.