Dangerzone

April is the cruelest month

2026-05-06T00:00:00Z

This April has been a wild ride. At the start of the month, Anthropic made bold claims about the security research abilities of its Claude Mythos model. Any open source project under the sun is now in the danger zone, and Dangerzone even more so.

In the past few days, we became aware of some AI-assisted vulnerabilities that could affect Dangerzone, but thankfully are mitigated by our defenses.

On April 17, a security team disclosed that iTerm2 was vulnerable to a PTY confusion attack. The details of the attack and its impact are not what matter here, but the crucial point is that there are popular terminal emulators out there that may parse untrusted output and perform actions based on it. Our dangerzone-cli, the CLI counterpart to the Dangerzone GUI, does handle untrusted content and may print it to the terminal, but thankfully, it sanitizes it first:

Testing Dangerzone against a file that begins with the control characters of the iTerm2 exploit. Dangerzone replaces escape sequences with � characters.

We were aware of this attack vector from internal research we had performed a while back, which was the result of our first-ever security advisory.

On April 29, the copy.fail vulnerability was disclosed by another security team. This vulnerability allows any unprivileged user in the system to gain root privileges on any Linux system since 2017, via an exploit in the kernel crypto API (AF_ALG). This would theoretically affect all of our users, since Dangerzone uses Linux VMs to run its sandbox, even on Windows and macOS.

Our gVisor integration, though, saved the day:

Testing Dangerzone against the copy.fail exploit. gVisor does not support the vulnerable protocol and thwarts the attack.

We are confident that our security measures in place will still hold for the foreseeable future, but ne'er cast a clout till May be out!

How Dangerzone distributes sandbox updates

2026-04-02T00:00:00Z

TL; DR: In 0.10.0, Dangerzone introduced a feature that allows users to auto-update the container used to do conversions.

This article goes through why that matters and how we implemented it:

attesting the provenance of the images
making them reproducible, and
signing them using an auditable system.

In case you don't already know Dangerzone, here is a quick summary: It's a tool that uses containers to convert documents (.docx, .pdf, images, etc.) into pixels and then reconstruct them as PDFs. This renders any embedded script or malware ineffective. The conversion is done in an untrusted container that takes a binary stream as input and returns a pixel stream as output. We consider opening a document unsafe and exploitable, which is why we distrust the container.

With that being said, this container still needs to be kept up to date in order to avoid an attacker using known exploits. It's better to think about this in layers: If an attacker wants to compromise Dangerzone, they would need first to exploit the document viewer and then find a container escape.

Originally, Dangerzone bundled the container image within its installers, which made it difficult for us maintainers to release container updates in a timely fashion. Emergency releases of the container were time-costly, because they meant a full-blown release: testing on Windows, macOS, and many Linux flavors, which tends to generate some delay and stress.

This “Independent Container Updates” feature makes that stress go away, enabling us to release a new version of the Dangerzone container quickly, and without blindly trusting the container registry used to distribute the images.

Here is what we're doing when releasing a container image, implementing the steps best known as the Triangle of Secure Code delivery:

Attesting its provenance.
Making sure it is reproducible.
Signing it.

So, how do we do this? Let's go for a small walk!

Checking image provenance

Currently, our container images are built nightly by our Continuous Integration system in a GitHub runner. This allows us to automatically run tests against them.

Since we don't blindly trust the GH runners for doing what they claim (see the next section about reproducibility), we verify the image was generated from a specific workflow and repository.

To that goal, we are using the SLSA framework. Runners add attestations to our container registry, and we then check them before going further.

Practically, attestations are information about the run: from which repository, which branch, which commit?

All the information about the run is added to the container registry (ghcr.io in our case) at a specific location, matching the digest of the published image: container-registry/image:sha256-{digest}.att.

The attestation is a base64-encoded blob that can be read in a human form using this script:

IMAGE=ghcr.io/freedomofpress/dangerzone/v1
TAG=latest

# Retrieve the digest of the latest tagged image
DIGEST=$(crane digest ${IMAGE?}:${TAG?})

# Generate the sha256-{digest}.att location
ATT_MANIFEST=${IMAGE?}:${DIGEST/:/-}.att

# Save the provenance info in attestation.json
ATT_BLOB=${IMAGE?}@$(crane manifest ${ATT_MANIFEST?} | jq -r '.layers[0].digest')
crane blob ${ATT_BLOB?} | jq -r '.payload' | base64 -d >> attestation.json

The resulting attestation.json is too large to be displayed, so let's just view a part of it as an example:

cat attestation.json | jq '.predicate.invocation.configSource'
{
  "uri": "git+https://github.com/freedomofpress/dangerzone@refs/heads/main",
  "digest": {
    "sha1": "58aed2d6f6dedebc2bbbc4a96fe69ac9c425b508"
  },
  "entryPoint": ".github/workflows/release-container-image.yml"
}

Then, prior to reproducing and signing the image, we use this information in our own builders to verify the provenance of the container.

For this, we're using a CUE policy. In our case, we ensure that the entrypoint of the workflow and the repository match our expectations.

// The predicateType field must match this string
predicateType: "https://slsa.dev/provenance/v0.2"

predicate: {
  // This condition verifies that the builder is the builder we
  // expect and trust. The following condition can be used
  // unmodified. It verifies that the builder is the container
  // workflow.
  builder: {
    id: =~"^https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v[0-9]+.[0-9]+.[0-9]+$"
  }
  invocation: {
    configSource: {
      // This condition verifies the entrypoint of the workflow.
      // Replace with the relative path to your workflow in your
      // repository.
      entryPoint: ".github/workflows/release-container-image.yml"

      // This condition verifies that the image was generated from
      // the source repository we expect. Replace this with your
      // repository.
      uri: =~"^git\\+https://github.com/freedomofpress/dangerzone"
    }
  }
}

Of course, you don't have to know all this! Just using cosign verify-attestation will do that for you (if you don’t know Cosign, don’t fret; we’ll talk about it again very soon).

Reproducible images

Once we are sure the image comes from the expected repository and workflow, we want to make sure we are able to reproduce it locally.

One of our prerequisites is that you don't really have to trust us. When we ship a container image, you should be able to verify that the container image matches our published source code.

That's where reproducible container images enter in the landscape. You can build yourself a container image based on a specific git commit, and it will be bit for bit the same as the one we have signed and distributed.

If you are interested in knowing more about this, you can read our article on the matter.

Signing an image

The last thing we want to do (but not the least) is to sign the image and verify the signatures locally.

We are using the Sigstore ecosystem for this, which provides a tool named Cosign, that signs and verifies container images. Sigstore differs from traditional signing mechanisms because signatures can be audited; every signature is recorded in Sigstore’s transparency log. Having our signatures auditable makes it possible for us (or anybody) to know when our keys are used.

It's worth noting that Sigstore can be used in a number of different ways, one of them being keyless signatures. In our case, though, our process relies on physical keys, so we are using the Sigstore ecosystem mainly for the auditable logs.

So, how do you sign container images? Use cosign sign! It does the following:

Generates a signature using the provided keys.
Uploads the signature to the auditable log and gets back a tamper-resistant proof.
Attaches the signature and the proof to the container registry, at sha256-{digest}.sig.

The signature itself and the way the signature is attached to the container registry is part of the signature specification.

[The following section explains how signatures are computed and applied to a container registry. If you are not interested in the deep dive, you can skip to the following section about verifying the container signatures]

Let's have a look at the signatures for our latest container image:

crane manifest ghcr.io/freedomofpress/dangerzone/v1:sha256-7396780b5862cf8b37527854a2a2331e5c746b6a71aa1f424258c3bfaf3a1bd7.sig | jq

Outputs:

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "size": 233,
    "digest": "sha256:a3b01184f5d756fc9601d3386b49fe1c3cd3eedea08b8a6e11137b2a7988ed5f"
  },
  "layers": [
    {
      "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json",
      "size": 252,
      "digest": "sha256:88b8a2ac5b829f47bd25a5a4d9c2ccb0fccff7f53a17477b6d9b5680436aa80f",
      "annotations": {
        "dev.cosignproject.cosign/signature": "MEQCIAQScnT03MVfmxjYyW5qAmvQ6TSoukPuw0HmSVlMBwYEAiAzGb76cvDb4CHJ+H6tD00bW1Sh1CK6opaRmI2ist4p2A==",
        "dev.sigstore.cosign/bundle": "{\"SignedEntryTimestamp\":\"MEYCIQCsAt/PgYO2WFKoQX/P42vXCWJVUEgqRLXZ0BlrKwY40QIhAOTu/oE7jDtL8XP4PiZJhJ3nSlW3yXUp5ErSmjedzdCv\",\"Payload\":{\"body\":\"eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoiaGFzaGVkcmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiI4OGI4YTJhYzViODI5ZjQ3YmQyNWE1YTRkOWMyY2NiMGZjY2ZmN2Y1M2ExNzQ3N2I2ZDliNTY4MDQzNmFhODBmIn19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FUUNJQVFTY25UMDNNVmZteGpZeVc1cUFtdlE2VFNvdWtQdXcwSG1TVmxNQndZRUFpQXpHYjc2Y3ZEYjRDSEorSDZ0RDAwYlcxU2gxQ0s2b3BhUm1JMmlzdDRwMkE9PSIsInB1YmxpY0tleSI6eyJjb250ZW50IjoiTFMwdExTMUNSVWRKVGlCUVZVSk1TVU1nUzBWWkxTMHRMUzBLVFVacmQwVjNXVWhMYjFwSmVtb3dRMEZSV1VsTGIxcEplbW93UkVGUlkwUlJaMEZGTTBOVmJHNTNhRGd5TlZvMWQxRkJTbFkyVkdWclJXazJZa05MTWdwWmRrRm5OMEVyWVdWbGNrMDFhSFpqTkVORFEwcEdRbUZsTlVGcWJuTnFSMGgyTkZZdk0zaDZjM05qYXpabE5URlhLMkl3YWxVMGNWWjNQVDBLTFMwdExTMUZUa1FnVUZWQ1RFbERJRXRGV1MwdExTMHRDZz09In19fX0=\",\"integratedTime\":1770622892,\"logIndex\":929816779,\"logID\":\"c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d\"}}"
      }
    }
  ]
}

There is a lot to unpack here. Two main things are of interest:

First, the digest of the Cosign payload is stored under the layers[0].digest key, where you can read sha256:88b8a2ac5b829f47bd25a5a4d9c2ccb0fccff7f53a17477b6d9b5680436aa80f. Let's retrieve it from the referenced blob:

crane blob ghcr.io/freedomofpress/dangerzone/v1@sha256:88b8a2ac5b829f47bd25a5a4d9c2ccb0fccff7f53a17477b6d9b5680436aa80f | jq .

{
  "critical": {
    "identity": {
      "docker-reference": "ghcr.io/freedomofpress/dangerzone/v1"
    },
    "image": {
      "docker-manifest-digest": "sha256:7396780b5862cf8b37527854a2a2331e5c746b6a71aa1f424258c3bfaf3a1bd7"
    },
    "type": "cosign container image signature"
  },
  "optional": null
}

That's what we sign: the digest of our image (the sha256:7396780… bit).

Let’s back up for a moment: How does that work?

Container registries store manifests (and blobs, for that matter) at their digest address, meaning signing a digest is actually like signing the whole manifest.

If we verify the signature for a specific digest, then it's the same as verifying the signature of the image itself.

Second, the sha256-{digest}.sig signature we retrieved from the container registry provides us a bundle in the dev.sigstore.cosign/bundle field. It contains:

The base64-encoded body (which embeds the public key and the signature).
The logIndex and logID, which refer to the published log on Rekor.

Verifying a signature means verifying that the provided signature matches the expected payload and public key, and that it matches the accompanying inclusion proof in the auditable log.

Here is the bundle:

jq -r '.layers[0].annotations."dev.sigstore.cosign/bundle"' | jq

{
  "SignedEntryTimestamp": "MEYCIQCsAt/PgYO2WFKoQX/P42vXCWJVUEgqRLXZ0BlrKwY40QIhAOTu/oE7jDtL8XP4PiZJhJ3nSlW3yXUp5ErSmjedzdCv",
  "Payload": {
    "body": "eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoiaGFzaGVkcmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiI4OGI4YTJhYzViODI5ZjQ3YmQyNWE1YTRkOWMyY2NiMGZjY2ZmN2Y1M2ExNzQ3N2I2ZDliNTY4MDQzNmFhODBmIn19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FUUNJQVFTY25UMDNNVmZteGpZeVc1cUFtdlE2VFNvdWtQdXcwSG1TVmxNQndZRUFpQXpHYjc2Y3ZEYjRDSEorSDZ0RDAwYlcxU2gxQ0s2b3BhUm1JMmlzdDRwMkE9PSIsInB1YmxpY0tleSI6eyJjb250ZW50IjoiTFMwdExTMUNSVWRKVGlCUVZVSk1TVU1nUzBWWkxTMHRMUzBLVFVacmQwVjNXVWhMYjFwSmVtb3dRMEZSV1VsTGIxcEplbW93UkVGUlkwUlJaMEZGTTBOVmJHNTNhRGd5TlZvMWQxRkJTbFkyVkdWclJXazJZa05MTWdwWmRrRm5OMEVyWVdWbGNrMDFhSFpqTkVORFEwcEdRbUZsTlVGcWJuTnFSMGgyTkZZdk0zaDZjM05qYXpabE5URlhLMkl3YWxVMGNWWjNQVDBLTFMwdExTMUZUa1FnVUZWQ1RFbERJRXRGV1MwdExTMHRDZz09In19fX0=",
    "integratedTime": 1770622892,
    "logIndex": 929816779,
    "logID": "c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d"
  }
}

When we retrieve the entry related to this logIndex on the Rekor log, we can see that it matches the base64-decoded body in Payload.body:

curl https://rekor.sigstore.dev/api/v1/log/entries?logIndex=929816779 | jq -r ".[].body" | base64 --decode | jq

{
  "apiVersion": "0.0.1",
  "kind": "hashedrekord",
  "spec": {
    "data": {
      "hash": {
        "algorithm": "sha256",
        "value": "88b8a2ac5b829f47bd25a5a4d9c2ccb0fccff7f53a17477b6d9b5680436aa80f"
      }
    },
    "signature": {
      "content": "MEQCIAQScnT03MVfmxjYyW5qAmvQ6TSoukPuw0HmSVlMBwYEAiAzGb76cvDb4CHJ+H6tD00bW1Sh1CK6opaRmI2ist4p2A==",
      "publicKey": {
        "content": "LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJemowREFRY0RRZ0FFM0NVbG53aDgyNVo1d1FBSlY2VGVrRWk2YkNLMgpZdkFnN0ErYWVlck01aHZjNENDQ0pGQmFlNUFqbnNqR0h2NFYvM3h6c3NjazZlNTFXK2IwalU0cVZ3PT0KLS0tLS1FTkQgUFVCTElDIEtFWS0tLS0tCg=="
      }
    }
  }
}

The public key is base64-encoded; here is the decoded version:

--BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE3CUlnwh825Z5wQAJV6TekEi6bCK2
YvAg7A+aeerM5hvc4CCCJFBae5AjnsjGHv4V/3xzssck6e51W+b0jU4qVw==
-----END PUBLIC KEY-----

Verifying the signatures

Now that you understand how everything is stored in the container registry, let's switch perspectives and step into the shoes of the user of the application. How can we validate that the signatures are valid?

As usual in these cases, don't do it yourself! Cosign provides a tool to verify a signature against a payload and a public key. In our case, we need to do a small rearrangement of how the payload is laid out to follow the format expected by Cosign, but that's mainly it.

See how it is implemented in Dangerzone.

Storing signatures

Once the signatures are deemed valid, we can store them locally. Here is how we do it:

tree ~/.local/share/dangerzone/signatures/
├── <pubkey-digest>
│   ├── <image-digest>.json
│   ├── <image-digest>.json
└── last_log_index

The last_log_index file is used to keep track of the last log index processed by the updater. When we apply an update, we verify that the new log index is actually greater than the last known log index, effectively ensuring that an attacker cannot downgrade our container image once installed.

The format used in the .json file is the cosign download signature, which differs from the "bundle" one used in the code, as we've just seen earlier.

Right before running the container, we verify that the signatures are valid for the digest we have signatures for.

Wrapping up

So, here is how we've been setting things up related to images and signatures for Dangerzone. At the time of writing, image signing is a moving target: Cosign recently issued a version 3, where they slightly changed the format used for the bundles, but the main idea remains the same.

In the end, releasing a new image is as simple as:

Picking an image, most probably the latest nightly build.
Logging to our build machines.
Verifying the provenance of the image.
Reproducing it locally.
Signing the container image and tagging it as latest.

The Dangerzone application checks for new versions of the sandbox, at most, every 12 hours (if you’ve enabled this feature). When we detect a new version, we:

Check the signatures against our stored public key (distributed alongside the software).
Store the signatures locally.
Proceed with the podman pull of the image.

Then, we verify the validity of the signatures right before summoning the sandbox for doing conversions.

One extra benefit from doing this, is that now the Dangerzone container image can be used without Dangerzone itself. That enables a whole world of possibilities, in case you have an idea where doing a conversion to pixels without exposing the host makes sense. It’s as simple as: podman pull ghcr.io/freedomofpress/dangerzone/v1 while using a correct container policy, as outlined in this issue.

P.S. We’re also working on a way for you to use Dangerzone as a library, but let’s save that for a different time!

Reproducing the reproducible images

2026-03-02T00:00:00Z

The Dangerzone project has to be a bit distrustful: It distrusts the document that is processed in its container, and it also distrusts the registries that serve its image, which is why we sign it and ensure it’s bit-for-bit reproducible.

The reproducibility of our container image is one of our core defenses against supply chain attacks, and in this post, we talk a bit more broadly about this often-overlooked subject. We will also introduce a collection of tools and CI helpers for reproducible images, which should be generic enough to apply to your project as well.

For those new to what “reproducible” means, here’s a helpful definition by the Reproducible Builds project:

“A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.”

When talking about reproducible container images, the two main container managers, Docker (BuildKit) and Podman (Buildah), suggest specifying both SOURCE_DATE_EPOCH and an argument to rewrite the image layers:

For BuildKit, specify SOURCE_DATE_EPOCH in your Dockerfile (or environment) and pass the rewrite-timestamp=true option (source).
For Buildah, specify SOURCE_DATE_EPOCH in your Dockerfile (or environment or use the CLI option --source-date-epoch) and pass the --rewrite-timestamp option (source).

Let’s create a reproducible image

Reproducibility is actually much more than setting a timestamp. The image itself must be free of any sources of nondeterminism. Let’s consider a Dockerfile, where we install gcc in a Debian image that was created on 2023-09-04 and has remained the same ever since:

FROM debian:bookworm-20230904-slim
RUN apt-get update && apt-get install -y gcc

Is this container image reproducible? Let’s find out:

$ export SOURCE_DATE_EPOCH=1677619260  # Just a random UNIX epoch
$ docker buildx --no-cache --output type=docker,dest=image.tar,rewrite-timestamp=true .
[...]
 => => rewriting layers with source-date-epoch 1677619260 (2023-02-28 21:21:00 +0000 UTC)                                                                                                                                                9.7s
 => => exporting manifest sha256:81ebf01e608e298f2827d3da4e546e531e6b8b19f2f793df10b058f16b85545a

Once more, with feeling:

$ docker buildx --no-cache --output type=docker,dest=image.tar,rewrite-timestamp=true .
 [...]
 => => rewriting layers with source-date-epoch 1677619260 (2023-02-28 21:21:00 +0000 UTC)                                                                                                                                                9.7s
 => => exporting manifest sha256:231a1e36dae728a3f8bc3bdfa20a856c3bb78f0a3759ad98a1ea13d2d4920614                                                                                                                                        0.0s

That’s interesting, the digests differ!

So, the Dockerfile is not reproducible, but why? The Reproducible Containers project by Akihiro Suda fills an important gap in the understanding and tooling around reproducible container images. Among other utilities, it offers a tool to diff OCI images: diffoci.

So, let’s check why those images differ with diffoci. We’ll use the --semantic flag here, to check only file differences, and the --report-dir diffs/ option to write the differing files into a diffs/ directory:

$ diffoci diff --semantic --report-dir diffs/ <image1> <image2>
TYPE    NAME                            INPUT-0                                                             INPUT-1
File    var/log/apt/term.log            f78e67afe7aca12045cd74a73d6bdb38fd2ef3621f64b178feb0b82fad9d26a2    e3b6ff496d4253810b97f432eec285bc0a4f85ae87d667cc7ef6f4c7c2eaef1f
File    var/cache/ldconfig/aux-cache    c0bd5b8e12012d153bf527509e6ef0d125bafbd998e33443d8bca12c9352abb4    37f21a5282b0bc13af266cbab5c6819d7045c346f28c782a5920d52044f2720f
File    var/log/dpkg.log                fe4e8edc30b2b0a8d936b9930ece042c9affa8b2b567f74d160a680d57874a73    530173cae986e3607bac1eef1b1739d1a3cfbfa539f9aebfaa7397b397f31712
File    var/log/alternatives.log        abb1f05b7ff0598fcbe7374f513898a0acf6f23260661420ebb1e732bd09b192    da346849248fbcd01371339956f2a90a9e28ace7c54e596ed1dc95df06919111
File    var/log/apt/history.log         99e8510b67d705a84899115a25c15206fa9affd52f75af1e6ef6ecd06e679552    766b51931e938fee62973d04c495e38d9a36be7ca4b2efafb76883ac502672f2

It seems that some APT-related files are different. Let’s check them out:

$ diff diffs/input-{0,1}/layers-1/var/log/apt/term.log
2c2
< Log started: 2026-01-22  09:58:37
> Log started: 2026-01-22  09:59:38
355c355
< Log ended: 2026-01-22  09:58:47
---
> Log ended: 2026-01-22  09:59:48

Makes sense, the fact that we define SOURCE_DATE_EPOCH does not alter the time within the container image and what will be written in the logs. A simple way to solve this problem is to remove the logs after apt-get is done.

But there’s more to that:

$ docker run --rm <image> apt-cache policy gcc
gcc:
  Installed: 4:12.2.0-3
  Candidate: 4:12.2.0-3
  Version table:
 *** 4:12.2.0-3 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
        100 /var/lib/dpkg/status

Turns out that the gcc package does not come from Debian’s archives (https://snapshot.debian.org/), but from the main bookworm one (see http://deb.debian.org/debian bookworm/main). Granted, Bookworm is oldstable by now, and gcc does not change often, but that doesn’t mean that one of its dependencies can’t.

The proper solution here is another project by Reproducible Containers, repro-sources-list.sh. This script configures /etc/apt/sources.list and similar files for installing packages from a snapshot, using https://snapshot.debian.org in place of the default APT source.

Here’s a better Dockerfile using this script:

FROM debian:bookworm-20230904-slim
ENV DEBIAN_FRONTEND=noninteractive
RUN \
  --mount=type=cache,target=/var/cache/apt,sharing=locked \
  --mount=type=cache,target=/var/lib/apt,sharing=locked \
  --mount=type=bind,source=./repro-sources-list.sh,target=/usr/local/bin/repro-sources-list.sh \
  repro-sources-list.sh && \
  apt-get update && \
  apt-get install -y gcc && \
  : "Clean up for improving reproducibility (optional)" && \
  rm -rf /var/log/* /var/cache/ldconfig/aux-cache

This is now a bit-for-bit reproducible container image. As long as the Debian snapshot servers work, its digest is guaranteed to be sha256:b0088ba0110c2acfe757eaf41967ac09fe16e96a8775b998577f86d90b3dbe53.

Because we want to make sure that what we’re building now can be reproduced in a month or a year from now, we actually went ahead and created a nightly CI job that constantly builds this image and verifies its digest is the expected one, and it worked.

Well, until Feb. 20, 2025. But more on that below — we’re getting ahead of ourselves.

On build environments

Reminder: A requirement for reproducible builds is to have the same build environment and build instructions. For container images, the build environment is the base container image, and the build instructions are the Dockerfile. But that’s not the whole story.

What if we build the above image with Podman?

$ podman build --no-cache --source-date-epoch 1677619260 --rewrite-timestamp
[...]
4eb5ec336a90d4fb2ab7449782c3efdbfac8dcd11037b89213bf90ef2faec977

The digest is different. Let’s check how many differences diffoci reports:

$ diffoci diff <image1> <image2> | wc -l
847

Welp, that’s a lot of stuff there. The majority of those are filename reorders within the layer tarballs, some others are about .wh.* files, and some are about the image format itself (OCI vs. Docker). And yet, that does not mean that the container image is not reproducible. Quoting again from Reproducible Builds:

Reproducible builds does not mandate that a given piece of source code is turned into the same bytes in all situations. This would be unfeasible. The output of a compiler is likely to be different from one version to another as better optimizations are integrated all the time.

Instead, reproducible builds happen in the context of a build environment. It usually comprises the set of tools, required versions, and other assumptions about the operating system and its configuration. A description of this environment should typically be recorded and provided alongside any distributed binary package.

The point here is that the image builder, its version, and its arguments are part of the build environment and the build instructions. That’s why projects like Tor and Bitcoin use their own version of a static toolchain, possibly within a machine or container. And not only that, but OSes like Debian have CI tests that verify packages remain reproducible and don’t have regressions.

So, what happened on Feb. 20, 2025? BuildKit v0.20.0 was released, and our CI tests picked it up. This release had a small regression and added an extra field in the image config:

    "rootfs": {
      "type": "layers",
      "diff_ids": ["sha256:341de903..."]
-   }
+   },
+   "variant": "v8"

This was enough to affect the digest of the image. But because we had these CI tests in place, we detected it immediately and opened moby/buildkit#5774. The regression has been fixed, and the hash has remained unchanged ever since.

Introducing repro-build, a collection of helpers for reproducible images

We strongly believe that reproducible containers that are built and verified only once are prone to rot. If we want more people to engage with them, they need a toolchain to work with and an easy way to continuously reproduce them as part of their CI tests.

With this in mind, we created https://github.com/freedomofpress/repro-build, which holds:

A script that reproducibly builds container images using a static build environment.
Two GitHub Actions:
- One that reproducibly builds and pushes container images (and can be used in place of docker/build-push-action).
- One that rebuilds a container image and compares the digests.

Let’s see that in more detail:

The Python script

repro-build:

$ ./repro-build build --source-date-epoch 0 .
2025-02-24 09:17:48 - INFO - Build environment:
- Container runtime: docker
- BuildKit image: moby/buildkit:v0.19.0@sha256:14aa1b4dd92ea0a4cd03a54d0c6079046ea98cd0c0ae6176bdd7036ba370cbbe
- Rootless support: False
- Caching enabled: True
- Build context: ./repro-build
- Dockerfile: (not provided)
- Output: ./repro-build/image.tar

Build parameters:
- SOURCE_DATE_EPOCH: 0
- Build args: (not provided)
- Tag: (not provided)
- Platform: (default)

Podman-only arguments:
- BuildKit arguments: (not provided)

Docker-only arguments:
- Docker Buildx arguments: (not provided)

[...]

This is a simple script that:

Works with Docker and Podman, and ensures that BuildKit is used under the hood.
Pins BuildKit to a specific version.
Enforces the usage of a source date epoch or a human-friendly timestamp.
Removes some common sources of nondeterminism by rewriting timestamps and removing build provenance.

It’s our tested version of a static toolchain.

A replacement for the `docker/build-push-action` GitHub action that can reproducibly build container images

freedomofpress/repro-build@v1:

- name: Reproducibly build and push image
  uses: freedomofpress/repro-build@v1
  with:
    tags: ghcr.io/my-org/my-image:latest
    file: Dockerfile
    platforms: linux/amd64,linux/arm64
    source_date_epoch: 1677619260
    push: true

For simple image builds, you can consider this a drop-in replacement for docker/build-push-action, doing a similar job as the above script. We know, because we make sure that both this action and the above script create, bit-for-bit, the same images.

A GitHub action that rebuilds a container image and compares the digests

freedomofpress/repro-build/verify@v1:

- name: Verify image reproducibility
  uses: freedomofpress/repro-build/verify@v1
  with:
    target_image: ghcr.io/my-org/my-image:latest
    file: Dockerfile
    platforms: linux/amd64
    source_date_epoch: 1677619260
    runtime: podman

Reproducible container images

Our repro-build repo has a CI job that builds Debian images from snapshot repos nightly and then rebuilds them immediately, to make sure that they are reproducible. This CI job reuses the helpers we mentioned above, and produces container images that you can independently reproduce and verify.

Also, it has a CI job that still reproduces sha256:b0088ba0110c2acfe757eaf41967ac09fe16e96a8775b998577f86d90b3dbe53 every night, across container runtimes, BuildKit versions, and host images. You are more than welcome to copy our workflow and do the same for your images.

Future work

All this is exciting, but there is still room for improvement:

Include the build environment and instructions within the container image.
Implement a CI system where we can enroll reproducible images and continuously build and verify them, same as Debian has for their packages.
Improve ergonomics for multi-arch images.

We want to make it easy for folks to create their first reproducible container image, which is why we are offering the tools we use ourselves. We believe that with increased adoption of these practices and a systematic way to verify that they work, the container ecosystem will become more robust against supply chain attacks, which is something we deeply care about. So try them out and give us your feedback!

For more, view a 20-minute talk we gave on this subject at FOSDEM 2026.

Why we switched our container from Alpine Linux to Debian Stable

2026-02-05T00:00:00Z

We’ve been so busy bringing changes to fruition for Dangerzone this past year that writing about them was mostly an afterthought. So to make up for that, this article kickstarts our attempt in the coming weeks to document those modifications and their rationale.

One of these changes was the switch of our container image from Alpine Linux to Debian stable. Dangerzone uses a container as a sandbox, in order to open documents in a restricted environment and return a pixel buffer to the host. In this article, we’ll explain how we improved our image's footprint, security and build complexity, by switching from Alpine Linux to Debian Stable.

Our issues with Alpine

Dangerzone initially chose Alpine for its small size, security focus (musl libc, quick CVE fixes), and faster builds.

Dangerzone requires a container image with the following tools:

LibreOffice, for rendering office documents to PDF
PyMuPDF, for rendering PDFs to pixels
A Java runtime (OpenJDK), for the H2ORestart LibreOffice plug-in
Python, and the python3-magic package, to run our sanitization logic
A font that supports Chinese, Japanese, and Korean languages (Noto CJK)

The Alpine-based container image of Dangerzone 0.8.1 clocked in at roughly 1.1 GiB and included 283 packages (you can download it). This size is unexpected for an Alpine image with just five packages installed, so we dug into the package list and found the culprit: a significant number of seemingly unnecessary packages in a headless container context. We found graphical utilities like mesa, wayland-libs-server, and libx11, alongside multimedia frameworks like gstreamer.

Why are these installed? Unlike package managers in other distributions, Alpine's apk offers less granular control over dependencies. To the best of our knowledge, there's no straightforward way to install LibreOffice on Alpine without pulling in this extensive and unwanted dependency tree, nor is there an officially packaged headless variant of LibreOffice available in the Alpine repositories.

Security woes

The inclusion of GStreamer, for example, isn't theoretical bloat; it has directly led to security headaches. A GStreamer CVE necessitated a hotfix release (see security advisory 2024-12-24), and we narrowly avoided another due to a separate GStreamer vulnerability.

On a separate occasion, a critical vulnerability (CVE-2023-43115) was discovered in Ghostscript, a core library we used circa 2023, on Sept. 18. The Ghostscript authors fixed it in their main branch but didn't immediately cut a new release. This meant downstream distributors had to backport the patch themselves. Distributions like Debian and Fedora had patches available by mid-October. The Ghostscript authors finally released a new version on Nov. 1, which Alpine packaged on Nov. 9. By then, Dangerzone had released a new container image using the vulnerable Ghostscript version, forcing us to issue a hotfix.

One could argue that Alpine’s security model of following upstream brings in more security fixes early on, even if it didn’t work out for us in the above case. That’s a fair point, but we never used the edge distribution of Alpine anyway. We always used the stable distribution, in which the packages are not updated that often. Case in point, on May 28, 2025, Alpine Linux v3.21 still had LibreOffice 7.6.7.2, built on Nov. 11, 2024, i.e., roughly half a year without updates.

We must stress that keeping up with CVEs and triaging them requires a lot of effort and diligence for every package that Alpine Linux maintains, which can be taxing for a small team like Alpine’s. And Alpine's security team punches way above its weight (as highlighted in this insightful post). So this does not mean that Alpine’s or Debian’s security model is superior, only that Debian benefits from a larger number of maintainers.

Slower image builds

PyMuPDF isn't available in the standard Alpine repositories, so we installed it via PyPI. This is fine for amd64 builds where pre-compiled wheels are available. However, for arm64 architectures (like those found in Apple Silicon Macs), there's no musl-compatible arm64 wheel on PyPI. This forced our build process to compile PyMuPDF from source, a computationally expensive task that adds considerable time to builds, even with caching.

Switching to Debian Stable

Considering the above, we decided to switch to Debian Stable for the following reasons:

Smaller and leaner image: Using Debian's apt --no-install-recommends and headless packages (e.g., libreoffice-nogui), the Debian image is about 10% smaller (around 1 GiB) and contains only essential packages, drastically reducing the attack surface.
Reasonably good security: In addition to a smaller attack surface, Debian Stable improves our baseline security by patching known vulnerabilities as soon as they are out, or marking CVEs as "won’t fix." When our security scans start ringing, this helps with our triaging a lot.
Faster and simpler builds: Debian repositories include packaged PyMuPDF for all architectures, eliminating slow source compilation on arm64.

Another important factor is the potential for improved build reproducibility, a topic we are exploring in a separate effort.

P.S. For a more nuanced take, check an interesting discussion on this subject with GrapheneOS creator, Daniel Micay.

Pwning Santa before the bad guys do

2025-12-10T00:00:00Z

The backstory

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.

More info:

About Dangerzone

Safe Ride into the Dangerzone: Reducing attack surface with gVisor

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 🏁.

Get started

Fork https://github.com/freedomofpress/santa-pwn-dangerzone/.
Craft your document (see supported types) with the payload in it.

Encrypt the document using Kenny's public key.


gpg --import < kenny.asc
gpg --recipient kenny@santa.club --encrypt ./letter

Submit a PR and let the games begin! 🥳

FAQ

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.

Dangerzone 0.10.0 released

2025-12-02T00:00:00Z

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 want to thank trcrsired, ramones79, dhgatjeye, DeltaEpsilon19498, dstark, hwine, and sudwhiwdh for their feedback, questions, and contributions. Also, a big thank you to all the people who tried, and provided feedback for, the 0.10.0 release candidate.

If you have any issues, remarks, or questions, don't hesitate to let us know!

Dangerzone wants you! Help us test upcoming changes

2025-11-03T00:00:00Z

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.0 RC1 release:
Start Dangerzone for the first time.
- Wait while Dangerzone initializes.
- Select a document and convert it.
- Quit Dangerzone.
Start Dangerzone for the second time.
- You should be prompted about enabling automatic sandbox updates.
- Click “yes.”
- Quit Dangerzone.
Start Dangerzone for the third time.
- Dangerzone should verify, download, and install a new sandbox version.
- Once done, run a conversion.

During these steps, if you encounter any errors, please either email us at support@dangerzone.rocks or open an issue in our bug tracker.

Thanks a lot!

Dangerzone 0.9.1 released

2025-07-10T00:00:00Z

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.

Dangerzone team at Dataharvest '25

2025-05-22T00:00:00Z

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:

Signal link: https://signal.me/#eu/L3_X6xwgCV4FhmHR8_C8qzIZHJc-m6xxdSh6AxHV_dc-cUddySNCXaZxKiGp410i
Signal username: @dzdh.25

Dangerzone 0.9.0 released

2025-04-09T00:00:00Z

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)

Platform support updates

Add support for Fedora 42 (#1091)
Add support for Ubuntu 25.04 (Plucky Puffin) (#1090)
Drop support for Ubuntu Focal, since it's nearing end-of-life (#1018)
Drop support for Fedora 39 (#999)
Add support for Python 3.13 (#992)

Fixed

Fix our Debian “trixie” installation instructions using Sequoia PGP (#1052)
Fix the way multiprocessing works on macOS (#873)
Update minimum Docker Desktop version to fix an stdout truncation issue (#1101)

Community contributions

For this release, we had some help from community members. We want to thank:

@sudoforge for making changes to how we refer to our Debian base image (#1116 and #1118)
@jkarasti for using Ruff to lint our code (#1029) and for upgrading our Windows installer to Wix Toolset 5 (#929)
@DeltaEpsilon19498, @sudwhiwdh, @mkonia, @randomhydrosol, @thisislola, @t32r2r4653g21es1, @Rexless505, @rtfmkiesel, @Hitmanforrent and @charginglabrador for letting us know about issues they faced, and for some proposed changes. Don't hesitate to do so if you face any issues!

For a full list of the changes, see our changelog

On a final note, the Windows .msi package has been built from a different commit (to include some last minute changes) that you can check out here.

Upcoming Docker Desktop disruptions for macOS users

2025-01-27T00:00:00Z

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.

If the malware notification persists, you can consult this troubleshooting guide.

Dangerzone 0.8.1 is out

2024-12-24T00:00:00Z

This is a security release that mainly addresses CVE-2024-47538, CVE-2024-47607 and CVE-2024-47615.

Our security advisory follows:

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.

For a full list of the changes, see our changelog.⏎

Dangerzone 0.8.0 is out

2024-11-06T00:00:00Z

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.
Add support for Fedora 41 (#947)
Add support for Ubuntu 24.10 (#954)
Drop support for Ubuntu Mantic (23.10), since it's end-of-life (#977)

Community contributions

For this release, we had some help from community members. We want to thank:

@bnewc, who improved the interface, effectively preventing our users from using illegal characters in the output filename (#362)
@amnak613, who allowed us to report some stray conversion errors (#776)
@jkarasti, who helped us change the signature mechanism from SHA1 to SHA256 for our Windows installer (#931)

On a final note, the container image embedded in the Debian packages differs from the one attached to the release. You can have a look at issue #988 for more details.

As usual, for a full list of changes, see our changelog.

Dangerzone 0.7.1 is out

2024-10-01T00:00:00Z

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.

Safe Ride into the Dangerzone: Reducing attack surface with gVisor

2024-09-23T00:00:00Z

This article was written in collaboration with Google's gVisor team and cross-posted on the gVisor blog.

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.

If you’re an existing Dangerzone user on 0.7.0 scratching your head and thinking “Well, I haven’t noticed anything different,” then first of all, “yay!” That was the plan. And second, because the plan worked so deviously well, this change has probably flown under the radar, so here are more than 3,000 words to amend this.

The rest of the article dives deep into Dangerzone’s security, describes how gVisor works as a technology, and explains how Dangerzone’s security profile has changed after this integration. Expect some technical terms and nerdery.

How Dangerzone works

Dangerzone’s purpose is to sanitize documents of any elements that can compromise your computer or the source’s identity (think malware and document metadata). To do this, it first renders the document into visual data (pixels) and then turns this visual representation back into a readable document file. The first part of this process (rendering the document into pixel data) is the most security-critical part and, for the purpose of this article, we will zoom in on just this.

💡 For a broader understanding of how Dangerzone works, we encourage you to read the “About Dangerzone” section on the Dangerzone website. Props to the Qubes OS team, who first popularized the concept that is now their TrustedPDF feature.

In order to support a wide variety of document formats (PDF, office documents, image formats, etc.), Dangerzone needs to open them with software that potentially has security bugs. That may result in compromise of the user’s device, personal files, and communication. This is the same risk you face when you use your computer to open attachments from unknown sources. Dangerzone needs to somehow isolate this process from the rest of your computer, so that anything it does cannot "get out of the box".

Dangerzone’s isolation relies on Linux containers. Containers are very handy for two things: ensuring that they work the same way across operating systems and separating the container from the rest of the machine.

Outline of how Dangerzone uses containers to render a document into pixels.

Dangerzone benefits from both of these aspects: Development and testing are made easy by using containers’ cross-platform compatibility; and containers’ security, especially how Dangerzone configured them, offers strong isolation guarantees. The security audit Dangerzone passed recently is a testament to this.

In computer security, the gold standard of isolation is virtual machines. VMs are what they sound like: a computer running within a computer. When running a virtual machine, the "host" (outer) machine is protected from the action of the "guest" (inner) virtual machine. This is why the TrustedPDF feature of QubesOS uses disposable VMs as its isolation mechanism. Dangerzone also tried to use VMs in the past, but implementing them in a multiplatform way proved high-maintenance. Thus, Dangerzone switched back to containers, but the team always wanted to improve Dangerzone’s security properties.

💡 How does Dangerzone use Linux containers on Windows and Mac OS? It requires Docker Desktop, which runs Linux inside a virtual machine and then runs Linux containers in it.

Dangerzone’s attack surface

To understand how to protect Dangerzone users from exploits, it’s useful to think like an attacker. When Dangerzone processes a malicious document within a container, the first point of the attack is the application that opens the document. Dangerzone is designed with the assumption that determined attackers will find a vulnerability in such applications and take control of them (check out this security advisory from the Dangerzone team about a recent, critical LibreOffice vulnerability). From there on, the next point of attack is to circumvent the Linux kernel protections for the container or directly compromise the Linux kernel.

The Linux kernel, even in Docker Desktop VMs, is a very privileged component. It has access to sensitive data, such as other files on the user’s machine or the user’s browser history, and to your computer’s network.

Processes in containers interface with the Linux kernel through system calls and virtual filesystems. Attackers can try to take advantage of security bugs in the above interfaces. So it is critical to limit the container’s access to the Linux kernel. We call this the container’s attack surface. The smaller it is, the more secure a system is.

Dangerzone tries to reduce its attack surface by multiple mechanisms available to Linux containers:

Removal of process capabilities. This reduces the set of permissions the container has in the kernel.
Removal of network access. This prevents the container from accessing the internet to exfiltrate document data.
Filtering of allowed system calls through seccomp. This reduces the set of system calls (i.e., types of actions) that the container is allowed to make to the kernel.
Minimal user ID mapping. This reduces the risk that the container may access files belonging to users other than the Dangerzone user on the same computer.

💡 Check out the above protection measures in Dangerzone’s codebase.

Container protections employed by Dangerzone prior to 0.7.0.

This provides the container with a fair degree of isolation from the Linux kernel. However, some attack surface remains, since:

The computer’s user is still mapped in the container. This means that a container escape would allow the attacker to access the user’s personal files (browser data, documents, etc.); it would be more isolated if that were not the case.
The system call filter is still relatively permissive. The specific system calls that are blocked are dependent on the container manager and version in use (see Docker’s filters, for example), but in general, the system call filter only blocks obscure or system-admin-only system calls (e.g., rebooting, modifying systemwide settings). It does not block containers from opening arbitrary files or interacting with the network stack, which can still be vectors for security bugs.
The container’s root filesystem, while ephemeral, is still writable. This allows attackers to exploit potential vulnerabilities in Linux’s filesystem stack.
The Linux kernel is still exposed to the container. While it is possible to reduce the attack surface available to the container to a minimum, this architecture still requires that the container have direct access to Linux via system calls. So if a Linux security bug can be triggered within the set of filtered system calls, an attack may still be successful.

Dangerzone’s attack surface prior to 0.7.0, illustrated.

We’ve wanted to mitigate these risks for a while now, but we had to do so in a cross-platform way and without burdening the user with administrative tasks.

Enter gVisor.

What is gVisor?

gVisor is a container security solution. In short, it makes it much harder for malicious code to break out of the container boundary. This was a great fit for Dangerzone’s security needs.

An open source project written in Go, gVisor was released in May 2018 by Google under the Apache 2.0 license. It runs on Linux and integrates with all popular container management software, such as Docker, Podman, or Kubernetes. At its core, gVisor is an application kernel that implements a substantial portion of the Linux system call interface. This means gVisor sits between a container and the Linux kernel and plays both roles: from the container’s perspective, gVisor acts as a kernel, but from Linux’s perspective, gVisor is just a regular application. That means the container can no longer directly interface with the Linux kernel. This is a massive reduction in attack surface.

If you’re new to gVisor, the concept of not interfacing with the Linux kernel at all may seem either quite vague or overly restrictive. That’s normal, so let’s toy with this concept a bit for fun and illustrative purposes. Here’s a perfectly normal sentence:

“A process opens a document on the filesystem”

And here’s how gVisor warps every single word in that sentence:

“on the filesystem”: Nope, no such thing. The gVisor container runs in an empty filesystem.
“opens a document”: Nuh-uh, the gVisor container does not even have the permission to perform the open system call. Also, there are no files to open in the first place.
“A process”: Amusingly, the gVisor container does not even have the ability to perform the exec system calls. From the Linux kernel’s perspective, the gVisor “process” looks like a typical multithreaded program, even while many independent processes are running within the gVisor sandbox.

And yet, gVisor can containerize most applications without issue. For example, the Dangerzone container image was not altered at all for the gVisor integration.

So what’s going on here?

gVisor manages to pull the above trick with the help of two components:

Sentry is the component that runs the containerized application. It intercepts every system call that the application makes and reimplements it in Go. As part of this, it may decide to do one or more system calls to the host Linux kernel. However, it’s heavily restricted with a strict seccomp filter (that’s why system calls like open, socket, or exec are not allowed).
Gofer is a component that runs outside the container and is responsible for filesystem operations. The sentry may make I/O requests to the gofer. The gofer will independently validate them, then perform these I/O operations on the container’s behalf (that’s how the container can read files from the host filesystem, even though open is not allowed from the sentry).

The above components are managed by a container runtime called runsc, which exposes the same interface as other container runtimes. This means it can be integrated in other container management software like Podman, Docker, or Kubernetes.

gVisor intercepting system calls from a sandboxed application

With the above architecture, gVisor blue-pills the application into thinking that it interacts with a regular Linux kernel. In practice, gVisor reimplements most basic features that Linux provides (memory management, scheduling, system call interface, I/O, networking), and only issues system calls to the Linux kernel when truly necessary, such as when it needs information from it (e.g., reading the document to be converted by Dangerzone).

The gVisor kernel is designed to be difficult to break out of. gVisor is written in Go. Many of Linux’s security woes stem from its use of C, which is a memory-unsafe language. By contrast, gVisor is a regular Go application and inherits Go’s memory safety features. This eliminates a large class of security vulnerabilities.

The gVisor kernel also has a much smaller code footprint, because unlike a traditional kernel like Linux, it does not have to deal with things like hardware devices, and only implements a subset of the Linux kernel interface that is sufficient for most applications to work in practice. Because of its smaller implementation, there are fewer moving parts to juggle between, and thus fewer opportunities for bugs to exist.

Beyond its kernel indirection, gVisor also hardens itself through a bunch of security measures on startup, some of which are similar to regular containers:

Isolation: Running in its own set of namespaces (user namespace, process namespace, network namespace, etc.) to further isolate it from the host.
File access prevention: Running in its own root with exactly zero host files initially visible to it.
Privilege revocation: Dropping all capabilities it has to ensure it runs with the least privileges.
System call filtering: Setting a strict system call filter tuned for the gVisor Sentry specifically.
- As mentioned, unlike Docker or Podman’s default system call filter, this is a very restricted set of system calls. This filter blocks basic operations like opening files, creating network connections, or executing other processes. The presence of this filter does not prevent use of these system calls from within the gVisor sandbox; instead, the gVisor kernel intercepts and reimplements system calls internally without needing to make a “real” system call out to the Linux kernel.
The gofer also uses all of the above techniques to isolate itself as much as possible.

The gVisor kernel has been battle-tested by Google and other large companies like Ant and Cloudflare. For example, searching for the text "GKE Sandbox" (which uses gVisor) on the GKE security bulletin shows how often Linux kernel vulnerabilities occur but that gVisor prevents. gVisor is also continuously fuzz-tested for bugs using Syzkaller, an automated kernel security testing tool.

What’s the catch here? Applications that perform lots of system calls and heavy I/O will have some degraded performance. Also, applications that rely on exotic features by the Linux kernel may not work. In practice, the majority of applications do not suffer from this issue.

Integrating gVisor with Dangerzone

So, gVisor looks like a strong candidate for Dangerzone, which is a relatively simple application that does not perform a heavy amount of system calls. Also, gVisor conveniently offers a container runtime that is a drop-in replacement for use with Docker/Podman. Therefore, integrating these two projects should be really simple, right?

Well, not so fast.

Dangerzone is a multiplatform application, and most of its users are on Windows and macOS. Integrating gVisor just for Linux would not cut it. At the same time, gVisor works strictly on Linux systems, so we are at an impasse.

In what is, in retrospect, a classic case of Maslow’s hammer, we decided to solve our container problems with yet another container. The idea is simple; why not containerize gVisor and make it run on Docker Desktop? After all, as we already pointed out, Docker Desktop runs Linux inside a virtual machine.

By doing so, Dangerzone now has two containers with different responsibilities:

The outer Docker/Podman container acts as the portability layer for Dangerzone. Its main responsibility is to bundle the necessary config files, scripts, and programs to run gVisor. It’s also responsible for bundling the container image that gVisor will spawn a container from.
The inner gVisor container acts as the isolation layer for Dangerzone. Its sole responsibility is to run the actual Dangerzone logic for rendering documents to pixels.

Outline of how gVisor integrates with Dangerzone. There are now two nested containers, and each one brings its own protections. Usage of LibreOffice is implied.

Running gVisor inside a container came with its own set of challenges:

The Docker/Podman’s seccomp filter must allow the ptrace system call. We found that recent Docker Desktop versions and Podman version >= 4.0 have a seccomp filter that allows this system call. For older versions, we specified a custom seccomp filter that allowed it.
gVisor cannot run under SELinux in enforcing mode under default settings, so we labeled the container with container_engine_t (see GitHub issue #880).
The Docker/Podman container must run with the SYS_CHROOT capability. This is needed by gVisor to restrict its own access to the filesystem before it starts document processing. Other than that, the outer container drops all other capabilities and privileges.

💡 You can find more details about this integration in the Dangerzone’s gVisor design doc.

Dangerzone protections

We talked about Dangerzone’s original attack surface, and how we integrated gVisor to reduce it. In practice though, in what ways is Dangerzone better off than before? Well, if the Matryoshka containers are giving you a headache, or you just skimmed to this section (no shade), here’s how the new Dangerzone protections fare against the previous version, and the default protections of Linux containers:

🛡️ Protections	Default	Dangerzone (0.6.1)	Dangerzone + gVisor (0.7.0)
🐧 Linux kernel	Exposed	❌ Exposed	✅ Not exposed
🛠️ System call filter	Moderate	❌ Moderate	✅ Strict
🛠️ Capabilities	Default	✅ None	✅ None
👤 Host user	Mapped	❌ Mapped	✅ Unmapped
📁 Filesystem	Exposed	❌ Writable	✅ Read-only
🌐 Network	Exposed	❌ Disabled	✅ Disabled at two levels
🔒 SELinux	Yes (`container_t`)	✅ Yes (`container_t`)	✅ Yes (`container_engine_t`)
🖥️ Hardware Virtualization	None	❌ None	❌ None

As you can see, the most important protection is that the document conversion process no longer has access to the Linux kernel. Instead, it only has access to the gVisor kernel (in the Sentry), and must break out of it before it can access the Linux kernel that it (prior to gVisor integration) had access to.

Additionally, Dangerzone itself configures the two containers to be more secure with:

Privilege revocation: Removing all privileges and capabilities of the document conversion process in the inner container, and minimizing the set of capabilities granted to the outer container to just SYS_CHROOT and no other.
File modification prevention: Making the inner container’s root filesystem read-only.
User isolation: Running the outer container in a user namespace that does not include the Dangerzone UI user (available in Linux distributions with Podman version 4.1 or greater).
Kernel security settings: Setting the outer container’s system call filter and SELinux label settings.
Host access prevention: Not using any mounts in either container.
Network access prevention: Disabling both containers’ ability to use networking.

Explanation of how Dangerzone’s latest protections limit its attack surface.

Conclusion

Integrating the gVisor project with Dangerzone was very exciting: It’s a good example of how gVisor can add another line of defense to a project without requiring application-level changes.

At the same time, the design complexity of the Dangerzone project increased a bit, mostly to cater to its cross-platform nature, but honestly not that much. Dangerzone is strongly security-focused, so we believe it’s worth the cost.

We hope that this article demystifies some security aspects of containers, so that you can use Dangerzone and gVisor with even more confidence. Feel free to reach out to us with any questions or comments:

Welcome to the Dangerzone

2024-08-22T00:00:00Z

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!

Dangerzone

April is the cruelest month

How Dangerzone distributes sandbox updates

Checking image provenance

Reproducible images

Signing an image

Verifying the signatures

Storing signatures

Wrapping up

Reproducing the reproducible images

Let’s create a reproducible image

On build environments

Introducing repro-build, a collection of helpers for reproducible images

The Python script

A replacement for the docker/build-push-action GitHub action that can reproducibly build container images

A GitHub action that rebuilds a container image and compares the digests

Reproducible container images

Future work

Why we switched our container from Alpine Linux to Debian Stable

Our issues with Alpine

Security woes

Slower image builds

Switching to Debian Stable

Pwning Santa before the bad guys do

The backstory

The challenge

The bounty

Get started

FAQ

1. Why do we encrypt documents when we submit them?

2. What happens on a successful submission?

3. Can I experiment with this challenge locally?

4. Does my submission have to pass the sanitization step?

5. Can I submit any other types of issues?

6. Are we living in such desperate times that people will burn a gVisor/kernel 0-day for anything less than six figures?

7. Is this a CTF challenge, or a bug bounty program?

Dangerzone 0.10.0 released

Dangerzone wants you! Help us test upcoming changes

Help us test Dangerzone!

Dangerzone 0.9.1 released

Dangerzone team at Dataharvest '25

Dangerzone 0.9.0 released

Platform support updates

Fixed

Community contributions

Upcoming Docker Desktop disruptions for macOS users

Am I affected by this?

What can I do?

Dangerzone 0.8.1 is out

Summary

How does this impact me?

What do I need to do?

Dangerzone 0.8.0 is out

Platform support updates

Community contributions

Dangerzone 0.7.1 is out

Safe Ride into the Dangerzone: Reducing attack surface with gVisor

How Dangerzone works

Dangerzone’s attack surface

What is gVisor?

Integrating gVisor with Dangerzone

Dangerzone protections

Conclusion

Welcome to the Dangerzone

A replacement for the `docker/build-push-action` GitHub action that can reproducibly build container images