Penetration Test Report (TrailOfBits): SecureDropWorkstation

SecureDrop Workstation
Security Assessment
January 2 9, 2 020
Prepared For:
SecureDrop Team | F reedom of the Press Foundation
securedrop@freedom.press
Prepared By:
Dominik Czarnota | T rail of Bits
dominik.czarnota@trailofbits.com
Artem Dinaburg | T rail of Bits
artem@trailofbits.com
Changelog:
December 18, 2020 Initial report delivered
January 19, 2021 Added Findings 25-26 and Appendices G-H
January 29, 2021 Final version delivered: extended Executive Summary
Executive Summary
Project Dashboard
Engagement Goals
Coverage
Recommendations Summary
Short term
Long term
Findings Summary
1. Incorrect TOR_V2_AUTH_COOKIE_REGEX regular expression when validating config
2. Verifying Qubes installation media is confusing and error-prone
3. Only support Intel hardware, as AMD appears to lack sufficient testing
4. The order of operation in the safe_mkdir function allows an attacker to create the
directory with broader permissions
5. The downloaded submission may end up in an overly permissioned directory
6. Qubes qrexec tools handle libvchan_recv and libvchan_send return values
inconsistently
7. Whonix.NewStatus Qubes RPC should be redesigned
8. The offline mode doesn't require any authentication
9. Downloaded submissions have too broad permissions
10. Passwordless root access in VMs
11. qrexec-daemon in Qubes >= 4.1 could misidentify policy engine replies
12. The sd-app downloads submission to a file path fully trusted from the server,
allowing for path traversal
13. The migration script adds non-existent path to sys.path
14. The sd-proxy and sdclientapi allows duplicate JSON keys
15. Backup files remain valid policies
16. The securedrop-export in sd-devices unpacks incoming archives in a way that allows
for placing unpacked files in arbitrary paths
17. An arbitrary file write allows adding or overwriting mime types handlers in any
SecureDrop VM
18. The sd-app VM can call many different apps in sd-devices
19. The sd-viewer DispVM can DoS Qubes OS
20. Redundant AppArmor policy entries
21. Some spawned processes are not waited upon or terminated which may lead to
resource leaks in certain scenarios
22. The authorization key is valid for 8 hours
© 2020 Trail of Bits Freedom of the Press Foundation
SecureDrop Workstation Assessment | 1
23. The export UI reports an inaccurate error for exporting to external usb with more
than one partition
24. The validate_config script uses assertions that may be optimized out
25. Sysctl kernel configuration hardening
26. Hardening of SecureDrop applications
A. Vulnerability Classifications
B. Faking malicious replies from the SecureDrop server
C. The sd-devices TarFile.extractall path traversal proof of concept
D. Semgrep query that finds TarFile.extractall usage
E. An example of spawning a process without terminating it
F. Code Quality Recommendations
G. Attack surface analysis
Application-Level
Attack Surface
Security Mitigations
AppArmor Profiles
PaX hardening
Recommendations
OS-Level
Attack Surface
Qubes RPC Endpoints
Linux Kernel
Recommendations
Hypervisor Level
Attack Surface
Xen to VM CPU Interface
Xen to VM Driver Interface
Qubes OS GUI Interface
Recommendations
Recommendations Summary
H. Restricting SecureDrop processes via process isolation
Isolation tools
Sandboxing X11 applications
Example of isolating a PDF viewer in the sd-viewer DispVM with Nsjail
© 2020 Trail of Bits Freedom of the Press Foundation
SecureDrop Workstation Assessment | 2
Executive Summary
From November 30 through December 18, 2020, the Freedom of Press Foundation
engaged Trail of Bits to review the security of the SecureDrop Workstation. Trail of Bits
conducted this assessment over the course of 6 person-weeks with 2 engineers assessing
SecureDrop Workstation 0.5.0.
SecureDrop is an open-source whistleblower submission system maintained by Freedom
of the Press Foundation, a non-profit organization based in the United States. Over 75
news outlets worldwide use the system to communicate with sources.
The S ecureDrop Workstation is a new set of provisioning code, applications, and virtual
machines built on top of the Q ubes OS operating system. It provides a journalist the ability
to decrypt, open, and export documents and messages that were submitted by anonymous
sources. In the past, journalists relied on a manual, cumbersome process of decrypting and
opening submissions with an air-gapped computer. This approach attempts to improve the
journalist experience through virtualization and automation.
During the first week, Trail of Bits gained an overall familiarity with the Qubes OS and
SecureDrop Workstation architecture. This consisted of setting up and configuring
SecureDrop Workstation, documentation review, and a determination of areas for further
investigation. During the first week, we also ran B andit, S emgrep, and C odeQL static
analysis tools against the SecureDrop codebase.
During the second week, we reviewed the securedrop-client, securedrop-proxy, and
securedrop-sdk codebases and investigated communication between different VMs. We
also reviewed applicable policy controls present in the Qubes OS qrexec framework.
During the third week, we continued reviewing SecureDrop Workstation and the Qubes OS
qrexec framework. We also reviewed the included AppArmor policies by trying to gain
persistence in the s d-app VM. To investigate how the SecureDrop client handles malicious
responses, we set up a proxy between the s d-app VM and the SecureDrop server to allow
for the injection of malicious responses.
During the final week, we finished the review of SecureDrop Workstation codebases,
investigated the network communication between SecureDrop, Tor, and the Internet and
looked into additional hardening approaches that would provide layers of defense against
malicious submissions.
We were unable to achieve a direct compromise of the Workstation from the position of an
Internet-based attacker during our engagement. Our inability to achieve a direct
compromise of SecureDrop Workstation does not imply that such a compromise is
impossible or that SecureDrop Workstation is free from bugs. However, our assessment of
© 2020 Trail of Bits Freedom of the Press Foundation
SecureDrop Workstation Assessment | 3
the SecureDrop Workstation codebase resulted in 26 findings ranging from informational
to high severity. Definitions for both finding severity and category can be found in
Appendix A. Notable, the high severity finding details case where a malicious SecureDrop
server could create files in arbitrary paths in the s d-app VM, which may allow for code
execution (T OB-SDW-012) .
Furthermore, it is worth noting that the SecureDrop Workstation system relies heavily on
the Qubes OS system and its features such as qrexec RPC framework or VM isolation. While
we did not focus on the Qubes OS during this assessment, we reviewed the system's
configuration and investigated how the Qubes features were used. This included a review
of the source code of Qubes OS qrexec tools and its policy enforcement logic, which
resulted in two informational findings (T OB-SDW-006, T OB-SDW-011) .
Overall, the SecureDrop Workstation system represents a complex but well-researched
product that has been thoughtfully designed. Though, through the course of the
assessment, we were able to identify areas for improvement within the architecture. One
area is reliance on the q vm-open-in-vm RPC call, which brings in unnecessarily complex
logic to find which program to execute. Another area is application hardening. The entirety
of the application should undergo hardening steps, outlined in A ppendix H: Restricting
SecureDrop processes via process isolation.
Moving forward, Trail of Bits recommends addressing the findings in the report, ensuring
both short- and long-term recommendations are considered. Once fixes are applied and
recommendations considered, an assessment should be performed to ensure fixes are
adequate and do not introduce additional security risks.
© 2020 Trail of Bits Freedom o