Attacker obtains code execution in the GPG VM partially mitigated

THREATQW6 · Partially mitigated: Some controls are in place, but the risk is still too high. · Defined in catalog.py:3061

Risk
High impact × Low likelihood = 6 medium
After mitigations
Medium impact × Very Low likelihood = 2 low

How statuses and scores work

An attacker with code execution on GPG VM could exfiltrate the GPG submission key or perform arbitrary decryptions.

Threat actors: Nation State / Law Enforcement Large Corporation

Mitigations

No mitigations in place.

Possible further mitigations

Residual risk

In the event of a cross-vm attack or dom0 compromise, an attacker would be able to decrypt submissions or exfiltrate private keys.

Where it applies

Applies to 1 component in 2 scenarios.

Workstation: reading submissions · sd-gpg
Workstation: boot, provisioning and updates · sd-gpg

Notes

Existing mitigations: sd-gpg vm has a limited attack surface as it only stores GPG keys and performs decryptions of SecureDrop-generated gzip archives through the Qubes split-gpg feature. Qubes-rpc policies restrict only sd-app from accessing this VM, all other requests are denied by default. Decrypted Gzip files are immediately sent to another vm for processing/display. GPG VM does not have any network connectivity. Further mitigations: - Use hardware token (yubikey, nitrokey) (MITIGQW8) to prevent exporting the key. - Consider using a more stripped down Template (kernel, OS) to reduce attack surface (MITIGQW4) - Validate that GPG files are valid (to potentially prevent exploitation of a GPG vulnerability by not attempting to decrypt malicious files (noting that the parsing of files also is a risk)) (MITIGQW11) - Qubes RPC policy to deny (MITIGQW15) - Validate GPG payload in sd-svs prior to sending to sd-gpg for decryption (MITIGQW16).

How this threat is matched

Listed for these components. A boundary covers every component inside it.