Burning of the user gas in the `sendCompressedBytecode` function
Opened this issue · 5 comments
Lines of code
https://github.com/code-423n4/2023-10-zksync/blob/1fb4649b612fac7b4ee613df6f6b7d921ddd6b0d/code/system-contracts/bootloader/bootloader.yul#L1244-L1245
https://github.com/code-423n4/2023-10-zksync/blob/1fb4649b612fac7b4ee613df6f6b7d921ddd6b0d/code/system-contracts/bootloader/bootloader.yul#L1255-L1259
https://github.com/code-423n4/2023-10-zksync/blob/1fb4649b612fac7b4ee613df6f6b7d921ddd6b0d/code/system-contracts/bootloader/bootloader.yul#L1365
https://github.com/code-423n4/2023-10-zksync/blob/1fb4649b612fac7b4ee613df6f6b7d921ddd6b0d/code/system-contracts/bootloader/bootloader.yul#L1562-L1579
https://github.com/code-423n4/2023-10-zksync/blob/1fb4649b612fac7b4ee613df6f6b7d921ddd6b0d/code/system-contracts/contracts/Compressor.sol#L54-L82
Vulnerability details
Description
In the bootloader::sendCompressedBytecode function the nearCallPanic() is used for the case of unsuccessfull call of the Compressor::publishCompressedBytecode function. In practice, such situation could happen because of invalid data provided by the operator, as any of the internal checks of this function could be ignored by the operator to make the call to revert: decoding of the _rawCompressedData (link), the checks on dictionary length (link1, link2), the check on the encodedData length (link), etc.
Such possibility of forcing the overall bootloader::ZKSYNC_NEAR_CALL_markFactoryDepsL2 to near call revert, makes the operator able to burn all the gas of the L2 transaction if there is at least one bytecode to be published at the start of transaction processing.
Impact
The ability of the operator to burn all the gas of the L2 transaction in the call of the bootloader::ZKSYNC_NEAR_CALL_markFactoryDepsL2 function, if at least one bytecode is to be published.
Recommended Mitigation Steps
Use revertWithReason instead of nearCallPanic for the cases of unsuccessful calls of the Compressor::publishCompressedBytecode function. The cases of out of gas error on such calls operator can process as standard bytecode publications through the bootloader::markFactoryDepsForTx functionality.
Assessed type
Other
141345 marked the issue as sufficient quality report
This has medium severity because it gives the operator the ability to forcefully fail the transaction.
miladpiri (sponsor) confirmed
GalloDaSballo marked the issue as selected for report
The finding is similar to #71, however in this case it shows how the Operator can break trust expectations by purposefully making tx fails via OOG