Known vulnerability in any VM template mitigated

THREATQW22 · Mitigated: Controls in place bring the risk down to an acceptable level. · Defined in catalog.py:3323

Risk
High impact × High likelihood = 12 high
After mitigations
High impact × Low likelihood = 6 medium

How statuses and scores work

A known vulnerability in the template VM is exploited by an attacker. Any VM using the template would contain the vulnerable package.

Threat actors: Nation State / Law Enforcement Large Corporation Developer error

Mitigations

Mitigation Status
Autoupdate all VMs MITIGQW1 implemented
grsecurity in all Debian templates MITIGQW3 implemented

Residual risk

AppVMs that have not been rebooted do not have updates applied. TemplateVMs must have upstream support (e.g. receive security fixes). Custom grsecurity-hardened kernels must be built and updated by FPF.

Where it applies

Applies to 9 components in 3 scenarios.

Workstation: reading submissions · sd-app (SecureDrop Client), sd-proxy, sys-firewall, sys-net, sd-gpg, sd-viewer (disposable VMs), sd-log
Workstation: export and print · sd-app (SecureDrop Client), sd-devices (export and print), sys-usb, sd-viewer (disposable VMs), sd-log
Workstation: boot, provisioning and updates · sd-gpg

Notes

Existing mitigations: - Template packages are updated prior to starting the SecureDrop App. Once the update is complete, the user will prompted to reboot to apply updates if any dom0 updates were found. - Grsecurity hardened kernels used in critical VM templates (MITIGQW3). Further mitigations: - Updater GUI informs and prompts user to restart AppVMs or entire workstation. - Provide end-user documentation informing them that an Internet connection and reboot are required to ensure package updates.

How this threat is matched

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