keeper-register deployer proof is not bound to the pool it registers

[0x-SquidSol]

Summary

The keeper-register stateless deployer proof authorizes the slab but not the
pool it registers. The signed message binds only (slabAddress, unix-minute),
so a single valid signature authorizes registering that slab against any pool
address — including one substituted by a replay of a captured signature.

Affected code

app/app/api/playground/keeper-register/route.ts

// :134-136 — the signed message
function statelessProofMessage(slabAddress: string, unixMinute: number): Uint8Array {
  return new TextEncoder().encode(`${STATELESS_PROOF_PREFIX}:${slabAddress}:${unixMinute}`);
}

// :142-157 — verification takes only (slab, deployerPubkey, signature)
function verifyStatelessDeployerProof(slabAddress, deployerPubkeyBytes, signatureBytes) { ... }

The caller-supplied dexPoolAddress — which is what the keeper (and the display
feed via dex_pool_address) is pointed at, i.e. the pool the AuthMark settlement
price is derived from — is not part of the signed material. Neither is
mainnetCA or the rest of the payload.

Impact

Within the proof's validity window, a captured deployer signature can be
replayed with a substituted dexPoolAddress, repointing the market at an
attacker-chosen (but real, existence-checked) pool and thereby influencing the
settlement price the market resolves against.

Scope is bounded and worth stating plainly:

• The signature still proves control of deployer, and the route independently
  requires deployer to equal the slab's live on-chain marketauth. So this is
  not "anyone can repoint any market."
• Once percolator-stake's InitPool rotates marketauth to a PDA, no
  signature passes again — the realistic exposure is the pre-InitPool window
  for a freshly created market, or the admin-bypass path.
• Replay requires observing the deployer's signature, which travels over HTTPS.

It is therefore best characterised as a signature-hygiene weakness to harden for
v2: a proof should bind every security-relevant parameter it authorizes (the
pool), not just the slab. (For contrast, PR #2387 added payload binding on the
POST /api/markets path, which the launch flow no longer uses; the live
keeper-register proof was not covered.)

Proof of concept

Reproduces the message + verification verbatim and shows one signature verifies
regardless of the submitted pool, with a control asserting the slab is bound:

import nacl from "tweetnacl";

const PREFIX = "keeper-register";
// Buffer→Uint8Array (not TextEncoder) to avoid a jsdom realm mismatch with tweetnacl.
const msg = (slab: string, m: number) =>
  new Uint8Array(Buffer.from(`${PREFIX}:${slab}:${m}`, "utf-8"));
const verify = (slab: string, pub: Uint8Array, sig: Uint8Array) => {
  const now = Math.floor(Date.now() / 60_000);
  for (let d = -5; d <= 1; d++)
    try { if (nacl.sign.detached.verify(msg(slab, now + d), sig, pub)) return true; } catch {}
  return false;
};

const deployer = nacl.sign.keyPair();
const slab = "Fg6ptQ111111111111111111111111111111111111";
const minute = Math.floor(Date.now() / 60_000);
const sig = nacl.sign.detached(msg(slab, minute), deployer.secretKey);

// signature verifies, and the signed string references no pool at all:
verify(slab, deployer.publicKey, sig);                 // true (any submitted pool is accepted)
`${PREFIX}:${slab}:${minute}`.includes("<any pool>");  // false — pool is unauthenticated

// control: the slab IS bound, confirming only the pool binding is missing
const s2 = nacl.sign.detached(msg("SLAB_ONE", minute), deployer.secretKey);
verify("SLAB_TWO", deployer.publicKey, s2);            // false
verify("SLAB_ONE", deployer.publicKey, s2);            // true

Suggested fix (rollout is a maintainer decision)

Bind the pool (and ideally a hash of the full registration payload) into the signed
message: keeper-register:<slab>:<minute>:<dexPoolAddress>, verified server-side.

This is a coordinated client + server change — the client signs the message in
app/hooks/useCreateMarket.ts (~L469) — so a naive cutover would make
already-deployed clients fail to register. Two rollout options, left for
maintainers to choose:

1. Dual-accept, then deprecate — server accepts both the old
   (slab:minute) and new (slab:minute:pool) messages for a transition window;
   client emits the new format; drop the old format in a later release. No
   registration breakage.
2. Hard cutover — server requires the pool-bound message; client updated in
   the same release. Strongest binding immediately, but clients on an older bundle
   fail to register until they reload.

No fix PR is attached intentionally, so the rollout approach can be decided here.

[dcccrypto]

Two verified details that bear on the rollout choice, both checked against
playground@f2a3bbe5.

1. There are two client signing sites, not one. The issue names
useCreateMarket.ts ~L469; there is a second at L830, in the batched-launch
path, which bursts the signMessage prompt immediately before the batch
pipeline runs:

app/hooks/useCreateMarket.ts:469  `keeper-register:${params.slabAddress}:${unixMinute}`   // standard + retry path
app/hooks/useCreateMarket.ts:830  `keeper-register:${slabPk.toBase58()}:${unixMinute}`    // batched launch

A hard cutover (option 2) that updates only L469 would leave every batched launch
signing the old message and failing registration against a server that now
requires the pool-bound one. Whichever option is chosen, both sites change
together.

2. The pool is already in scope at both signing sites, so no restructuring is
needed to bind it. L469 has params.dexPoolAddress directly, and L830's guard is
already if (isKeeperOracle && params.dexPoolAddress && wallet.signMessage) — the
value is in hand at the moment of signing, ~15-30s before it is used.

Recommendation: option 1 (dual-accept, then deprecate). Not because the
cutover is infeasible — point 2 shows it isn't — but because this is a
browser-delivered bundle: a user with the create wizard already open holds the old
client, and under option 2 their registration fails at the last step of a flow
that has already spent real SOL on rent. The market goes live on-chain but
unregistered, and they land on "Retry registration", which on a stale bundle keeps
signing the old message and keeps failing. Dual-accept makes that window a no-op,
and the deprecation half is a one-line server change once traffic has rolled over.

One note on sequencing: #2467 is open against the same route
(app/api/playground/keeper-register/route.ts) for GH#2466. Landing that first
would avoid a conflict.

[Bayyan16]

Carrying over the remaining verified deltas from #2505 for consolidation here.

1. Exact replay window

The current stateless verifier checks seven candidate minute buckets:

const STATELESS_PROOF_WINDOW_BACK_MIN = 5;
const STATELESS_PROOF_WINDOW_FWD_MIN = 1;

d ∈ {-5, -4, -3, -2, -1, 0, +1}

So the verifier accepts seven distinct candidate messages around the server's current minute.

Because the proof is stateless and there is no consumed nonce / single-use state, the same valid signature may be accepted repeatedly while its signed minute remains inside that verification window.

This does not change the root cause already tracked in this issue; it just quantifies the replay property precisely.

2. Existing payload-bound authorization pattern

The sibling POST /api/markets path already implements the stronger authorization shape through buildMarketRegistrationMessage in app/lib/market-registration-auth.ts.

That message is domain-separated and binds:

• request method/path,
• deployer,
• server-issued nonce,
• and the complete canonical registration payload.

This provides an existing in-repo reference for binding the authorization to the registration parameters rather than only (slabAddress, unix-minute).

The two useCreateMarket.ts signing sites and the rollout implications are already documented in the comment above, so I am not duplicating them here.

Full PoC and expanded impact/severity analysis are documented in #2505.

[dcccrypto]

Confirmed still live — keeping open.

The deployer proof is bound to the slab, not to the pool. app/app/api/playground/keeper-register/route.ts signs:

keeper-register:<slabAddress>:<unix-minute>

(:34, :135, :300, :339) — poolAddress appears nowhere in the signed message, though it is very much in the payload that gets written (:24, :444).

So a signature valid for a slab authorises registering any pool against that slab, and re-registering to repoint it later, exactly as you describe. The route header even states the stakes at :12 and :17: this is "the only place the market↔pool binding is recorded", and the concern is someone able to "repoint any market's pricing pool".

The mitigations present are real but orthogonal: :19-22 resolves dexType authoritatively by classifying the pool account and verifies the pool exists on mainnet. That stops a nonexistent or misclassified pool — it does not stop a valid pool being bound to a market whose creator never authorised that specific pool.

Fixing it means changing the signed message to include the pool (e.g. keeper-register:<slabAddress>:<poolAddress>:<unix-minute>), which is a wire-format change for every existing client that signs this. That is a compatibility call — versioning the message, accepting both forms during a migration window, or a hard cutover — so I have not made it unilaterally.

[dcccrypto]

FIXED and merged in PR #2532. Closing — same root cause as #2505, fixed in one change.

The message now binds dexPoolAddress along with every other acted-on parameter, so a signature is valid for exactly one (slab, pool, CA, type, symbol, label) tuple.

Your statement of it is precise and is now an assertion in the test suite:

so a single valid signature authorizes registering that slab against any pool address — including one substituted by a replay of a captured signature

The test that pins it:

it("a substituted POOL produces a different message — the #2468 attack", () => {
  const attacker = { ...base, dexPoolAddress: "EviLPooL111111111111111111111111111111111" };
  expect(bytes(attacker)).not.toBe(bytes(base));
});

Under the old message those two were byte-identical, which is exactly why one signature covered both.

Worth noting about the separation

You and #2505 filed what turned out to be one defect from two angles — #2505 on the missing payload coverage generally, yours on the specific pool-substitution consequence. Neither is a duplicate of the other: #2505 establishes that the signature does not cover what the request does, and yours establishes what that buys an attacker. The second is what made the severity legible.

Both are closed by binding the parameters.

Not fixed, deliberately

The signature remains valid across the ~6-minute window and is not single-use — closing that needs a nonce store, which is what H1v2 removed to fix a serverless race. The consequence is now bounded instead: a replay can only re-register the same tuple, which is idempotent.

Negative control: reverting to the unbound message fails 4 of the 8 new tests. Launch suite: 3136 passed / 0 failed.