Full Report
Scroll is a ZK EVM blockchain. Recently, they made some changes to the code that led to some pretty serious issues. One via an individual and another through Immunefi by a user named WhiteHatMage. The first bug was a soundness issue in the zkEVM circuit for the auipc opcode. This function used an iterator that skipped the first element. That led to the bits of the PC being ranged checked to 8-bits instead of 6-bits. This would have allowed a malicious prover to fill in arbitrary values in the higher 2 bits of the PC, changing the flow of execution. Any ZK soundness issue is bad but the exploitable impact is unknown. Since the prover and sequencer are operated by Scroll, this is unexploitable though. The fix for this vulnerability is literally swapping the order of skip(1) and enumerate(). Neat! The second vulnerability was a message spoofing issue on the bridge. For the Euclid phase-2 update, they made some big changes and had a full audit done that did not uncover the issue. From being in a Discord with the author of the bug, they had automation setup to notify them of changes to contracts on Scroll. While reviewing this, hours after release, they immediately saw the issue. When going from an L1, like Ethereum to an L2 such as Scroll, there is typically a bridge in between them. When going between the L2 and the L1, there was an application-level permission issue that had not been noticed. On one end of the bridge, there was an authorization check. By crafting a malicious withdraw on the L2 to the L1, the L1ScrollMessenger entity permission could be abused to make a call back into the main bridge. Since this caller is considered trusted on L2ScrollMessenger, access controls on the L2 could be bypassed, leading to an infinite mint. This was effectively a confused deputy problem. This wasn't exploitable in the past because EnforcedTxGateway did not allow calls from smart contract accounts. With the change to the code, this property was changed though. Hence, it was possible to trigger this path. The explanation is somewhat short and without context so I don't fully understand the bug though. As more details come out, I'll try to update. Overall, two good bugs! The second one led to a 1M payout because of the damage it could have caused; monitoring for the win. It's fascinating the stark difference between the Scroll DoS from last week and this second crazy vulnerability.
Analysis Summary
# Vulnerability: Scroll zkEVM Soundness Issue (auipc Opcode Skipping)
## CVE Details
- CVE ID: Not specified in the context.
- CVSS Score: Not specified in the context. Unexploitable impact noted.
- CWE: Could relate to CWE-190 (Integer Overflow or Wraparound) or CWE-824 (Improper Access of Index or Boundary).
## Affected Systems
- Products: Scroll zkEVM Circuitry / `auipc` opcode implementation.
- Versions: Unspecified, present before the deployment of the fix.
- Configurations: Circuits handling the `auipc` instruction execution trace.
## Vulnerability Description
A soundness issue was identified in the zkEVM circuit related to the `auipc` opcode. The function responsible for checking the Program Counter (PC) used an iterator that incorrectly skipped the first element (`skip(1)` applied before `enumerate()`). This logic error caused the bits of the PC to be range-checked against an 8-bit constraint instead of the correct 6-bit constraint. This flaw would have allowed a malicious prover to supply arbitrary values in the two higher bits of the PC, potentially leading to unauthorized changes in the flow of execution within the validity proof generation.
## Exploitation
- Status: Not exploitable by external actors.
- Complexity: Medium (Requires ability to generate a faulty ZK proof).
- Attack Vector: Proof Generation Channel.
**Note on Exploitation:** Since both the prover and the sequencer are operated by Scroll (implying a centralized or controlled setup during this phase), the direct execution impact of generating a faulty validity proof is currently contained and unexploitable by external users.
## Impact
- Confidentiality: Unknown (Dependent on successful exploitation pathway).
- Integrity: Potentially Critical (Compromise of ZK Soundness).
- Availability: Unknown.
## Remediation
### Patches
- Logic fix involved swapping the order of `skip(1)` and `enumerate()` in the PC checking function. (Specific version information for the patched release is not provided).
### Workarounds
- None specified, although centralized operation of Prover/Sequencer acts as a temporary mitigation against public exploitation.
## Detection
- Detection would require deep review of ZK circuit logic, specifically range checks related to PC handling during `auipc` instruction processing.
## References
- [Based on the provided context, no external advisories or links are available.]
---
# Vulnerability: Scroll Bridge Message Spoofing (Confused Deputy Leading to Infinite Mint)
## CVE Details
- CVE ID: Not specified in the context.
- CVSS Score: High (Indicated by $1M payout for potential damage).
- CWE: CWE-284 (Improper Access Control) or CWE-918 (Server-Side Request Forgery - analogous to a confused deputy over a trusted channel).
## Affected Systems
- Products: Scroll L2 <-- L1 Bridge mechanism (Euclid Phase-2 changes).
- Versions: Versions deployed after the Euclid phase-2 update that enabled smart contract callers at the EnforcedTxGateway level.
- Configurations: Bridge operation between L2 (Scroll) and L1 (e.g., Ethereum) where an L1 permission check interacts with L2 message handling.
## Vulnerability Description
This was an application-level permission issue on the L2-to-L1 bridge, manifesting as a confused deputy problem during the withdrawal phase. A recently introduced code change altered the behavior of the `EnforcedTxGateway` such that it began allowing calls originating from smart contract accounts, which was not the case previously.
By crafting a malicious withdrawal transaction on L2 targeting L1:
1. The attacker initiated a withdrawal path.
2. The L1 entity (`L1ScrollMessenger`) was erroneously called/abused.
3. Because the caller's path originated from the L2 side (via the bridge interaction), the L2 side (`L2ScrollMessenger`) treated this return/callback as originating from a trusted entity, bypassing necessary L2 access controls.
4. This bypass allowed an attacker to invoke functions that resulted in an **infinite mint** of assets on the L2 (or controlled assets being moved improperly).
## Exploitation
- Status: Vulnerability disclosed via bug bounty program; assumed contained before widespread exploitation.
- Complexity: High (Requires understanding of the cross-chain messaging/bridge sequence).
- Attack Vector: Network (Via crafted L2 transaction).
## Impact
- Confidentiality: Low.
- Integrity: Critical (Risk of infinite minting/asset inflation).
- Availability: Low.
## Remediation
### Patches
- Patches deployed to correct the application-level permissioning issue that allowed the trusted execution path to be abused by a malicious L2 withdrawal call. (Specific version information is not provided).
### Workarounds
- None specified, an immediate fix was likely required due to the severity.
## Detection
- Monitoring L1 bridge callbacks/inbound messages for unexpected or unauthorized sequences originating from the L2 side that trigger minting functions.
- Auditing access controls immediately following code execution changes related to `EnforcedTxGateway` modifications.
## References
- Reportedly resolved via a $1M bug bounty payout to WhiteHatMage.
- [Based on the provided context, no external advisories or links are available.]