Detect Malicious STL files

[maltfield]

This issue will track the effort to implement some mechanism to scan (or sanitize) .stl files committed in PRs

Problem

Today @goldfishlaser and I realized that we don't have a system in-place to be able to scan and/or sanitize .stl changes committed by contributors. For example, this simple PR resulted in a change to an .stl file with 39,614 additions and 39,726 deletions

39,614 additions, 39,726 deletions not shown because the diff is too large

• https://github.com/BusKill/usb-a-magnetic-breakaway/pull/8/files

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

Solution

We need either:

1. some way to scan .stl files, or
2. some way to sanitize .stl files (eg something like qvm-convert or Dangerzone), or
3. we need to have a policy not to accept .stl files into this repo (perhaps we can use a CI process to generate them from the source .scad files?)
4. something else that adequately mitigates this risk

[maltfield]

Here's an example real-world file change (taken from the PR mentioned in the OP)

wget -O pre.stl https://raw.githubusercontent.com/BusKill/usb-a-magnetic-breakaway/master/Goldfishlaser%20Version/CAD%20Files/intermediary%20design%20files/usbamagb_v04.0.stl
wget -O post.stl https://raw.githubusercontent.com/goldfishlaser/usb-a-magnetic-breakaway/ee7b7862f07bda4b132e177e7807fb50050db464/Goldfishlaser%20Version/CAD%20Files/intermediary%20design%20files/usbamagb_v04.0.stl

diff pre.stl post.stl

The good news is that the .stl file is just a plaintext file, but the bad news is that the diff is >100,000 lines long. The actual number of lines changed is almost 50,000.

user@disp2114:~$ file pre.stl 
pre.stl: ASCII text
user@disp2114:~$ 

user@disp2114:~$ file post.stl 
post.stl: ASCII text
user@disp2114:~$ 

user@disp2114:~$ diff pre.stl post.stl | wc -l
106982
user@disp2114:~$ 

user@disp2114:~$ diff -y --suppress-common-lines pre.stl post.stl | wc -l
44661
user@disp2114:~$ 

[maltfield]

I created this question on SE to see if there's already a tool available to scan or sanitize .stl files

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

[maltfield]

I opened a feature request for Dangerzone to support .stl files:

• Request: Support for STL files freedomofpress/dangerzone#876

[maltfield]

I read the TALOS-2022-1594 report published in April 2023 that describes the heap buffer overflow vulnerability in ADMesh v0.98.4 due to a maliciously-crafted .stl file, but unfortunately they didn't publish an example of the .stl file.

I'm curious if this issue can only be caused by binary files, so maybe it's sufficiently mitigated by only accepting plaintext .stl files?

Or maybe the maliciously-crafted .stl file doesn't comply with the STL syntax, such that we can greatly reduce our risk by simply doing a syntax check on a plaintext .stl file (refusing to merge if there's errors)?

I asked Talos and the ADMesh dev to please publish the maliciously-crafted .stl file, so that we could study it

• Security bug admesh/admesh#60 (comment)

[maltfield]

See also:

• https://graphicdesign.stackexchange.com/questions/165755/verify-syntax-of-stl-file

[maltfield]

See also Export STL file (in plaintext) in FreeCAD

• https://forum.freecad.org/viewtopic.php?p=773391#p773391

[maltfield]

See also Writing an .stl file from scratch

• https://danbscott.ghost.io/writing-an-stl-file-from-scratch/

[goldfishlaser]

See https://doi.org/10.1145/3471621.3471843

Edit: they mention a follow up paper and I found it but its not free: https://doi.org/10.1145/3626232.3653276

[maltfield]

Interesting. Quick review of the linked file above describes methods of using .stl files as a means to in/exfiltrate data with (encrypted) steganographic data encoded inside of objects. They describe use-cases of "watermarking" 3D IP. Blech.

Anyway, the relevant bit that I see is their Three Contexts of Distinguishability and Robustness Against STL File Sanitation sections, where they talk about how to sanitize STL files.

each and any of these can determine a defender’s ability to detect the subliminal steganographic channel and even extract the encoded message for further analysis. Such detection is critical for follow-on security procedure...
...
With the proposed bit encoding scheme, the “sanitization” of STL files is fairly simple and straightforward. Defenders can overwrite all facets in the file with either the same value (0 or 1) or with a completely random value. As mentioned before, due to the semantic equivalency of the vertex cyclical rotation, it should not affect the described 3D object geometry. However, while theoretically sound, this assumption needs to be verified empirically; we plan to conduct such an investigation in a follow-up work. Consequently, the proposed approach is fragile, and can be easily disrupted by the described sanitation approach.

We should note, however, that alternative encoding techniques are possible (see Appendix A.1). Similar to distinguishability, each of these encoding techniques would require a different sanitation approach. Any technique meeting the same criteria as our selected encoding, non-interference with printed geometry, would exhibit the same level of fragility against sanitation.

Alternatively, incoming and outgoing STL files can be read into a CAD program and re-saved, assuming that this step will remove all possible steganographically encoded information, regardless of the encoding primitives used. However, if such a CAD program is trojanized, it can be used by a malicious actor for the encoding of secret information instead of removing it.

[maltfield]

@goldfishlaser I think an STL sanitizer would make a great tool to present at DEF CON :P

[goldfishlaser]

I don't disagree. Their paper was pretty entertaining.

[goldfishlaser]

I plan to get my next free ticket by becoming a goon though :P

[goldfishlaser]

I still don't think banning/fearing STLs is the move though.

…

On Thu, Aug 29, 2024, 18:25 Michael Altfield ***@***.***> wrote: @goldfishlaser <https://github.com/goldfishlaser> I think an STL sanitizer would make a great tool to present at DEF CON :P — Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAER7EBRG765RRL5IJSHY4DZT6NVPAVCNFSM6AAAAABLNGH6HOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJZGE2TSNZRGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>