Security Advisory

SecureDrop Workstation 1.0.2 released

February 13, 2025

In internal code review, we found two security vulnerabilities in the SecureDrop Workstation. We have released SecureDrop Workstation 1.0.2 and SecureDrop Client 0.14.1 to fix both vulnerabilities. Users need to run the standard SecureDrop Workstation Updater to apply these updates. We are not aware of any exploitation in the wild for either vulnerability.

The vulnerabilities are:

  • CVE-2025-24888: Path traversal in SecureDrop Client API.download_reply()
    • This vulnerability requires compromise of a SecureDrop Server to be exploitable.
  • CVE-2025-24889: Path traversal in sd-log Qubes virtual machine
    • This vulnerability requires compromise of another virtual machine on the SecureDrop Workstation to be exploitable.

Instructions for admins and users

Users need to run the standard SecureDrop Workstation Updater to automatically apply all updates. The system will require you to run the updater before you can log in and check for new submissions.

If you or your administrator have not manually updated our signing key since 6 February 2025, you must follow these instructions first, then run the updater as you would normally. This step updates our signing key with a new expiry date and is required for updates to succeed. We contacted all known SecureDrop Workstation users ahead of time to offer assistance with this step. If you need help or have any questions, please contact us for support.

During this update, the logging VM (sd-log) will be recreated from scratch. A backup of the previous logging VM will be created and stored on the system in an inert (non-bootable) state so that users cannot accidentally interact with it. Administrators who wish to inspect the contents of this VM or conduct any analysis can follow our documentation. Out of an abundance of caution, because the backup of a compromised VM could contain malicious code, we will release a second update in two months (mid-April 2025) to delete the backup; admins must save it elsewhere if they want to keep it for longer.

If you have any questions about this advisory, please contact us for support:

Timeline

  • 27 January 2025: Internal code review identifies a path-traversal vulnerability in the logging VM. Remediation work begins.
  • 28 January 2025: Maintainers review other areas of the SecureDrop Client codebase and identify another path-traversal vulnerability.
  • 29 January 2025: Patches for Debian components are reviewed and approved internally.
  • 30 January 2025: GitHub assigns CVE-2025-24888 and CVE-2025-24889. The internal release and QA process begins.
  • 3 February 2025: Patch to back up and recreate logging VM reviewed and approved internally.
  • 13 February 2025: SecureDrop Workstation 1.0.2 and SecureDrop Client 0.14.1 are released; advisories are published.

CVE-2025-24888: Path traversal in SecureDrop Client API.download_reply()

A malicious SecureDrop Server could obtain code execution on the SecureDrop Client virtual machine (sd-app). SecureDrop Server itself has multiple layers of built-in hardening, and is a dedicated physical machine exposed on the internet only via Tor hidden services for the Source and Journalist interfaces, and optionally via remote SSH access over another Tor hidden service. A newsroom's SecureDrop Workstation communicates only with its own dedicated SecureDrop Server.

Despite the exploitability requirements, given the high potential impact, the vulnerability is classified as “High” with a CVSSv3 score of 8.1.

Technical details

The SecureDrop Client runs in a dedicated Qubes virtual machine, named sd-app, as part of the SecureDrop Workstation. The private OpenPGP key used to decrypt submissions and replies is stored in a separate virtual machine and never accessed directly. The vulnerability lies in the code responsible for downloading replies. The filename of the reply is obtained from the Content-Disposition HTTP header and used to write the encrypted reply on disk. Note that filenames are generated and sanitized server-side, and files are downloaded in an encrypted format, so a remote attacker who has not achieved server compromise, such as one posing as a source, could not craft the HTTP response necessary for this attack.

While the filename is later checked to guard against path traversal before being moved into the Client’s data storage directory, the file has already been written to a potentially arbitrary location. In this case, safe_move() would detect the path traversal and fail, leaving the original downloaded file in the attacker-chosen directory. Code execution can be gained by writing an autostart file in /home/user/.config/autostart/.

We are not aware of any exploitation in the wild. This attack requires a previously compromised SecureDrop Server.

CVE-2025-24889: Path traversal in sd-log Qubes virtual machine

An attacker who has already gained code execution in a virtual machine on the SecureDrop Workstation could gain code execution in the sd-log virtual machine by sending a specially crafted log entry.

The vulnerability is not exploitable remotely and requires an attacker to already have code execution on one of the other VMs of the system. Due to the Workstation's underlying usage of Qubes for strong isolation, the vulnerability would have allowed lateral movement between any log-enabled VM and the sd-log VM, but no further. As such, and given the exploitability requirements, the vulnerability is classified as “Medium” with a CVSSv3 score of 4.5.

Technical details

The SecureDrop workstation collects logs centrally in an isolated virtual machine named sd-log for easy export for support and debugging purposes. The sd-log VM is completely isolated from the internet and ingests logs via a narrow Qubes RPC policy that allows for specific inter-VM communication via the Xen vchan protocol used by Qubes's qrexec mechanism.

A path traversal bug was found in the logic used to choose where to write the log file for a specific VM: the VM name, used unsanitized in the destination path in sd-log, is supplied by the logging VM itself instead of being read from a trusted source, such as the Qubes environment variable QREXEC_REMOTE_DOMAIN that is used in the fixed implementation. An attacker could provide an arbitrary source VM name, possibly overwriting logs of other VMs, or writing a file named syslog.log, with attacker-controlled content, in arbitrary directories as a low-privileged user.

A successful attack could potentially overwrite or add configuration to software that loads configuration files from a directory. This is exploitable to achieve code execution by setting the target directory to /home/user/.config/autostart/ and letting it write syslog.log, because XFCE treats any file in that directory as a .desktop file regardless of its extension.

Next steps

Our priority has been to get fixes for both issues tested and released as soon as possible. We will conduct a postmortem review internally to surface both technical and process issues that led to these vulnerabilities and how we will address them going forward.

Security research

Researchers may submit security vulnerabilities either through our bug bounty program or via encrypted email to securedrop@freedom.press (public key, fingerprint: 734F 6E70 7434 ECA6 C007 E1AE 82BD 6C96 16DA BB79).

Return to News