Risk of Refund Loss During Upgrade Transactions

[c4-submissions]

Lines of code

https://github.com/code-423n4/2023-10-zksync/blob/main/code/contracts/ethereum/contracts/zksync/libraries/TransactionValidator.sol#L55

Vulnerability details

Impact

The absence of a mechanism to verify the control of the refund recipient may expose upgrade transactions to the risk of refund loss

Proof of Concept

In the case of an upgrade transaction, there is a risk of losing the refund because there is no mechanism in place to ensure that the refund recipient address is under the control of the governor or administrator.
https://github.com/code-423n4/2023-10-zksync/blob/main/code/contracts/ethereum/contracts/upgrades/BaseZkSyncUpgrade.sol#L181
https://github.com/code-423n4/2023-10-zksync/blob/main/code/contracts/ethereum/contracts/zksync/libraries/TransactionValidator.sol#L55

Since the msg.sender for upgrade transactions is the address of the Governance contract, it is essential that the refund recipient corresponds to the L1toL2Alias of the Governance contract to ensure proper control and governance over the refund.

Tools Used

Recommended Mitigation Steps

The check on line 55 should be as follows:

require(_transaction.reserved[1] == applyL1ToL2Alias(msg.sender), "uf"); 

https://github.com/code-423n4/2023-10-zksync/blob/1fb4649b612fac7b4ee613df6f6b7d921ddd6b0d/code/contracts/ethereum/contracts/zksync/libraries/TransactionValidator.sol#L55

Assessed type

Context

[c4-pre-sort]

141345 marked the issue as sufficient quality report

[miladpiri]

More of a process issue than system contracts bug. So, QA.

[c4-sponsor]

miladpiri marked the issue as disagree with severity

[c4-sponsor]

miladpiri (sponsor) acknowledged

[c4-judge]

GalloDaSballo changed the severity to QA (Quality Assurance)