Cowrie Research

trusted-execution-envelope-corruption

14 min read

Trusted Execution-Envelope Corruption / Internally Authenticated Context Overwrite

  • Name: trusted execution-envelope corruption / internally authenticated context overwrite
  • Category: exploit pattern / serialized-context corruption / settlement-envelope authenticity failure / pointer-arithmetic bug class
  • Summary: Some protocols assemble a trusted execution envelope in memory or calldata before handing control to another contract, parser, or callback path. The callee is then allowed to trust fields inside that envelope — the resolver, payer, token list, fee metadata, target, proof payload, or some other authenticated context — because the protocol itself is supposed to have authored or sealed them. This pattern fails when attacker-controlled length, offset, or pointer arithmetic lets the envelope be overwritten, misaligned, or reinterpreted before consumption. The downstream checks may all be locally correct, but they validate attacker-shaped context wearing protocol-authored clothes.
  • What it is:
    • A protocol builds a serialized blob that later code is supposed to trust more than raw user input.
    • The blob often mixes user-provided data with protocol-appended fields such as suffixes, authenticated metadata, settlement context, or proof wrappers.
    • The code that constructs or decodes that blob uses unsafe pointer math, length patching, offset calculation, or memory-layout assumptions.
    • An attacker causes the trusted fields to land in the wrong place, be read from the wrong place, or be overshadowed by a counterfeit structure.
    • A downstream contract, parser, or callback path then acts on forged-but-apparently-authenticated context.
  • Typical preconditions:
    • The protocol uses Yul, inline assembly, custom serialization, manual suffix/prefix patching, or other hand-rolled context assembly.
    • One or more decisive security fields are supposed to be protocol-authored rather than user-authored.
    • User-controlled lengths, offsets, nested payloads, or dynamic arrays influence where authenticated fields are written or later read.
    • Downstream logic trusts the protocol-authored envelope strongly enough to move funds, spend approvals, release custody, or authenticate a callback target.
    • The deprecated or low-traffic path carrying the bug remains live even after the ecosystem thinks it has moved on.
  • Common vulnerable surfaces:
    • settlement routers that append resolver, payer, token, or fee metadata to dynamic calldata before a callback or recursive fill
    • Yul/assembly code that copies calldata into memory, patches lengths, and appends suffixes or trailers manually
    • proof or message wrappers whose authenticated fields are assembled by pointer arithmetic rather than safer typed encoding
    • callback systems where the callee trusts that some outer contract already bound the target, payer, or route context correctly
    • legacy compatibility code whose serialized layout remains reachable but is no longer actively exercised by normal users
  • Exploit sequence:
    1. The attacker identifies a path where the protocol manufactures authenticated context instead of reading it directly from user calldata.
    2. They find user-controlled length, offset, or layout fields that influence where the authenticated context will be written or read.
    3. They craft padding, fake structures, wrapped arithmetic, or nested payloads so the trusted fields land in attacker-chosen memory / calldata positions.
    4. The protocol finishes constructing what it believes is a trusted envelope.
    5. A downstream decoder, callback path, or callee interprets attacker-controlled bytes as protocol-authenticated context.
    6. The callee moves funds, honors approvals, authenticates the wrong target, or releases other privileges under that forged context.
  • Variants:
    • Suffix overwrite / suffix relocation — appended fields such as resolver, payer, or fee metadata are written to the wrong location and later decoded as authoritative.
    • Prefix-length corruption — a patched dynamic-length field causes later decoding to absorb bytes that were never supposed to be part of the authenticated object.
    • Fake wrapper shadowing — attacker-supplied bytes are positioned so the decoder reads them instead of the protocol-appended structure.
    • Compatibility-path residue — the vulnerable serializer remains live only for an obsolete path, but funded integrations still trust it.
    • Typed-structure illusion — downstream logic relies on the shape of the decoded structure and never re-derives the underlying trusted facts independently.
  • Detection heuristics:
    • Ask which bytes in a serialized execution path are supposed to be protocol-authored truth rather than user-authored input.
    • Trace every attacker-controlled length and offset used before those bytes are written or decoded.
    • Review any ptr + offset + length style arithmetic in Yul / assembly as a possible authenticity boundary, not merely a memory-safety detail.
    • Look for decode paths where a callee trusts if this outer contract called me, the context must be genuine without independently recomputing the important facts.
    • Treat deprecated serializers and backward-compatibility adapters as live attack surfaces until no funded integration still accepts them.
  • Quick classifier against nearby settlement-callback families:
    • Stay here when the decisive break is the protocol itself meant to author the settlement context, but unsafe assembly / serialization let attacker-shaped bytes become that context before the downstream consumer used it.
    • Use callback-frame-truth-security-object when the callback source may be genuine and the bug is instead that one still-live in-flight execution frame leaked actor / target / stage authority across callbacks.
    • Use callback-origin-authentication-failure when the sharper question is instead did the downstream consumer trust the wrong pool / pair / callback sender? and the protocol-authored bytes were not themselves the main thing that got corrupted.
    • Use settlement-envelope-truth-security-object when the sharper question is the positive-design one: what exact counterparty / payer / asset / stage object should have stayed one authenticated envelope across the whole settlement path?
    • Use route-commitment-across-callback-frame-and-settlement-envelope when the sharper design task is end-to-end: how a router or solver should have kept one callback-stage object and one later settlement-stage envelope pinned across the same route lifecycle instead of trusting a loose execution is in progress story.
    • Use account-confusion-root-of-trust-substitution when the protocol first accepted the wrong root market / bank / jar / helper object before any protocol-authored execution envelope existed to corrupt.
  • Defenses:
    • Prefer typed ABI encoding or safer structured serialization over hand-built pointer arithmetic for security-critical envelopes.
    • Bound-check every user-controlled length and offset before using it to decide where authenticated fields are written or read.
    • Re-derive critical facts such as resolver, payer, target, token list, or route identity at the point of use instead of trusting a mutable serialized wrapper.
    • Minimize the number of downstream contracts that treat one upstream contract as a universal signer of contextual truth.
    • Sunset deprecated compatibility paths aggressively once successor versions are live.
    • Add tests that deliberately use wrapped lengths, overlapping dynamic regions, padding blocks, and nested fake structures to prove authenticated fields cannot be displaced.

Three execution-envelope promotions healthy systems should not collapse

  1. Some transaction-shaped or callback-shaped blob exists
    • A router, resolver, settlement helper, or callback path can hand around bytes that decode into payer, resolver, token, amount, route, or stage fields.
    • That only answers the narrow existence question: some plausible envelope-shaped object is present.
  2. That blob still counts as the canonical protocol-authored execution envelope
    • Healthy systems separately prove that the decisive fields downstream consumers trust are still the exact fields the protocol meant to author, at the exact offsets and parser version the design intended.
    • This is the promotion 1inch Fusion V1 collapsed: the consumer saw a valid-looking structure, but the bytes it treated as protocol truth were attacker-positioned rather than protocol-authored.
  3. That accepted envelope still deserves live settlement or spender authority right now
    • Even a correctly authored envelope should not automatically keep ordinary payer scope, inventory reach, destination freedom, or approval-consuming power under degraded, compatibility, or fallback conditions.
    • This is why serializer rollback and path disablement have to prove more than the bytes decode correctly again: defenders also need to know which still-live envelopes remain allowed to move funds, from which inventory buckets, and under what narrower authority budget.

What sound design looks like

  • A healthy settlement or callback path names one trusted execution envelope all the way through: who is paying, who is allowed to receive, what assets and amounts are in scope, what stage of execution is happening, and which bytes are protocol-authored rather than caller-authored. The strongest positive-design companion on that side is settlement-envelope-truth-security-object: this family is what breaks when that one envelope silently splits into bytes the protocol thinks it wrote and bytes the downstream consumer actually trusts.

  • Protocol-authored context should be fixed-boundary truth, not an emergent side effect of pointer arithmetic. If critical fields live in trailers, suffixes, or patched dynamic regions, a healthy design either encodes them in a typed fixed-layout object, hashes them separately, or otherwise binds them so attacker-controlled lengths cannot slide the trust boundary around. Healthy reviewers keep three separate answers in view: some blob exists, this blob is still the canonical protocol-authored envelope, and this accepted envelope still deserves live settlement authority.

  • Downstream consumers should distrust serialization success. A blob decoding cleanly is not evidence that the right actor authored the fields that matter. Healthy consumers either re-derive decisive facts at the point of use or assert cheap semantic invariants that would fail if the envelope were merely well-formed but counterfeit.

  • Mutable compatibility paths should fail closed before they become live trust roots. If a legacy serializer, deprecated resolver path, or low-traffic assembly helper still produces envelopes that funded integrations honor, healthy design treats that code like current custody code rather than historical baggage.

  • Envelope construction deserves the same review intensity as signature construction. In this family, the upstream serializer is effectively signing contextual truth for the downstream consumer, so length arithmetic, copy order, overlap assumptions, and decode boundaries need the same paranoia as cryptographic authorization logic.

  • The clean design question is: if a downstream contract later says I trusted this resolver / payer / route / asset context because the protocol told me to, what exact bytes made that statement true, and what prevented user-controlled layout from changing which bytes those were?

  • High-signal incidents:

    • resolver-substitution drain (2025-03-05) — Fusion V1 built a dynamic settlement suffix that resolvers were meant to trust, but attacker-controlled interactionLength underflowed the suffix write location, letting a fake interaction blob masquerade as protocol-authenticated resolver and token/amount context and drain TrustedVolumes.

  • Why this pattern matters:

    • Many smart-contract exploits are framed as missing checks in the victim contract. This pattern preserves the more uncomfortable cousin: the victim’s checks can all be locally right while the upstream contract quietly lies to it through corrupted serialization.
    • It also forces reviewers to treat low-level memory and calldata layout code as part of the protocol’s authenticity boundary, not just as gas-optimization plumbing.
    • The family matters more as protocols keep using hand-rolled Yul, custom settlement envelopes, and backward-compatibility serializers around high-value routing paths.

Failure-prevention checklist

  • Write down the exact execution-envelope truth object before writing code: which bytes are user instructions, which bytes are protocol-authored commitments, and which downstream component is allowed to trust each field. Force design review to answer three separate questions up front: what envelope-shaped object exists, what makes it the canonical protocol-authored one, and what live spender / settlement authority that accepted envelope is still allowed to exercise.
  • Treat every user-controlled length, offset, pointer, and nested dynamic region as an authenticity input, not just a parsing detail. If it can move where the trusted bytes land, it is part of the security boundary.
  • Prefer typed ABI encoding or a minimal fixed-layout struct for security-critical settlement context. If custom serialization is unavoidable, keep the authenticated portion fixed-width and separately hashed or length-delimited.
  • Recompute or rebind critical facts at the point of use — resolver, payer, token list, route id, counterparty, fee metadata, proof domain — instead of trusting that an upstream serializer preserved them intact.
  • Separate protocol-authored suffix/trailer from user-authored payload with explicit boundaries that cannot be widened by attacker-supplied length patching, wraparound arithmetic, or nested blobs.
  • Kill obsolete compatibility serializers quickly. A dusty envelope path that still reaches funded integrations is still a production trust root.
  • Add property tests and adversarial fixtures for underflow, overflow, overlap, aliasing, fake nested wrappers, zero-length edge cases, and maximum-length dynamic segments.
  • Require code review on every assembly / Yul block to answer a concrete question: what trusted field is being authored here, and what attacker-controlled value can still change where it will be read from later?
  • Instrument downstream consumers so they can reject impossible combinations of envelope fields rather than assuming the upstream constructor must have made them coherent.

Audit prompts

  • Which exact fields in this blob are supposed to be protocol-authored truth, and where is that trust assumption documented in code or design docs?
  • Can any attacker-controlled length, offset, or nested dynamic segment influence where those trusted fields are written, copied, or later decoded?
  • Does the serializer rely on ptr + len + offset style arithmetic anywhere, and what prevents wraparound, truncation, overlap, or shadowing into a different structure?
  • If the downstream consumer accepted a forged resolver / payer / target today, would that be because its local checks were missing, or because the upstream envelope constructor could be tricked into presenting counterfeit context as authenticated?
  • Are deprecated versions, compatibility shims, or low-traffic resolver paths still able to emit envelopes that funded integrations continue to honor?
  • Does any downstream contract independently recompute the critical facts it acts on, or is it effectively treating the upstream serializer as a universal signer for all execution context?
  • Can a fake nested blob, alternate ABI shape, or padded dynamic segment cause the decoder to read attacker bytes where the protocol believes it appended authenticated metadata?
  • Are there invariants the consumer could cheaply assert — expected caller, route hash, token pair, settlement stage, domain separator, amount direction — that would fail if the envelope were merely well-formed but semantically counterfeit?
  • What tests currently prove that malformed layouts fail closed instead of being reinterpreted as a different but still valid-looking envelope?
  • If this path were exploited in production, what is the emergency boundary: can the vulnerable serializer be disabled independently, or does the protocol have to halt the whole routing stack?

Lessons that should already be standard

  • Serialization code is authority code. Once downstream components trust bytes because the protocol wrote them, pointer math becomes part of the access-control surface. The dangerous collapse is treating some bytes exist, those bytes are protocol truth, and those bytes still deserve live settlement authority as one event.
  • A consumer can be perfectly strict and still be exploitable if the producer can be tricked into minting counterfeit context that passes all of the consumer’s checks.
  • Assembly only touches layout is a dangerous myth. In high-value routing systems, layout decides authorship.
  • Dynamic trailing metadata is especially fragile when user-controlled lengths decide where that trailer begins. If the suffix can slide, the trusted truth can be replaced.
  • Compatibility paths deserve the same paranoia as flagship flows. Attackers love the serializer everyone assumes no one uses anymore.
  • The right question is not only did decoding succeed? but did the same actor author the bytes this decoder is about to trust?
  • Typed, fixed-boundary encodings are usually cheaper than an exploit. Gas wins from bespoke envelope assembly rarely justify authenticity risk on spender or custody paths.
  • If downstream logic cannot cheaply re-derive the important facts, upstream construction must be treated like signing; review it with the same paranoia as signature creation.

Internal linkages

  • Positive-design companion: settlement-envelope-truth-security-object — the settlement-side checklist for what exact counterparty, payer, asset semantics, execution stage, and protocol-authored bytes should have remained one trusted object before any downstream resolver or callback consumer acted.
  • Adjacent callback-frame companion: callback-frame-truth-security-object — use this when the decisive bug is not corrupted protocol-authored settlement bytes, but stale actor / target / stage authority leaking across a real callback path.
  • Adjacent pattern: callback-origin-authentication-failure — both families let a downstream settlement path trust the wrong context, but that note is about spoofed callback origin and route binding while this one is about corruption of the protocol-authored envelope the callback consumes.
  • End-to-end routing companion: route-commitment-across-callback-frame-and-settlement-envelope — use this when the design question is not only what envelope should have stayed authentic? but how should callback-stage truth and settlement-stage truth have remained one route lifecycle without collapsing into ambient state?
  • Adjacent pattern: account-confusion-root-of-trust-substitution — both families authenticate the wrong object, but that note centers on caller-supplied counterfeit root objects whereas this one centers on corrupted serialization of an object the protocol meant to author itself.
  • Adjacent pattern: release-provenance-failure — both involve a divergence between what was reviewed / intended and what was actually consumed, but release-provenance failure lives in build and distribution pipelines rather than in live execution-context assembly.
  • Best current exemplar: 1inch-fusion-v1-settlement-yul-calldata-corruption-resolver-substitution-drain-2025-03-05.

Control surface

Graph View

Backlinks