Open code423n4 opened 1 year ago
0xSorryNotSorry marked the issue as high quality report
0xSorryNotSorry marked the issue as duplicate of #709
Picodes marked the issue as duplicate of #703
Picodes marked the issue as not a duplicate
Picodes changed the severity to QA (Quality Assurance)
Picodes marked the issue as grade-a
This previously downgraded issue has been upgraded by Picodes
Picodes changed the severity to QA (Quality Assurance)
Lines of code
https://github.com/code-423n4/2023-03-asymmetry/blob/44b5cd94ebedc187a08884a7f685e950e987261c/contracts/SafEth/SafEth.sol#L182
Vulnerability details
Impact
If SafEth.addDerivative() is called with an invalid derivative contract address, all users' staked ETH will be frozen, and contract SafEth will be completely unusable.
Proof of Concept
When adding a new derivative contract through SafEth.addDerivative(), passing an invalid derivative contract address (such as the 0 address, an EOA account address, or any other non-derivative address) will make the following functions unusable:
stake()
will be unusable because L73 will revert.unstake()
will be unusable because L115 will revert.rebalanceToWeights()
will be unusable because L141 will revert.Therefore, all users will not be able to stake any more and will not be able to unstake/withdraw their previously staked assets.
What is more serious is that even setting the weight of the invalid derivative contract to 0 will not fix this problem.
Test code for PoC:
Test outputs:
Tools Used
VS Code
Recommended Mitigation Steps
Due to the severity of the consequences caused by this issue, we must perform strict checks and validations on the
addDerivative()
.We can avoid this problem as much as possible by using EIP-165.
All derivative contracts (Reth, SfrxEth, WstEth) should inherit from ERC165, and
supportsInterface()
should be called when adding a new derivative to make sure the new derivative contract implements the IDerivative.sol interface.