Closed code423n4 closed 2 years ago
We are well aware of the permission structure. The owner will most likely be a large multisig. We mentioned the Frax Multisig in the scope too. If moving funds, it is assumed someone in the multisig would catch an invalid or malicious address.
Zero-address checks, should be QA?
closing as invalid, low quality.
Lines of code
https://github.com/code-423n4/2022-09-frax/blob/55ea6b1ef3857a277e2f47d42029bc0f3d6f9173/src/ERC20/ERC20PermitPermissionedMint.sol#L34 https://github.com/code-423n4/2022-09-frax/blob/55ea6b1ef3857a277e2f47d42029bc0f3d6f9173/src/OperatorRegistry.sol#L41
Vulnerability details
Impact
The timelock_address can be set to a zero address.
Proof of Concept
When
ERC20PermitPermissionedMint:constructor
is called, the_timelock_address
is not being checked for a zero address. See code snippet below. Thus if you pass in a zero address for the_timelock_address
, theERC20PermitPermissionedMint:constructor
will settimelock_address
to a zero address. The same applies to theOperatorRegistry:constructor
where_timelock_address
is also not being checked for a zero address. See code snippet below.Tools Used
None
Recommended Mitigation Steps
Check whether
_timelock_address
is a zero address inside theERC20PermitPermissionedMint:constructor
and inside theOperatorRegistry:constructor
.