In advance of the initial release of SecureDrop Inbox, we commissioned an independent security audit from X41 D-Sec. In keeping with our policy of undergoing audits before major code changes are shipped, this was the inaugural audit of the new SecureDrop Inbox and the third independent audit focused on the SecureDrop Workstation.
This audit identified one medium-severity issue and three low-severity security issues in a prerelease version of the Inbox. Two of these issues will be mitigated in a future version of SecureDrop Inbox; one was fixed in advance of the initial release, and one was downgraded to informational after clarifying the relevant attack surface with the auditors.
“While vulnerabilities were identified, none are considered easily exploitable by attackers. This lowers their practical risk and indicates that SecureDrop Workstation is on a good security level compared to systems of similar size and complexity.”
Scope
This audit was focused on a prerelease version of the new SecureDrop Inbox. SecureDrop Inbox is a complete Electron rewrite of the SecureDrop Client, the core application of our Qubes OS-based SecureDrop Workstation. We thus implemented recommendations from this audit as we prepare the 1.0.0 release of the Inbox that will be delivered to newsrooms.
Besides the all-new TypeScript codebase, the auditors also scrutinized how SecureDrop Inbox is integrated with the compartmentalization and isolation features of Qubes OS. They also reviewed some of our development policies and our threat model.
Note that the SecureDrop Client was out of scope for this audit, as it is being phased out. However, we did apply all relevant fixes to it in a recent release.
Findings
The respective low- and medium-severity findings, SCRDR-CR-26-01: Deletion and Modification of Data Without Journalist Interference and SCRDR-CR-26-02: An Attacker Controlling sd-proxy May Read Journalists’ Replies, both identified how a compromised sd-proxy VM could be leveraged into a Machine-in-the-Middle attack, allowing an attacker to impersonate a source or interfere with the deletion and update of submissions. SecureDrop’s use of a proxy VM is one of the ways we leverage the strong isolation between application processes afforded by Qubes OS. These two findings suggest ways we could further harden SecureDrop if we treated this proxy VM as untrusted.
Implementing those suggestions would require reconsidering how sd-proxy functions, as well as changes to SecureDrop server. We plan to do both in future versions. Note that these findings do not indicate the potential for recovery of SecureDrop submissions by an attacker.
SCRDR-CR-26-04: Document Conversion Executed in Sensitive Qube was initially an informational note but was upgraded to a low-severity finding at our request. An isolated and ephemeral sd-export VM running LibreOffice is used to export submissions for printing and to USBs. When submissions are printed from multiple sources in the same session, the same sd-devices VM is used — a malicious submission exploiting a vulnerability in LibreOffice could thus potentially alter submissions from other sources.
This was partially mitigated by splitting printing into a new sd-printers disposable; our long-term fix will be to sanitize documents with Dangerzone before printing them. Because this same issue also affects the SecureDrop Client, we implemented this fix in the 0.17.4 version of SecureDrop Client and the 1.5.2 version of SecureDrop Workstation.
The remaining low-severity issue, SCRDR-CR-26-03: Moved: ANSI Escape Characters not Filtered, was reclassified as an informational note after we clarified the relevant attack surface with the auditors. Nevertheless, we still implemented a change to make it clear this use of ANSI filtering is purely for cosmetic reasons.
Additional recommendations
The auditors also provided 21 additional informational recommendations for improving the security of SecureDrop Inbox and its development.
We implemented small fixes to harden SecureDrop Inbox based on the following informational notes:
- SCRDR-CR-26-106: Electron Fuses
- SCRDR-CR-26-112: GnuPG Warnings Not Caught
- SCRDR-CR-26-113: DoS of Logging Component
- SCRDR-CR-26-114: No Timeout on GnuPG Child Process
- SCRDR-CR-26-115: DoS of Proxy Component
- SCRDR-CR-26-118: Inconsistent Item Deletion
- SCRDR-CR-26-122: Unhandled Exceptions
- SCRDR-CR-26-123: Path Validation Can Be Improved
- SCRDR-CR-26-124: An Attacker Controlling sd-proxy May Force File Download
We also implemented the improvement to SecureDrop’s documentation recommended by SCRDR-CR-26-105: HTTP Links in Documentation.
Solutions to both SCRDR-CR-26-100: Not All git Commits Are Signed and SCRDR-CR-26-101: Documentation Not Signed are in progress, as we implement stricter policies for signing commits and our published documentation. SCRDR-CR-26-104: GnuPG Keys Not Available is an issue we already address by expecting users to verify releases, but not every individual commit to our code. SCRDR-CR-26-103: Git Repositories Still Using SHA-1 is a risk we deem acceptable, since it is a limitation of our current forge, and we are not able to migrate presently.
SCRDR-CR-26-111: Files Are Extracted Automatically after Decryption, SCRDR-CR-26-119: Submissions Encrypted Server-Side, SCRDR-CR-26-120: No Mitigation of Compromised Submission Key, and SCRDR-CR-26-121: Lack of Trust Boundary Between Different Journalists all stem from limitations with SecureDrop’s fundamental architecture, which the next-generation SecureDrop Protocol seeks to solve.
We determined SCRDR-CR-26-107: Binary Hardening can only be addressed by changes to upstream projects (but we intend to encourage those changes).
SecureDrop Inbox can contain outdated dependencies, as noted in SCRDR-CR-26-109: Outdated Packages, since we follow our own policy for when to upgrade a dependency.
Finally, SCRDR-CR-26-102: All Actors Act in Good Faith provided helpful feedback to our threat model, which we intend to consider in a future update.
Closing thoughts
Rewriting the core application of the SecureDrop Workstation from scratch in an entirely new framework was a major undertaking. We were extremely pleased with this audit result, which only discovered a few minor security issues. While we were already confident SecureDrop Inbox would provide a greatly improved user experience for journalists, we can now also be confident it provides the same standard for security that SecureDrop depends on.
Thank you to X41 D-Sec for its thorough work and collaboration in this audit.
If you discover any security vulnerabilities in SecureDrop Inbox or SecureDrop’s other components, please submit them through our public bug bounty program (which will soon be amended to include the new Inbox — stay tuned!) or via encrypted email to securedrop@freedom.press (public key, fingerprint: 734F 6E70 7434 ECA6 C007 E1AE 82BD 6C96 16DA BB79).