Full Report
zksync is a zero knowledge (ZK) project that was building out a ZK EVM. The contest had 1.1M in rewards. The winner Winnie had never touched ZK stuff before but decided to ramp up on it before the event. I purposely didn't do this because I thought that the competition would have too many specialist but I was wrong about that! ZK logic uses arithmetic circuits which act as gates with logic similar to binary logic in traditional computers. The circuits must be implement this strictly otherwise there may be more than one correct answer, which is unacceptable for a EVM execution. On the div operation the circuit wasn't constrained enough. There is a missing check on the result of the subtraction. This means that the division with a smart contract could be given an incorrect result, which is awful. The exact same missing constraint exists on shr as well. The lack of constraints is a very common critical vulnerability within ZK systems. This was done with log emitting, AND, OR and out of bounds memory reads as well. For the AND and OR values, the constraint only must be less than 128. For XOR, there is an integer truncation bug that leads to the same affect. The final high finding is a denial of service via an unprovable via an over constrained circuit. If a dividend is nonzero and the divisor is zero, the quotient and remainder are both zero. Interesting that BOTH the over and under constraints are bad. There are also a plethora of medium severity and low findings. Many of these are wrong values or differing implementations between the EVM and the zEVM. These are worth reading but there are too many to make notes about.
Analysis Summary
# Vulnerability: Critical Constraint Omissions in zkSync Era Arithmetic Circuits
## CVE Details
- **CVE ID**: N/A (Web3/Smart Contract Audit Finding)
- **CVSS Score**: 9.1 (Calculated estimate) (**Critical**)
- **CWE**: CWE-685 (Function Call with Incorrect Number of Arguments / Incorrect Constraint Validation)
## Affected Systems
- **Products**: zkSync Era (Zero-Knowledge Rollup)
- **Versions**: Protocol state as of October 2023 Code4rena contest.
- **Configurations**: Implementations of the zkEVM arithmetic circuits, specifically the `div`, `shr`, `binop`, and `log sorter` modules.
## Vulnerability Description
The vulnerability stems from **under-constrained arithmetic circuits**. In ZK-SNARKs, logic must be strictly defined via polynomial constraints to ensure only one valid solution exists. Several high-severity findings revealed a failure to strictly constrain circuit outputs:
1. **`div` and `shr` Opcodes**: A missing range constraint on the remainder check allowed for incorrect division results. Because the subtraction was not constrained, a prover could provide a "fake" result that satisfies the basic equation but uses an incorrect quotient/remainder.
2. **Logic Gates (AND/OR/XOR)**: Constraints for AND/OR only ensured values were less than 128, failing to enforce bitwise correctness. The XOR implementation suffered from an integer truncation bug.
3. **Memory & Logs**: The `log sorter` failed to prevent attackers from manipulating queues to emit reverted logs. Additionally, the `skip_if_legitimate_fat_ptr` logic allowed for forging arbitrary memory read values due to insufficient validation of fat pointers.
## Exploitation
- **Status**: PoC available (submitted via Code4rena audit).
- **Complexity**: High (Requires deep knowledge of ZK circuit arithmetic and witness generation).
- **Attack Vector**: Network (Malicious transactions executed on the zkEVM).
## Impact
- **Confidentiality**: None reported.
- **Integrity**: **High**. Attackers could potentially manipulate the execution state of smart contracts, forge logs, or produce incorrect calculation results that are accepted by the ZK-prover.
- **Availability**: **High**. The `Mul/div` relation issue (H-06) could lead to unprovable batches, effectively creating a Denial of Service (DoS) for the rollup if specific mathematical conditions are met.
## Remediation
### Patches
- The vulnerabilities were addressed following the Code4rena audit (February 2024 report). Developers must ensure they are using the updated circuit definitions and bootloader configurations provided by the zkSync team (Matter Labs).
### Workarounds
- No manual workarounds exist for end-users; the security of the system relies entirely on the correctness of the circuits deployed by the operator and verified by the L1 settlement contract.
## Detection
- **Indicators of Compromise**: Discrepancies between expected EVM execution and zEVM state transitions.
- **Detection Methods**: Formal verification of arithmetic circuits and differential testing between the zkEVM implementation and standard EVM (Geth/Hardhat).
## References
- Code4rena Audit Report: [https://code4rena.com/reports/2023-10-zksync](https://code4rena.com/reports/2023-10-zksync)
- zkSync Era Documentation: [https://era.zksync.io/docs/](https://era.zksync.io/docs/)
- Finding H-01 Github: [https://github.com/code-423n4/2023-10-zksync-findings/issues/1117](https://github.com/code-423n4/2023-10-zksync-findings/issues/1117)