Lucene search

K
code423n4Code4renaCODE423N4:2023-03-ZKSYNC-FINDINGS-ISSUES-147
HistoryMar 19, 2023 - 12:00 a.m.

Default accounts cannot pay transaction fees due to DefaultAccount not calling MsgValueSimulator

2023-03-1900:00:00
Code4rena
github.com
8
default account
transaction fees
zksync

Lines of code

Vulnerability details

Impact

Default accounts cannot pay the transaction fees to the bootloader. It’s not clear whether the attempts to do so will silently succeed or revert because the behaviour of the CALL opcode in the zkSync Era virtual machine isn’t explained in the description of the project.

Proof of Concept

As per the description of the project:

> Unlike Ethereum, zkEVM does not have any notion of any special native token. That’s why we have to simulate operations with Ether via two contracts: L2EthToken & MsgValueSimulator.

Also:

> L2EthToken is a contract that holds the balances of ETH for the users. […] The only method for transferring Ether is transferFromTo. It permits only some system contracts to transfer on behalf of users. This is needed to ensure that the interface is as close to Ethereum as possible, i.e. the only way to transfer ETH is by doing a call to a contract with some msg.value. This is what MsgValueSimulator system contract is for.

DefaultAccount is the default implementation of the Account Abstraction protocol: all EOAs on zkSync Era will use it as their default account implementation. The contract implements payForTransaction intended to pay transaction fees on behalf of the user. The method calls TransactionHelper.payToTheBootloader to pay a transaction fee, however payToTheBootloader uses the CALL opcode to make the payment. As per the description cited above, this should not work because the only way to transfer ETH on zkSync Era is by calling L2EthToken.transferFromTo via MsgValueSimulator.

Unfortunately, the description of the project doesn’t explain how transferring msg.value via the low-level CALL opcode works on the virtual machine of zkSync Era. But, according to the description of the L2EthToken and MsgValueSimulator contracts, it shouldn’t work at all.

It’s also likely that this was thoroughly tested since paying transaction fees is a crucial feature of the AA protocol. And it could be so that the testing environment didn’t fully replicate the behaviour of the virtual machine, letting transferring of ETH via the CALL opcode pass.

Tools Used

Manual preview

Recommended Mitigation Steps

Consider calling the MsgValueSimulator system contract to pay transaction fees in the TransactionHelper.payToTheBootloader functions.


The text was updated successfully, but these errors were encountered:

All reactions