25917 - [SC - Insight] Timelock can call transferProxyOwnership of Dep...

Submitted on Nov 21st 2023 at 01:59:51 UTC by @said for Boost | DeGate

Report ID: #25917

Report type: Smart Contract

Report severity: Insight

Target: https://etherscan.io/address/0xf2991507952d9594e71a44a54fb19f3109d213a5#code

Impacts:

• Theft of funds from the Default Deposit Contract that requires malicious actions from the DeGate Operator.

• Permanent freezing of funds from the Default Deposit Contract that requires malicious actions from the DeGate Operator.

• Contract fails to deliver promised returns, but doesn't lose value

Description

Bug Description

It is mentioned that the goal of Timelock is to solve the trustless issue when DeGate need to modify the code and complete the upgrade. However, timelock is not restricted to execute transferProxyOwnership inside DepositContractProxy and ExchangeProxy.

Impact

This will allow Timelock to change proxy ownership, then the new owner can execute upgrade and modify code without trough the designed DeGate timelock process. Basically breaking trustless assumption and violating the new upgrade design.

https://github.com/degatedev/protocols/blob/180138015197c886ec3c87efa8bf0031b653359f/packages/loopring_v3/contracts/thirdparty/timelock/Timelock.sol#L63-L72

    function queueTransaction(address target, uint value, string memory signature, bytes memory data, uint eta) public returns (bytes32) {
        require(msg.sender == admin, "Timelock::queueTransaction: Call must come from admin.");
        require(eta >= getBlockTimestamp().add(delay), "Timelock::queueTransaction: Estimated execution block must satisfy delay.");

        bytes32 txHash = keccak256(abi.encode(target, value, signature, data, eta));
        queuedTransactions[txHash] = true;

        emit QueueTransaction(txHash, target, value, signature, data, eta);
        return txHash;
    }

It can be observed that queueTransaction allow any operation including transferProxyOwnership to DepositContractProxy and ExchangeProxy

Risk Breakdown

Difficulty to Exploit: Critical

Recommendation

Restrict the queueTransaction function inside Timelock by checking if it is providing transferProxyOwnership call to DepositContractProxy and ExchangeProxy. If yes, revert the operations

References

https://github.com/degatedev/protocols/commit/180138015197c886ec3c87efa8bf0031b653359f?utm_source=immunefi#commitcomment-132582143

https://github.com/degatedev/protocols/commit/180138015197c886ec3c87efa8bf0031b653359f?utm_source=immunefi#diff-83099129c62e972adeec76325e36fa907afaac960342ce8de1c451d033ac41ef

Proof of concept

PoC Scenario :

1. MultiSig create transferProxyOwnership via queueTransaction operation trough timelock process and providing non-timelock address.

2. All MultiSig owners sign the transaction and wait for the normal timelock time.

3. All MultiSig create executeTransactionfor the timelock operation and sign the transaction id.

4. The transferProxyOwnership is executed and proxy owner changed to non-timelock.

5. the new owner can change proxy implementation without any notice and delay and can break or steal funds from users.

Setup empty foundry, and run provided test in gist.

Note, to RUN the PoC, add the following to foundry.toml :

evm_version = "shanghai"