Skip to content
This repository has been archived by the owner on Jul 10, 2023. It is now read-only.

Incorrect Depth Calculation for Extension Nodes Allows Denial of Service

Critical
ed255 published GHSA-6m99-mxg3-pv9h Jul 10, 2023

Package

mpt.yul (Solidity)

Affected versions

*

Patched versions

None

Description

https://github.com/privacy-scaling-explorations/zkevm-chain/blob/master/contracts/templates/mpt.yul#L24

During verification, the mpt library walks down the inclusion proof to verify that hashes match as expected. However, when encountering an extension node in the account of storage proof, the library incorrectly computes the depth by adding the length in bytes to the depth, which is counted as the number of nibbles (half-bytes), as well as not accounting for the path length parity.

For example, if the extension node ['13 f4 a7', next_hash] was encountered, the 1 would indicate that it is an extension node with an odd path length. The correct path length to be added to the depth would be 5, but the library incorrectly adds 3 to the depth by getting the length in bytes. More concretely, due to an extension node in the account or storage proof, it is impossible to prove that the storage slot 0 of address 0x0068cf6ef4fdf5a95d0e2546dab76f679969f3f5 contains the value 2 on Ethereum mainnet.

This error leads to valid proofs not being accepted by the mpt library. An attack can make use of this behavior by forcing an extension node in the account or storage proof and thereby DoS-ing the system. An attacker can take advantage of this by brute-forcing an address on L1 via CREATE2 that has a hash collision in the first nibbles with the hash of the L1 contract address. Hence, an extension node is forced to appear in the state trie, thereby preventing any message to be replayed on L2 - a denial-of-service attack - potentially locking users' funds until the contract is upgraded.

Consider fixing the length calculation for extension nodes to accept valid proofs. It is advised to test the library and integration more thoroughly, for instance with a differential fuzzing approach and integration tests.

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

CVE ID

No known CVE

Weaknesses

No CWEs

Credits