Adversary exploits gzip parsing to get code execution accepted
THREATQW37
· Accepted: The team has decided to live with this risk.
· Defined in catalog.py:3549
- Risk
- High impact × Very Low likelihood = 3 low
- After mitigations
- Medium impact × Very Low likelihood = 2 low
e.g. exploit in gzip parsing to get code execution on the sd-app AppVM (since it's parsing the gzip files)
Mitigations
| Mitigation | Status |
|---|---|
| sd-client running in non networked VM MITIGQW20 | implemented |
| grsecurity in all Debian templates MITIGQW3 | implemented |
Residual risk
Exfiltration is still possible via sending a reply to an attacker-controlled source using the SecureDrop API.
Related threats
This threat is part of: Vulnerability introduced in provisioning code THREATQW15, Attacker obtains code execution in proxy VM THREATQW23
Smaller threats that make up this one:
- Privilege escalation (Xen vulnerability) THREATQW11 accepted
- Vulnerability in the QubesOS management layer THREATQW27 transferred
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: gzip files are provided by a trusted server sd-app vm is non networked (MITIGQW20) - sd-app is running grsec kernels (MITIGQW3). Further mitigations: SecureDrop server should gzip each file individually, the file is sent to sd-viewer in gzipped format. File metadata (if required) could be read by inspecting the gzip file within the client. Improve data validation prior to extraction on client-side.
How this threat is matched
Listed for these components. A boundary covers every component inside it.