End-to-End Audit of SecondFi's recovery flow

Description. The destination-bound ownership proof commits to the affected credential and the 58-byte destination-address-v1 encoding, but not to the destination output’s datum or reference script (circuit.go:57-70):

preimage = append(preimage, domain...)
preimage = append(preimage, credential[:]...)
preimage = append(preimage, destination[:]...)
digest := hash.Blake2b(api, uapi, preimage, 32)

Correspondingly, ReclaimGlobalV2 reconstructs the destination from the output’s address field alone (ReclaimGlobalV2.hs:376-382) and checks its value and proof without inspecting the datum (ReclaimGlobalV2.hs:575-611). A valid proof therefore remains valid if a transaction builder keeps the same destination address and value but substitutes the datum while constructing the recovery output.

This matters only for a script payment address whose spending rules use the datum to select a beneficiary or other spending authority. The refund frontend accepts enterprise addresses as destinations (destinationAddressV1.ts:137-145) and encodes a script payment credential using tag 0x02 (destinationAddressV1.ts:173-184).

A datum already attached to an existing UTxO cannot be modified. The substitution described here occurs before the recovery output is created.

Impact. Key payment destinations are unaffected. Exploitation requires a script payment destination whose spending authority depends on its datum, plus control over transaction construction and access to the valid ownership proof. Under these narrow conditions, changing the datum could redirect control of the recovered output.

Recommendation. Reject script payment credentials in the refund frontend before generating a proof or submitting a claim. This should match proof-tool’s existing assertSafeWalletAddress check, which permits only key payment credentials (addresses.ts:56-64). Apply the same restriction in the claims backend so custom clients cannot bypass the frontend check.

Client Response. The client has acknowledged the finding and has implemented a fix in the refund repository. The audit team has reviewed the diff, retested and confirmed the fix is valid.

Description. The public POST /claims route is registered without an API key requirement (post.ts:97-112) and accepts attacker-controlled Groth16 proofs. Its API Gateway request model permits a base64 proof string of up to 4,096 characters (post.ts:31-37), and the Lambda validates only the base64 syntax and the same maximum length (http-lambda-handler.ts:28-37). Neither layer validates the proof’s internal commitment count.

The backend copies the submitted proof into a verifier artifact (verify.ts:75-94) and invokes the bundled proof-tool verify-destination binary (proof-tool-verifier.ts:49-57). The Go verifier passes the proof to UnmarshalProof (main.go:483-502), which base64-decodes it and calls gnark’s Proof.ReadFrom without imposing structural bounds (prover.go:419-428).

When ReadFrom reaches the commitments slice, gnark-crypto reads a four-byte unsigned commitment count and allocates both a G1Affine slice and a boolean slice of that attacker-selected length before checking whether the input contains the declared commitments (marshal.go:236-245):

sliceLen, err = dec.readUint32()
if err != nil {
    return
}
if len(*t) != int(sliceLen) || *t == nil {
    *t = make([]G1Affine, sliceLen)
}
compressed := make([]bool, sliceLen)

The count can therefore be as large as $2^{32}-1$, even when the submitted proof contains no commitment data. At roughly 96 bytes per BLS12-381 affine point, plus the boolean slice, the maximum value would require approximately 416 GB of slice storage. The 4,096-character input limit does not bound this allocation because the declared count occupies only four bytes.

The destination circuit expects exactly one commitment (gate_test.go:24-30), but this expectation is not enforced before deserialization.

Impact. A small unauthenticated request can make the verifier process attempt an allocation far beyond the claim Lambda’s configured 1,024 MB memory limit (lambdas.ts:16-17). This can terminate the verifier or its Lambda execution environment before the malformed proof is rejected. Repeated requests can consume compute resources and disrupt legitimate claim submissions. Proof verification occurs before the backend checks whether a claim already exists (index.ts:185-193), so an attacker can repeatedly exercise the decoder with the same public affected key hash.

Recommendation. Reject proofs with an unexpected structure before calling gnark’s ReadFrom. For the current destination circuit, decode the base64 input, require the canonical compressed proof length, require exactly one commitment, and reject trailing data.

Client Response. The client has acknowledged the finding and has implemented a fix in the recovery-claims repository. The audit team has reviewed the diff, retested and confirmed the fix is valid.