Update signatures, rollback and privileged installation

Test the update decision and installation boundary while preserving production signer and privilege assumptions.

Used in these playbooks#

Setup and invariant#

Use a disposable installation, the eligible release, one genuine update, a standard-user attacker account and a separate administrative setup account. For source-available projects, create a local updater harness or documented test feed that exercises the real verifier. Record any configuration change: redirecting production traffic or granting the attacker an update signing key would change the claim.

Invariant: installation consumes exactly the artifact authorized by the expected publisher policy, and lower-privileged users cannot substitute content before a privileged consumer uses it. Version rollback is a defect only when it violates a defined security policy or restores a demonstrable vulnerability under realistic attacker control.

Procedure and command sheet#

1. Observe a genuine update. Record installed version, requested channel, feed metadata, downloaded filename/hash, expected publisher identity, temporary path, verifier result and installing process identity. Inspect local artifacts without executing them:

apksigner verify --verbose --print-certs ./update.apk
codesign -dv --verbose=4 ./Update.app
codesign --verify --deep --strict --verbose=2 ./Update.app

The Apple commands require macOS; the APK command requires Android build tools. A valid signature establishes properties checked by that tool, not that the product updater enforces its intended publisher. APK signer, Apple code-signing inspection.

2. Identify the actual updater. Read the shipped update library/version and packaging configuration. Electron update behavior depends on platform and package mechanism; a generic claim about all Electron applications is too broad. Android platform update signing is separate from application-managed downloadable modules or scripts. Electron autoUpdater, Android application signing.

3. Build three local controls. Use a genuine authorized artifact as the positive control, a one-byte-corrupted copy as the integrity control, and an artifact signed by an unrelated lab publisher as the identity control where the harness supports it. Keep the latter inert. Change only the relevant input and record the precise rejection/acceptance decision. Acceptance of metadata alone does not establish installation; distinguish download, verification, staging and activation.

4. Inspect the privilege boundary. Determine who can write the staged artifact, parent directory, updater configuration and helper executable. On Windows, these commands inspect signatures and ACLs:

Get-AuthenticodeSignature -FilePath 'C:\Lab\Update.exe' | Format-List
icacls 'C:\Program Files\ExampleApp'
icacls 'C:\Lab\Update.exe'

Use the actual observed staging path, not the illustrative path above. A broad ACL matters only if the standard user can control bytes that a more privileged process actually consumes. Demonstrate a harmless marker operation in a lab path; keep service identity and write access in the evidence. Authenticode inspection, ACL inspection.

5. Test rollback semantically. Compare a supported older genuine release with the current release in the local harness. Check whether the defined version policy rejects it and whether an attacker can supply it without administrative or signing authority. Do not force an ADB downgrade and report the explicitly requested platform behavior as an updater bypass. Reuse file boundaries for staging/extraction and identity/session when a rollback changes credential protections.

Completion and cleanup#

• Record exact accepted bytes and identity, not just a green verification UI.
• Preserve genuine, tampered, wrong-publisher and applicable rollback results.
• Explain prerequisite control, installing privilege and demonstrated effect.
• Label locally modified verifier behavior as a limitation until release equivalence is established.
• Restore original feed/configuration, remove inert fixtures, restore the VM snapshot and confirm the normal update path works.

Vulnerability reverse references#

• Updater accepts an artifact outside its publisher trust policy — The real update decision accepts modified bytes or an unrelated publisher identity before activation.
• Privileged updater consumes lower-user-controlled staging content — A standard user can replace a staged file or redirect a path actually consumed by a privileged installation process.
• Attacker-controlled rollback restores a prohibited security state — An attacker bypasses an update version authorization policy to cause a rollback that restores a prohibited security state.

Nearby shared procedures#

Object, function, and property authorization · Authentication, recovery, federation, and session lifecycle · Trace input into queries, commands, and templates · Server-side fetching and network trust boundaries · Browser execution, cross-origin reads, and forged actions · Uploads, downloads, paths, archives, and XML · Workflow invariants, replay, idempotency, and races · REST, GraphQL, gRPC, WebSocket, and SSE permission parity