Closed code423n4 closed 1 year ago
There is no need to track the msg.sender
.
miladpiri marked the issue as sponsor disputed
I have to agree with the sponsor that no vulnerability was demonstrated
I will downgrade to QA because the observation can be viewed as a refactoring
R
GalloDaSballo changed the severity to QA (Quality Assurance)
GalloDaSballo marked the issue as grade-c
Lines of code
https://github.com/code-423n4/2023-03-zksync/blob/main/contracts/BytecodeCompressor.sol#L62 https://github.com/code-423n4/2023-03-zksync/blob/main/contracts/L1Messenger.sol#L49 https://github.com/code-423n4/2023-03-zksync/blob/main/contracts/libraries/SystemContractHelper.sol#L48
Vulnerability details
Impact
Users can use
BytecodeCompressor.publishCompressedBytecode()
to publish compressed bytecode on the L1. However,L1Messenger.sendToL1
usesmsg.sender
as sender in the L2->L1 log. In other words, the sender of all the compressed bytecodes published throughBytecodeCompressor.publishCompressedBytecode()
isBytecodeCompressor
instead of the real sender.Proof of Concept
When a user calls
BytecodeCompressor.publishCompressedBytecode()
, it would call L1_MESSENGER_CONTRACT.sendToL1(_rawCompressedData); https://github.com/code-423n4/2023-03-zksync/blob/main/contracts/BytecodeCompressor.sol#L62Then,
L1Messenger.sendToL1
calls SystemContractHelper.toL1 usingmsg.sender
as the sender of the message. https://github.com/code-423n4/2023-03-zksync/blob/main/contracts/L1Messenger.sol#L49Then the sender of the compressed bytecode becomes
BytecodeCompressor
.Tools Used
Manual Review
Recommended Mitigation Steps
There could be multiple methods to fix the issue. One is adding a new function in
L1Messenger
. The function takes a custom sender. And the function can be only called byBytecodeCompressor