New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Out-of-bounds memory access in DXF loader (path identification) #4037
Comments
|
I see lots of warnings, but no crash on MacOS with the current development code. |
|
And there are at least 3 places in the code with the same fragility. I hope this doesn't break any import tests... Good, it doesn't break any of the tests. I still want to test this with more files, though. |
|
I thought maybe we could catch the error earlier in the process (when adding lines), but so far I haven't figured out a way to do it. BTW - the second example actually hits the same sort of error in a different place, so thanks for providing both! |
|
OpenSCAD's DXF support is really a rather large piece of technical debt. At some point it's worth digging further into replacing it with an existing library, see https://github.com/openscad/openscad/wiki/Project%3A-Improve-DXF-import-and-export |
|
Ok, I have a fix that is safe, if not optimal. Trying to catch the error earlier runs into a lot of code that I cannot decipher easily (it's a huge state machine, with many inter-dependent arrays of data) -- so I cannot say that any changes there would be safe. |
|
Thanks for taking a look at this issue! Has the fix been merged? This vulnerability has been assigned CVE-2022-0496. |
|
No, the fix has not been merged. It's waiting on other pull requests to be merged (which have been sitting for 3 weeks). |
Add safety (test for, and continue past, bad indices). Report warnings about bad indices Add variables just to make the array indices easier to read and debug.
|
Now it has been merged! yay! |
|
Hold the horses, it will be in a bit :) |
Add safety to line lookups in DXF import (fixes #4037).
Summary
A DXF-format drawing with particular (not necessarily malformed!) properties may cause an out-of-bounds memory access when imported using
import().Vulnerable versions
Steps to reproduce
Two Proof-of-concept files are provided.
oob_dxfdata_505is larger, but more reliably reproduces the fault.oob_dxfdata_k5is my attempt at a minimal working example, but only reliably crashes the linux build from the latest commit on themainbranch (i.e. it does not crash in the windows release). Both illustrate the same crash, so I expect the_minexample to be more helpful in testing.oob_dxfdata_505.zip, the larger messier p-o-c
oob_dxfdata_k5.zip, the smaller p-o-c
.scadfile in OpenSCADAlternatively, for headless operation:
openscad --export-format stl -o /dev/null oob_dxfdata_k5.scadScreenshot
Cause
I haven't quite been able to wrap my head around the DXF parser yet, but the OOB access occurs in
src/dxfdata.ccon one of the lines 470, 475, 505, or 510 depending on the input file.It appears to be related to the fact that if multiple line segments share points in common, they are merged into contiguous paths. As a part of this, The ADD_LINE macro manipulates the
grid.data<>andlines<>structures. By creating lines either in theENTITIESsection of the DXF file or outside of it, an attacker is able to ensure that thegrid.dataentry created on line 108 points to an index inlineswhich never becomes valid.On line 470 (and the others listed above), this value (
k) is used as an index intolines, out of bounds.Impact
It appears that the out-of-bounds data can only be read, and not written. An out-of-bounds read does not expose a security vulnerability on its own, but can be used to bypass automatic security features such as stack canaries and pointer encryption.
Proposed mitigation
The algorithm employed in
DxfData::DxfDataneeds to be revised to prevent this type of aliasing. Without more insight into the DXF format and how it is used by OpenSCAD, I cannot say for sure where the actual flaw lies.It seems likely that the
ADD_LINEmacro on lines 108-109 is the culprit, since it inserts values that will be used for indexing even though the values are not yet valid indices.The text was updated successfully, but these errors were encountered: