Injection vulnerability in securedrop-client mitigated
THREATQW9
· Mitigated: Controls in place bring the risk down to an acceptable level.
· Defined in catalog.py:3117
- Risk
- High impact × Medium likelihood = 9 high
- After mitigations
- Low impact × Low likelihood = 2 low
By submitting a message to a SecureDrop instance, an attacker an inject malicious markup or code inside the securedrop-client message view once it is downloaded and displayed on screen. An attacker could then either cause a user to perform an action or attempt to obtain code execution on sd-app.
Threat actors: Nation State / Law Enforcement Large Corporation
Mitigations
| Mitigation | Status |
|---|---|
| Use non-networked disposible VMs for opening all decrypted files. MITIGQW18 | implemented |
Possible further mitigations
- Escape content in the SecureDrop Client (https://github.com/freedomofpress/securedrop-client/issues/160) MITIGQW17 proposed
Where it applies
Applies to 1 component in 2 scenarios.
Workstation: reading submissions · sd-app (SecureDrop Client)
Workstation: export and print · sd-app (SecureDrop Client)
Notes
Existing mitigations: sd-app is airgapped making exfiltration difficult. Testing suggests that while the link works in dev env, it does not work in Qubes. Any link should be opened in a disposable, airgapped VM (MITIGQW18). Further mitigations: Use Jinja to escape any potential markup (MITIGQW17).
How this threat is matched
Listed for these components. A boundary covers every component inside it.