convex-testing-interface
Safe HaskellSafe-Inferred
LanguageHaskell2010

Convex.ThreatModel.LargeData

Description

Threat model for detecting Large Data Attack vulnerabilities.

A Large Data Attack exploits permissive FromData parsers in Plutus validators that ignore extra fields when deserializing Constr data. If a validator's datum parser only checks the fields it expects and ignores additional ones, an attacker can "bloat" the datum with extra fields while preserving the validator's interpretation.

Consequences ==

  1. Increased execution costs: Processing bloated datums wastes CPU/memory execution units, making transactions more expensive.
  2. Permanent fund locking: If the datum is bloated sufficiently:
  • Deserializing the datum may exceed execution unit limits
  • The transaction required to spend the UTxO may exceed protocol size limits

In these cases, the UTxO becomes permanently unspendable and funds are locked forever with no possibility of recovery.

Root Cause ==

unstableMakeIsData and makeIsDataIndexed generate parsers that use wildcard patterns for constructor fields:

case (index, args) of
  (0, _) -> MyConstructor  -- The "_" ignores ALL extra fields!

This means Constr 0 [] and Constr 0 [junk1, junk2, ..., junk10000] both parse to the same value, allowing attackers to inject arbitrary data.

Mitigation ==

A secure validator should either:

  • Use strict manual FromData instances that check field count exactly
  • Validate the datum hash matches an expected value
  • Check datum structure explicitly in the validator logic

This threat model tests if a script output with an inline datum still validates when additional fields are appended to the datum's Constr data structure. If it does, the validator has a Large Data Attack vulnerability.

Synopsis

Documentation

largeDataAttack :: ThreatModel () Source #

Check for Large Data Attack vulnerabilities with 1000 extra fields.

This is the default configuration that appends 1000 extra ScriptDataNumber 42 fields to any inline datum on a script output. If the transaction still validates, the script's datum parser is permissive and vulnerable.

largeDataAttackWith :: Int -> ThreatModel () Source #

Check for Large Data Attack vulnerabilities with a configurable number of extra fields.

For a transaction with script outputs containing inline datums:

  • Try bloating the datum by appending n extra fields
  • If the transaction still validates, the script doesn't strictly validate its datum structure - it only checks expected fields and ignores extras.

This catches a vulnerability where different parsers may interpret the same on-chain data differently, leading to potential exploits.

bloatData :: Int -> ScriptData -> ScriptData Source #

Bloat a ScriptData value by appending extra fields to a Constr.

For ScriptDataConstructor idx fields, appends n copies of ScriptDataNumber 42 to the fields list.

For other ScriptData variants (Map, List, Number, Bytes), returns the value unchanged since they don't have the Constr structure that typical FromData instances parse.