Frontier Modexp Precompile Denial of Service via Gas Underpricing

Frontier serves as the Ethereum compatibility layer for Substrate-based blockchains, enabling them to run unmodified Ethereum Virtual Machine (EVM) contracts. A critical component of the EVM is the set of precompiled contracts located at specific addresses, which handle computationally intensive operations natively rather than in EVM bytecode. Address 0x00...05 corresponds to the modular exponentiation (modexp) precompile.

In affected versions of Frontier, the modexp implementation relies on the Rust num-bigint crate to perform the underlying mathematical calculations. The vulnerability stems from a discrepancy between the gas cost charged by the EVM and the actual computational resources required by num-bigint to execute the operation. Specifically, the gas cost formula treated all moduli uniformly, ignoring significant performance differences based on the parity of the modulus.

This misalignment allows an attacker to craft transactions using large, even moduli that trigger a worst-case performance path in the underlying library. Because the gas cost is calculated based on an optimized path, the transaction remains cheap to execute on the network but expensive for the physical hardware, leading to a Denial of Service (DoS) condition.

The root cause lies in the algorithmic implementation of modular exponentiation within the num-bigint crate and Frontier's failure to model its performance characteristics accurately. Modular exponentiation ($B^E \mod M$) is optimized in num-bigint using Montgomery Reduction when the modulus $M$ is odd. Montgomery Reduction replaces expensive division operations with efficient bit shifts and multiplications, resulting in highly performant execution.

However, when the modulus $M$ is even, num-bigint cannot use Montgomery Reduction. Instead, it falls back to a standard "plain power" algorithm, typically exponentiation by squaring combined with standard division-based reduction. Standard division is significantly more CPU-intensive than the operations used in Montgomery reduction.

Frontier's calculate_gas_cost function determined the transaction fee based solely on the bit lengths of the base, exponent, and modulus. It did not check the modulus value itself. Consequently, it assigned the same gas cost to calculations involving even moduli as it did to those involving odd moduli, despite the former being orders of magnitude slower to compute. This created an "Algorithmic Complexity" vulnerability (CWE-407) where the resource consumption was not proportional to the input size metric used for billing.

The vulnerability existed in frame/evm/precompile/modexp/src/lib.rs. The fix involves modifying the gas calculation logic to penalize operations involving even moduli. The developers introduced a heuristic multiplier to align the gas cost with the increased computational time.

Below is the logic before and after the patch:

Vulnerable Code (Conceptual):

fn calculate_gas_cost(..., mod_length: u64, ...) -> u64 {
    // Standard gas calculation based on input length
    // Complexity assumes optimized Montgomery reduction
    math::calculate_standard_cost(mod_length, ...)
}

Patched Code (Commit 5af12e9):

fn calculate_gas_cost(
    // ... existing parameters ...
    mod_is_even: bool, // New parameter to check parity
) -> u64 {
    let standard_cost = math::calculate_standard_cost(...);
    
    // Apply a 20x multiplier if the modulus is even
    // saturating_mul ensures the value doesn't wrap on overflow
    standard_cost.saturating_mul(if mod_is_even { 20 } else { 1 })
}

The patch specifically targets the mod_is_even condition. By multiplying the gas cost by 20, the developers effectively de-incentivize the attack vector. While this is a heuristic rather than a precise measurement of the underlying algorithm's complexity, it raises the cost of attack sufficiently to mitigate the DoS risk in the short term. The long-term solution suggested by the maintainers involves migrating to a constant-time cryptographic library that handles both cases efficiently.

To exploit this vulnerability, an attacker does not need special privileges or access to the node's configuration. The attack is performed entirely via the standard Ethereum JSON-RPC interface or by submitting signed transactions to the p2p network.

Attack Scenario:

1. Preparation: The attacker generates a payload for the modexp precompile (address 0x05). The payload consists of a large Base, a large Exponent, and a large Even Modulus (e.g., a 2048-bit number ending in 0).
2. Submission: The attacker submits a transaction containing this payload to the network. The gas limit is set according to the standard (low) estimation provided by the unpatched Frontier node.
3. Execution: When the validator nodes execute this transaction, they pass the inputs to num-bigint. Detecting the even modulus, the library enters the slow division-based reduction loop.
4. Impact: The validator thread hangs on this calculation for a duration disproportionate to the gas limit. If the attacker chains multiple such calls in a single transaction or block, they can stall block production or validation, causing network latency or consensus failure.

The primary impact of CVE-2023-28431 is Denial of Service (DoS). By stalling the block execution process, an attacker can prevent the network from finalizing blocks in a timely manner. In a permissionless blockchain context, this is a high-severity issue because it directly affects the availability and liveness of the network.

CVSS v3.1 Analysis:

• Score: 7.5 (High)
• Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
• Availability (H): High impact, as the primary function of the node (processing blocks) is interrupted.
• Confidentiality/Integrity (N): The vulnerability does not allow data exfiltration or state corruption, only resource exhaustion.

While the vulnerability is severe for availability, it does not allow for remote code execution or privilege escalation. The scope is limited to the node's execution runtime.