3 high vulnerabilities / 1 unclassified vulnerability found by Docker Scout (Docker Desktop)

[salevajo]

Docker Desktop is showing some vulnerabilities within dangerzone (v0.5.1) docker images.

Provided links are:

CVE-2023-49468⁠ CVE-2023-49467⁠ CVE-2023-49465⁠ ZDI-CAN-22300⁠

[deeplow]

It's good to see others are also keeping an eye on Dangerzone security! We also have our own monitoring in place and actively keep track of the higher severity vulnerability -- the last release (v0.5.1) was exactly to bump our container image due to a critical CVE in the container image that affected Dangerzone. Generally that's our threshold for a new release. We'd like to lower this threshold and I'll speak at the end about the high-level steps for that to happen.

Designed to Withstand these Vulnerabilities

(You're probably already aware of this but I'll state it anyway since without context the above may seem dismissive about security.)

It should be said that Dangerzone is designed to withstand vulnerabilities in the container image. Dangerzone assumes that the document can be malicious and execute code. By converting the images to pixels and then reassembling it ensures that the final output file is not infected. So these kinds of vulnerabilities at most make an attack slightly easier to pull off, but an attacker still has to chain a remote execution vulnerability with a container escape. In other words, a CVE in the container image alone does not mean that Dangerzone was compromised. But we do see security in depth as a priority as well, so this is something we want to tackle soon.

Steps towards faster container image releases

We are working towards being able to do more frequent container image releases. At the moment the docker image "bundled" into each release. So we have to go through our full Quality Assurance and multi-platform release process to make a new release. But in the future we will probably detach these two.

To make it possible we first need to move the "Pixels to PDF" part to the host (it currently also happens in a second container due to cross-platform compatibility), and we're getting close to that goal. Once that's done we can alleviate the release burden since the container image can be less trusted enough to consider even hosting on something like Docker Hub (but we'd probably host it ourselves). We can then set up some sanity-check tests to ensure the new container image behaves well and push it out to users faster. Theoretically if something gets broken we can also quickly fix it.

I hope I have addressed your concerns about these vulnerabilities. If there are no further concerns, I'll close the issue.

[apyrgio]

Also, two more things I wanted to address:

1. These four CVEs have High CVSS score, not Critical. As @deeplow said, at the moment we're trying to tackle just Critical CVEs.
2. These CVEs affect video files (H.265 and AVI). My understanding is that the conversion process does not render videos, and thus trigger this CVE. It should just keep the thumbnail in place, which is created by the document's author. Note that this is not definite, just my understanding from experimenting with embedded video files on documents.

Thanks again for letting us know about these CVEs. We take them very seriously and we are actively trying to improve our posture here.

[deeplow]

Closing this issue since with the vulnerabilities in question should have been addressed with the release of Dangerzone v0.6.0.

Since our last comment, Dangerzone has also gone through an audit, where a critical vulnerability was found. This discovery was classified by the auditors as informational, adding to our point that Dangerzone's sandboxed approach reduces the impact of said vulnerabilities.

Regardless, we appreciate the scrutiny and will work towards simplifying the release process as described before, in order to make faster container image releases to address the vulnerabilities that will inevitably accumulate.