Malicious operator can freeze users' bridged ERC20 tokens by appending transactions after the merkle tree is full

[c4-submissions]

Lines of code

https://github.com/code-423n4/2023-10-zksync/blob/1fb4649b612fac7b4ee613df6f6b7d921ddd6b0d/code/system-contracts/bootloader/bootloader.yul#L965-L966

Vulnerability details

Impact

In Boojum we’ll have to maintain this fact. Having the priority operations’ statuses is important to enable proving failed deposits for bridges.

However, the check for numberOfL2ToL1Logs is incorrect. As a result, malicious operator can append transaction even after the merkle tree is full. User will not be able to redeem failed deposits since the proof for the failed transaction is not included in the merkle tree.

Proof of Concept

Let's focus on function publishPubdataAndClearState of L1 messenger.

    require(numberOfL2ToL1Logs <= numberOfL2ToL1Logs, "Too many L2->L1 logs");

We are requiring nothing here. So numberOfL2ToL1Logs can be larger than 2048.

    uint256 nodesOnCurrentLevel = L2_TO_L1_LOGS_MERKLE_TREE_LEAVES;
    while (nodesOnCurrentLevel > 1) {
        nodesOnCurrentLevel /= 2;
        for (uint256 i = 0; i < nodesOnCurrentLevel; ++i) {
            l2ToL1LogsTreeArray[i] = keccak256(
                abi.encode(l2ToL1LogsTreeArray[2 * i], l2ToL1LogsTreeArray[2 * i + 1])
            );
        }
    }
    bytes32 l2ToL1LogsTreeRoot = l2ToL1LogsTreeArray[0];

Later, we simply ignore logs after 2049. They will not be reflected in the root hash.

Each time when function processL1Tx is called in bootloader, a log indicating transaction result will be sent.

            // Sending the L2->L1 log so users will be able to prove transaction execution result on L1.
            sendL2LogUsingL1Messenger(true, canonicalL1TxHash, success)

A malicious operator can wait patiently until the current pending priority transactions emit more than 2048 logs in total (operator can also do it herself!) After that, if a ERC20 deposit failed, operator conclude the batch and the failed deposit can never be redeemed, since the log is not included in the merkle tree.

Tools Used

Manual

Recommended Mitigation Steps

    require(numberOfL2ToL1Logs <= 2048, "Too many L2->L1 logs");

(It's better to have a dynamic tree here)

Assessed type

Context

[c4-pre-sort]

bytes032 marked the issue as low quality report

[c4-pre-sort]

141345 marked the issue as duplicate of #853

[c4-judge]

GalloDaSballo changed the severity to 2 (Med Risk)

[c4-judge]

GalloDaSballo changed the severity to QA (Quality Assurance)

[miladpiri]

While the attack scenario may not be fully correct (indeed more than 2048 is not possible to send on L1), the fix / the general issue is right. Low is fair.

[c4-sponsor]

miladpiri marked the issue as disagree with severity

[GalloDaSballo]

Maintaining QA and I believe that a checksum on hashes would prevent this from being exploited
If the warden wishes to have this looked at again they will have to send a coded POC of bypassing all security checks