Once upon a time, Santa Claus received letters from children all over the world, delivered by trusty postal workers. But times have changed! With kids more online than ever, Santa had to adapt and start opening letters in digital form.
Enter Kenny Longears, an elf in Santa's security team (yes, Virginia, Santa has one)! 🧝 Kenny always preferred the ol' paper format. That way, he didn't need to worry about worms, bugs, and other pests that have no place in the North Pole. Begrudgingly, he yielded to the new era and set up Dangerzone in Santa's laptop to safely open email attachments. But wait! Kenny, being the cautious elf he is, decided to challenge Santa's red team to find vulnerabilities in Dangerzone before the naughty hackers do.
The challenge
Craft a naughty letter that can demonstrably bypass some or all of Dangerzone's defenses and earn a bounty 💰.
ℹ️ Quick recap of how Dangerzone works
Dangerzone sanitizes documents in a secure sandbox, in a process that is similar to a photocopy. It does so by spinning up a Podman container, which spins up a gVisor sandbox, which in turn reads a document. The sandbox then converts the document into a PDF, and the PDF pages into pixels. The Dangerzone logic that runs on the host converts the pixels to images, optionally OCRs them, and then creates a PDF. This PDF looks like the original document, but is safe to read and share with others.
To demonstrate your attack, you can send a PR to https://github.com/freedomofpress/santa-pwn-dangerzone/ with a specially crafted document, and a CI job will sanitize it with Dangerzone. The catch here is that this CI job plants three flags in the following locations:
The sandbox where the document turns into pixels (/home/dangerzone/raster.flag within the gVisor sandbox).
The container that spawns the gVisor sandbox for the conversion (/gvisor.flag within the Podman container).
The host of the CI job, where Dangerzone is installed (~/secrets/host.flag file in the host).
If you manage to capture one or more of these flags, add them in the sanitized document or print them to stderr from the conversion sandbox. The CI job will detect it, and the submission will be considered a success.
The bounty
Capturing a flag varies in difficulty. Dangerzone operates under the assumption that attackers can find vulnerabilities in the programs we use for rasterization (LibreOffice and PyMuPDF). Therefore, the raster.flag is expected to be captured at some point. The gvisor.flag flag requires escaping the gVisor sandbox, which is much, much more difficult. And the ~/secrets/host flag requires combining a gVisor sandbox escape and a Linux container escape at the same time, which we haven't seen yet in the wild.
Each flag is backed by a bounty, and the first PR that captures it gets that bounty 🤑. The bounty levels are:
🥇 ~/secrets/host.flag in the host: $1,700.
🥈 /gvisor.flag within the Podman container: $1,000.
🥉 /home/dangerzone/raster.flag within the gVisor sandbox: $300.
A PR can capture multiple flags at once, in which case it can get the full bounty, i.e., $3,000. Note that each flag can be captured once, since we need to cap the total payout to $3,000 across all submissions. In case of multiple submissions that capture the same flag, the first one wins 🏁.
1. Why do we encrypt documents when we submit them?
There are two primary reasons for encrypting your submissions. First, this is a public challenge, and we want to protect your ideas from being copied by others. Second, and more importantly, we aim to prevent real-world attackers from observing potential exploits and targeting our users. Encryption helps maintain the integrity and security of the challenge.
2. What happens on a successful submission?
If your submission is successful, we will redirect you to our Bugcrowd account to receive your reward. At the same time though, you will own the exploit. We will assist you in reaching out to the affected parties and help you claim any additional bounties they may offer for the vulnerability.
3. Can I experiment with this challenge locally?
Absolutely! You are encouraged to install Dangerzone locally and experiment with creating a document that can read a file from your PC during the sanitization process. Check out our CI job as well, to see how we plant the flags for the challenge. Once you have crafted your document, feel free to submit the encrypted version as a PR. Happy experimenting!
4. Does my submission have to pass the sanitization step?
If your submission cannot be sanitized, this means that we can't check for the captured flag in the resulting document. That's not a problem, though, since we look for flags in the conversion logs as well. If you capture a flag, you can print it to the process' stderr, and it will be included in the conversion logs. You should see it in the output of the CI job as well.
5. Can I submit any other types of issues?
If they undermine Dangerzone's security, you are encouraged to submit them via our Bugcrowd account, and we may assign a payout according to their severity, e.g., what flag they would potentially capture.
If they target this CI job, then they are considered out of scope.
6. Are we living in such desperate times that people will burn a gVisor/kernel 0-day for anything less than six figures?
Of course not! We are living in the merriest of times, where people can contribute their talent to spyware companies, enjoy a big payout, and sleep soundly at night! But at the same time, and let's be real for a second, no one will waste six figures to break Dangerzone. And if they do, this means that Dangerzone will have succeeded in protecting all the rest of the users that are not economically viable targets.
The scenario we want to avoid, though, is having a bug lying around that makes it trivial to bypass the defense layers Dangerzone employs. That's what we're looking for here, and the sanitization logic, for that matter, is pretty small. So, hopefully, this bounty will incentivize some folks to give our repo a look.
7. Is this a CTF challenge, or a bug bounty program?
It's a capped bug bounty program. The backstory is this: Dangerzone has never had a bug bounty program, as its sister project, SecureDrop, has. Our team has managed to secure some money from the bug bounty pool that was not spent this year and decided to give a festive spin to it because, well, why not? We hope that at some point in the future, we'll have an actual bug bounty program in place.
We're thrilled to announce the Dangerzone 0.10.0 release. It contains two big changes that we’ve been working on for the past few months:
The Dangerzone sandbox that performs the document conversion can now auto-update in the background, without having to install a new Dangerzone release. This allows us to push security fixes to all of our users in a timely fashion. It’s an opt-in feature that we strongly recommend you enable to greatly enhance your security. You can always choose to disable it if you prefer to update manually. Read more technical details about this feature in our documentation.
Windows and macOS users no longer need to install and manage Docker Desktop separately. Dangerzone now uses an open source container engine, Podman, which is embedded directly in the macOS and Windows builds. You can now simply start Dangerzone, and let it install WSL (Windows only) and create the necessary virtual machines and sandboxes under the hood. Plus, if you are a user/IT administrator in a big organization that wants to install Dangerzone, but couldn’t due to the licensing limitations of Docker Desktop, you now can.
In addition to these two changes, here are some more release highlights:
A new CLI helper called dangerzone-machine can help you manage the Podman virtual machine that Dangerzone uses under the hood (#1172).
All the commands and their outputs are now captured, and you can see them from our user interface. Click on the hamburger menu (☰) → “View logs” and a window will open with these logs (#1236).
The container image has been upgraded from Debian “bookworm” to Debian “trixie” (#1243).
The bundled LibreOffice has been upgraded from version 7.x to 25.x, as a result of our Debian trixie switch (#1165).
For a full list of the changes, see our changelog.
We're pleased to announce the First Release Candidate of Dangerzone 0.10.0.
This release introduces two major changes:
The Dangerzone sandbox that performs the document conversion can now auto-update in the background, without having to install a new Dangerzone release. This allows us to push security fixes to all of our users in a timely fashion. It’s an opt-in feature that we strongly recommend you enable to greatly enhance your security. You can always choose to disable it if you prefer to update manually. Read more technical details about this feature in our documentation.
Windows and macOS users no longer need to install and manage Docker Desktop separately. Dangerzone now uses an open source container engine, Podman, which is embedded directly in the macOS and Windows builds. You can now simply start Dangerzone, and let it create the necessary virtual machines and sandboxes under the hood. Plus, if you are a user/IT administrator in a big organization that wants to install Dangerzone, but couldn’t due to the licensing limitations of Docker Desktop, you now can.
Help us test Dangerzone!
These two changes are drastically changing how Dangerzone operates, especially on Windows and macOS. Dangerzone is used in different setups, and we cannot test for all of them. If you are willing to try this new release candidate and let us know how it went, that would be really useful to us.
Screenshot of the Dangerzone UI, where you can see a status bar with a VM being created.
If you want to help us, here is what to do:
Download and install the Dangerzone 0.10.0RC1 release:
We're pleased to announce that Dangerzone 0.9.1 has been released. It mainly
contains bug fixes for Windows and macOS platforms. If you are running Windows
or macOS, upgrading is advised as this release fixes errors with the latest
Docker Desktop version.
For this release, the highlights are:
Uniformly enforce our seccomp profile when running the Dangerzone sandbox,
across all platforms (Windows, macOS, Linux) and container runtimes (Docker,
Podman). This fixes a regression that has manifested since Docker Desktop 4.42.0
(#1191)
Fix a conversion failure for users who have enabled Podman Desktop
integration, whereby the Podman VM cannot find the necessary seccomp profile
(#1187)
Thanks to Nicola Sella for updating the
installation instruction for Fedora
(#1176).
This version drops support for Fedora 40, as security support has ended recently
(#1178).
For a full list of the changes, see our
changelog.
The Dangerzone team will be at Dataharvest '25, taking
place on May 23-25, 2025 in Mechelen, Belgium. If you are coming to Dataharvest,
feel free to reach out to us. We're more than happy to talk about Dangerzone and
related topics.
For more information on how to meet, you can send us a Signal message:
We're pleased to announce that Dangerzone 0.9.0 has been released. This release mostly includes stability improvements and security fixes, with a few new features.
If you are on a Mac or Windows, please also update Docker Desktop to version 4.40.0 or later, as previous versions contain known bugs that prevent Dangerzone from converting documents. On Windows, you will need to uninstall any Dangerzone version prior to 0.9.0 before installing this one.
For this release, the highlights are:
The container image is now reproducible across different container runtimes and versions (#1074). As part of this effort, the image used to run the conversion is now based on Debian (it was previously based on Alpine Linux) (#1046).
Outdated Docker Desktop versions are now highlighted in the user interface and the user is asked to upgrade (#693).
The CLI can now run with a --debug flag to help retrieve more logs (#941).
Experimental support is now available for Podman Desktop on Windows and macOS (docs)
The Docker Desktop team has issued an
announcement
in anticipation of an upcoming macOS Sequoia update that will affect Docker
users. If you update macOS before updating Docker Desktop, it's possible that
Docker may not start, or you may even see a warning like the one below:
Malware Blocked. “com.docker.vmnetd” was not opened because it contains
malware. This action did not harm your Mac.
Incorrect macOS malware notice for Docker Desktop
This warning is inaccurate. Docker Desktop is not affected by malware, but
instead was signed in a way that trips up the macOS malware detection mechanism.
Am I affected by this?
You are probably affected by the upcoming macOS update if:
You are a macOS user and are on the latest macOS 15 (Sequoia) version of the
OS. You can find out your OS version with
these instructions.
You are using Docker Desktop to run Dangerzone and haven’t updated since Jan.
9, 2025.
What can I do?
You are strongly advised to upgrade to the latest Docker Desktop version (4.37.2
or newer), either by
downloading the
latest version or via the Docker Desktop in-app update window. If you have
installed Docker Desktop via Homebrew, it is recommended to do a full reinstall,
following
these instructions.
If you have not yet upgraded your system to macOS 15 (Sequoia), you should
upgrade your Docker Desktop version before migrating to the new macOS version.
In Dangerzone, a security vulnerability was detected in the quarantined environment where documents are opened. Vulnerabilities like this are expected and do not compromise the security of Dangerzone. However, in combination with another more serious vulnerability (also called container escape), a malicious document may be able to breach the security of Dangerzone. We are not aware of any container escapes that affect Dangerzone.
To reduce that risk, you are strongly advised to update Dangerzone to the latest version.
Summary
A series of vulnerabilities in gst-plugins-base (CVE-2024-47538, CVE-2024-47607 and CVE-2024-47615) affects the contained environment where the document rendering takes place.
If one attempts to convert a malicious file with an embedded Vorbis or Opus media elements, arbitrary code may run within that environment. Such files look like regular Office documents, which means that you cannot avoid a specific extension. Other programs that open Office documents, such as LibreOffice, are also affected, unless the system has been upgraded in the meantime.
How does this impact me?
The expectation is that malicious code will run in a container without Internet access, meaning that it won't be able to infect the rest of the system.
What do I need to do?
You are strongly advised to update your Dangerzone installation to 0.8.1 as soon as possible.
This release includes various new features, stability improvements and security fixes. If you are on a Mac or PC you should additionally ensure that the Docker Desktop application is up to date. In addition to the changes specific to this release, we want to note that you can now use Dangerzone on the Tails live system. You can read the announcement on their blog, or read the documentation about it.
The highlights are:
The second phase of the conversion (pixels to PDF) now happens on the host.
Instead of first grabbing all of the pixel data from the first container, storing them on disk, and then reconstructing the PDF on a second container, Dangerzone now immediately reconstructs the PDF on the host, while the doc to pixels conversion is still running on the first container. This architectural change removes a class of problems we had in the past:
Issues with temporary directories and their permissions.
Out of space issues caused by documents with lots of pages (mainly impacted Qubes users).
SELinux issues due to relabeling mounted files.
Mounting files to Docker containers, prevented by security policies in Windows/macOS.
Not being able to run with user ID other than 1000.
If at some point in time you were affected by the above, we suggest giving this version a shot. The sanitization is no less safe, since the boundaries between the sandbox and the host are still respected (#625).
Installation and execution errors are now caught and displayed in the interface, which should make debugging easier (#193)
The macOS entitlements have been revisited, following our security audit. We have now removed unneeded privileges (#638)
We now always use our own seccomp policy as a default (#908)
Platform support updates
This release is the last one that will support Ubuntu Focal (20.04).
Ubuntu Focal is nearing its end of life date, due in April 2nd, 2025 (#965). We urge you to update to a newer Ubuntu version in order to get security updates.
This release includes a patch for Docker Desktop, and security updates. If you are on a Mac or PC you should additionally ensure that the Docker Desktop application is up to date. To install, follow the links in our downloads page.
The two changes in this release are:
Make Dangerzone work with fresh Docker Desktop installations
This release mainly addresses an issue with new Docker Desktop installations on Windows and Mac OS. Users who have done a fresh installation of Docker Desktop 4.30.0 or greater (released on August 29th), have reported that Dangerzone fails conversions with the following error message:
Unknown Error Code '125'
This error message is attributed to a new way that Docker Desktop stores and references container images, which broke some Dangerzone expectations. With this release, we enable Dangerzone to work both with older Docker Deskop installations and newer ones.
Update the software in our container image
As in every release, we rebuild our container image to get the latest security updates.
For a full list of the changes, see our changelog.
One of the oft-repeated sound bites of computer security advice is: “Don’t open random attachments from strangers.” If you are a journalist, however, opening attachments and documents is part of your job description. Since journalists already have a lot of security threats to worry about in dealing with sources, the safe opening of documents should not be one of them. Dangerzone was developed to solve this problem. It lets you open suspicious documents with confidence and gets out of your way.
For the past few months, members of the Dangerzone team and the gVisor project collaborated on significantly improving the security properties of Dangerzone. We’re excited to announce that as of version 0.7.0, Dangerzone uses gVisor to secure its document conversion process. It is already trusted by Google and others to secure cloud products, scan Gmail attachments for viruses, etc.
Welcome to the official Dangerzone blog. We will mainly cover:
release announcements
security updates (e.g., about code audits or vulnerabilities)
articles related to document sanitization and Dangerzone's inner workings.
You can follow the blog in your feed reader of choice. If you have thoughts on topics to cover (or would like to draft a post yourself), please don't hesitate to get in touch via our discussion forums.
Thank you for being part of the Dangerzone community!
