Nonce Management Bug in Ethermint Fork - Potential Vulnerability

[0xM3R]

Nonce Management Bug in Ethermint Fork - Potential Vulnerability

Description

The current implementation of stateDB.SetNonce(sender.Address(), msg.Nonce+1) in our Ethermint fork permanently modifies the sender’s nonce even for failed contract creations, leading to potential nonce mismatches in batched transactions. This deviation from standard Ethereum/Ethermint behavior may introduce a side-channel attack vector.

Vulnerability Reference

• Affected Code:
  state_transition.go#L400-L406
• Expected Behavior (Crons/Evmos Implementation):
  • The sender's nonce should be temporarily set to msg.Nonce during contract creation.
  • After contract creation, it should be restored to its original value (stateDB.SetNonce(sender.Address(), oldNonce)).
  • If contract creation fails, the sender's nonce should remain unchanged to prevent unintended nonce mismatches.

Current Ethermint Fork Behavior (Issue)

• Incorrect Handling of Nonce:
  • The nonce is permanently incremented (msg.Nonce+1), regardless of success or failure.
  • This can break the nonce sequence when multiple transactions are batched.
  • Batched transactions using LegacyTx are affected since the system assumes a continuous nonce sequence, but contract creation failures modify it incorrectly.

Potential Impact

• Nonce mismatch in batched transactions may lead to inconsistencies in transaction execution.
• Nonce forging vulnerability—incorrect nonce handling could lead to replay or transaction manipulation attacks.
• Possible side-channel attack—attackers might exploit predictable nonce sequences to infer transaction failures and forge invalid transactions.

Suggested Fix (Align with Cronos/Evmos)

• Implement correct nonce restoration after contract creation by:
  1. Temporarily setting stateDB.SetNonce(sender.Address(), msg.Nonce).
  2. Restoring stateDB.SetNonce(sender.Address(), oldNonce) after execution.
  3. Ensuring failed contract creations do not increment the nonce permanently.

Additional Notes

This issue was initially demonstrated by a security researcher who expected the nonce to be incremented four times (instead of two) in a batched transaction scenario. This suggests a real-world exploit potential.

Steps to Reproduce

1. Create a batched transaction with multiple contract creation calls using LegacyTx.
2. Observe the nonce behavior—check if it gets incremented incorrectly after a failed contract creation.
3. Compare behavior with Cronos/Evmos where nonce remains unchanged upon failure.

Impact Assessment

• Severity: Medium
• Type: Nonce Management, Side-Channel Attack Risk
• Affected Component: EVM State Transition in Ethermint Fork

Action Items

• Fix nonce restoration to match Cronos/Evmos.
• Test batched transactions for correct nonce behavior.
• Investigate potential security implications further.