zkSync Era - OffsideLabs's results

Lines of code

https://github.com/code-423n4/2023-10-zksync/blob/72f5f16ed4ba94c7689fe38fcb0b7d27d2a3f135/code/system-contracts/contracts/libraries/TransactionHelper.sol#L183-L187 https://github.com/code-423n4/2023-10-zksync/blob/72f5f16ed4ba94c7689fe38fcb0b7d27d2a3f135/code/system-contracts/contracts/DefaultAccount.sol#L78-L107

Vulnerability details

The L2 DefaultAccount.validateTransaction function and transaction encoding process in the bootloader do not enforce EIP-155. If the reserved[0] of the legacy tx is zero, the EIP-155 will be disabled. The chainId will not be included in the transaction signature.

        bytes memory encodedChainId;
        if (_transaction.reserved[0] != 0) {
            encodedChainId = bytes.concat(RLPEncoder.encodeUint256(block.chainid), hex"80_80");
        }

Impact

There are two potential exploitation scenarios:

1. A malicious attacker can replay transactions from the mainnet or other networks not protected by EIP-155. While there are very few EVM networks currently supporting transactions without EIP-155, attackers still have an opportunity to profit by replaying early transactions from other networks. For example, if an early ETH user A sent a legacy tx to user B before EIP-155 enabled, and now user A deposited some ETH into the Zksync era network, then user B could replay the early transaction from user A to steal his funds on the Zksync network.

2. Operators can replay early user transactions from eth/other EVM networks to collect gas fees or even profit directly.

Proof of Concept

EIP-155 will be disabled when the following two conditions are met:

1. transaction type is legacy tx, which tx_type=0 ;

2. tx.reserved[0] == 0

The value of the reserved field cannot be set arbitrarily, but if the user inputs a transaction with tx_type=0 and the v in the signature is 27 or 28, then reserved[0] will be set to 0.

Code: https://github.com/matter-labs/zksync-era/blob/6cb8c2c350385ed96c0824869a885a7285735a91/core/lib/vm/src/types/internals/transaction_data.rs#L52-L60

                let should_check_chain_id = if matches!(
                    common_data.transaction_type,
                    TransactionType::LegacyTransaction
                ) && common_data.extract_chain_id().is_some()
                {
                    U256([1, 0, 0, 0])
                } else {
                    U256::zero()
                };

    pub fn extract_chain_id(&self) -> Option<u64> {
        let bytes = self.input_data()?;
        let chain_id = match bytes.first() {
            Some(x) if *x >= 0x80 => {
                let rlp = Rlp::new(bytes);
                let v = rlp.val_at(6).ok()?;
                PackedEthSignature::unpack_v(v).ok()?.1?
            }

Tools Used

Manual review

Recommended Mitigation Steps

Enforce EIP-155 signature verification in the contract DefaultAccount.validateTransaction

Assessed type

Other

Lines of code

https://github.com/code-423n4/2023-10-zksync/blob/72f5f16ed4ba94c7689fe38fcb0b7d27d2a3f135/code/system-contracts/contracts/Compressor.sol#L54-L82

Vulnerability details

The _rawCompressedData parameter for Compressor.publishCompressedBytecode is currently provided directly by the operator and it represents the compressed bytecode, which should be published as “expensive” pubdata. But the publishCompressedBytecode function only check if the compressed data matchs with the original bytecode and bytecode hash. The only check for the length of _rawCompressedData is

require(dictionary.length <= 2 ** 16 * 8, "Dictionary is too big");

However, the check doesn't guarantee the compression ratio of the compressed bytecode. So a malicious operator submit a very long but valid dictionary to overcharge users gas, and even force users transactions to fail.

Impact

1. Malicious operators can overcharge users gas for the L2 transactions with FactoryDeps .

2. And since the publishCompressedBytecode function is called at the very beginning of bootloader.l2TxExecution , if a malicious operator exploits this vulnerability to consume all the gas passed into ZKSYNC_NEAR_CALL_markFactoryDepsL2, the normal transaction execution may be forced to fail due to out of gas.

Proof of Concept

The compressed bytecode is inputted directly from operator memory in the ZKSYNC_NEAR_CALL_markFactoryDepsL2 :

let dataInfoPtr := mload(COMPRESSED_BYTECODES_BEGIN_BYTE())

The operator can first compress the bytecode into the correct format and then pad the end of the dictionary with 0xff bytes that won't be used or checked, until the dictionary length reaches its maximum value of 2**19.

Tools Used

Manual review

Recommended Mitigation Steps

Check the compression ratio, the length of the compressed bytecode should not be greater than the original length.

Assessed type

Invalid Validation