Request: Support for STL files

[maltfield]

This ticket is a request to add support to dangerzone to sanitize .stl files.

Why?

I maintain a security-critical GitHub repo, which includes designs for open-source hardware USB dead man switches.

Our hardware designs are maintained in OpenSCAD .scad files and .stl files. The former (.scad files) are trivial to visually diff and check for potentially-malicious content. The later (.stl files) are plaintext, but nearly impossible for a human to read-through and scan for potentially-malicious content.

• https://github.com/BusKill/usb-a-magnetic-breakaway/issues/10

The concern is not unfounded: there has been at least one historically-known vulnerability where a maliciously-crafted .stl file could be used to trigger a heap buffer overflow. This was identified as a HIGH severity (8.8/10) bug by NIST in CVE-2022-38072

• https://nvd.nist.gov/vuln/detail/CVE-2022-38072

As a FOSS hardware project, it would be extremely useful if we had some way to pass .stl files committed to us in a PR through dangerzone to be sanitized before merging into our repo.

Solution

A solution to this would be for dangerzone to support sanitizing of .stl files.

[maltfield]

See also:

• https://security.stackexchange.com/questions/277974/how-to-scan-and-sanitize-stl-files

[apyrgio]

Huh, that's an interesting suggestion. I think a bit of a primer of how Dangerzone performs sanitization is needed here, and then I'll ask some questions:

Sanitization Primer

The main idea behind Qubes' TrustedPDF (and by extension Dangerzone) is that santization needs to happen in two stages:

1. The first stage takes a file in a format that can be malicious (e.g., PDFs, Word documents). Dangerzone then opens this file within a strong sandbox, and converts it to a safe(r) file format. We consider RGB pixels to be safe enough for parsing.
   • This is kind of a tricky detail. If Dangerzone returned a sanitized PDF or Word document, then whose to say that the code within the sandbox was not exploited, and the attacker feeds us back the unsanitized document?
2. The second stage takes the product of the first stage, does a simple parsing, and then creates a new file out of it, that is easier for the user to use. In our case, it is an OCRed PDF document.
   • That's an important detail as well. The returned file must be something that users can actually use, to avoid the temptation of opening the original, untrusted file.
   • ... and thus, Calc sheets are our cryptonite.

Do the above make sense? Note that there are other ways to perform sanitization of course (see "Content Disarm & Reconstruction"), but they have other cons.

Questions

Now, with the above in mind, let's see how we could do this in Dangerzone:

1. We need an intermediate, safe format for .stl files, that will be the product of the first stage of the conversion. What can we use there? I see some mentions for an ASCII .stl file, but is it actually safe?
2. Suppose that the result of the first stage of the conversion is something in pixels, e.g., a rendering of the .stl file from various angles. Can we reconstruct an .stl from such a render?

[maltfield]

Oh, I didn't realize you were producing simple RGB-image PDFs from Open/Libre Office documents too. I thought you were doing some sanitation like stripping macros.

1. We need an intermediate, safe format for .stl files, that will be the product of the first stage of the conversion. What can we use there? I see some mentions for an ASCII .stl file, but is it actually safe?

Good question. I'm still waiting to hear back from TALOS to see what their maliciously-crafted .stl file looked-like, but I'm wondering if it was just a product of a fuzz test, such that it very much deviated from the standard plaintext syntax, and a sanitation option might (at least) include to [a] convert binary .stl files to plaintext .stl files and [b] confirm that their syntax is valid.

But that's quite a bit different if dangerzone currently just literally converts everything to a simple image and puts it in a PDF file.

2. Suppose that the result of the first stage of the conversion is something in pixels, e.g., a rendering of the .stl file from various angles. Can we reconstruct an .stl from such a render?

Well, there is an equivalent: render the stl file (in your untrusted, disposable VM), take a screenshot from the [a] top, [b] bottom, [c] left, and [d] right. Then save those images to a 4-page PDF.

I doubt there's a way to go from images back to some 3D file (like an .stl file). But this would be roughly equivalent to trying to go from "screenshot of spreadsheet" back to "ods file with (now lost) formulas"

But .stl files are generally already an intermediary format. In our case, we generate .stl files from .scad files (scad files being human-readable and trivial to review in a PR). So this type .stl -> .pdf would actually be quite useful, since there isn't much of a need to go from .stl back to editor.