26501 - [SC - Insight] Timelock should handle queuing transactions and...
Previous26479 - [SC - Insight] ExchangeV cannot be reinitialized after an upgradeNext26502 - [SC - Insight] DeGate Exodus mode forcing study
Last updated
Was this helpful?
Last updated
Was this helpful?
Submitted on Dec 4th 2023 at 04:58:15 UTC by @conqueror for
Report ID: #26501
Report type: Smart Contract
Report severity: Insight
Target: https://etherscan.io/address/0xf2991507952d9594e71a44a54fb19f3109d213a5#code
Impacts:
Timelock should handle queuing deploys and initializing implementation contracts
Even if an unauthorized party was able to gain access to the Multisig, they should not be able to queue up transactions besides upgrade transactions (for example, ones changing the proxy ownership).
Furthermore, your implementation contracts are currently uninitialized. While this is not a concern at the moment, if you ever upgrade to an implementation contract that uses delegatecall in any way, this could become a big problem.
The timelock contract therefore should be in charge of:
Queueing up implementation contract deploys (you can set delay to 0 here), and calling initialize on the implementation contract
Only allow upgrade to be called on the proxy contracts, and not other functions. Do this by checking the signature.
Mitigate damage if multisig is ever compromised and initialize implementations. Not initializing implementations can be extremely bad in the future if you ever upgrade them to use delegatecall
Difficulty to Exploit: Easy Weakness: Low CVSS2 Score: L
Refactor the timelock contract a bit, as described above