Open maltfield opened 1 month ago
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:~$
I created this question on SE to see if there's already a tool available to scan or sanitize .stl
files
I opened a feature request for Dangerzone to support .stl
files:
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
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
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.
@goldfishlaser I think an STL sanitizer would make a great tool to present at DEF CON :P
I don't disagree. Their paper was pretty entertaining.
I plan to get my next free ticket by becoming a goon though :P
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 https://github.com/BusKill/usb-a-magnetic-breakaway/issues/10#issuecomment-2319159714, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAER7EBRG765RRL5IJSHY4DZT6NVPAVCNFSM6AAAAABLNGH6HOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJZGE2TSNZRGQ . You are receiving this because you were mentioned.Message ID: @.***>
This issue will track the effort to implement some mechanism to scan (or sanitize)
.stl
files committed in PRsProblem
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 deletionsThe 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-38072Solution
We need either:
.stl
files, or.stl
files (eg something like qvm-convert or Dangerzone), or.stl
files into this repo (perhaps we can use a CI process to generate them from the source.scad
files?)