Source: slic3r-prusa X-Debbugs-CC: team.org Severity: important Tags: security Hi, The following vulnerabilities were published for slic3r-prusa. Although these are quite old, I believe they have never been properly reported upstream and are unfixed to this day? CVE-2020-28594[0]: | A use-after-free vulnerability exists in the | _3MF_Importer::_handle_end_model() functionality of Prusa Research | PrusaSlicer 2.2.0 and Master (commit 4b040b856). A specially crafted | 3MF file can lead to code execution. An attacker can provide a | malicious file to trigger this vulnerability. https://talosintelligence.com/vulnerability_reports/TALOS-2020-1218 CVE-2020-28595[1]: | An out-of-bounds write vulnerability exists in the Obj.cpp | load_obj() functionality of Prusa Research PrusaSlicer 2.2.0 and | Master (commit 4b040b856). A specially crafted obj file can lead to | code execution. An attacker can provide a malicious file to trigger | this vulnerability. https://talosintelligence.com/vulnerability_reports/TALOS-2020-1219 CVE-2020-28596[2]: | A stack-based buffer overflow vulnerability exists in the | Objparser::objparse() functionality of Prusa Research PrusaSlicer | 2.2.0 and Master (commit 4b040b856). A specially crafted obj file | can lead to code execution. An attacker can provide a malicious file | to trigger this vulnerability. https://talosintelligence.com/vulnerability_reports/TALOS-2020-1220 CVE-2020-28598[3]: | An out-of-bounds write vulnerability exists in the Admesh | stl_fix_normal_directions() functionality of Prusa Research | PrusaSlicer 2.2.0 and Master (commit 4b040b856). A specially crafted | AMF file can lead to code execution. An attacker can provide a | malicious file to trigger this vulnerability. https://talosintelligence.com/vulnerability_reports/TALOS-2020-1222
Created prusa-slicer tracking bugs for this issue: Affects: fedora-all [bug 2294729]
As for CVE-2020-28594 / https://talosintelligence.com/vulnerability_reports/TALOS-2020-1218: The code upstream has been different from the one in the report since 2021 with commit https://github.com/prusa3d/PrusaSlicer/commit/f9f99c4889ca595b48104a0ab77ad78c0ddea619 which specifically says that it checks for invalid data. The fix went to upstream release 2.3.1.
As for CVE-2020-28595 / https://talosintelligence.com/vulnerability_reports/TALOS-2020-1219: The code upstream has been different from the one in the report since 2021 with commit https://github.com/prusa3d/PrusaSlicer/commit/8a2a9dba2f8f94da0106b60df613cd04ada4d595#diff-9ab56fd8ed8bcc525320e0809f0eb30e40b711ed49e7aab5bc60c0cfcf7a8dcb. The stl_allocate is no longer called in the code. The fix went to upstream release 2.4.0.
As for CVE-2020-28596 / https://talosintelligence.com/vulnerability_reports/TALOS-2020-1220: The code upstream has been different from the one in the report since 2020 with commit https://github.com/prusa3d/PrusaSlicer/commit/ba9a9b4e7ac8863f52923a90a9290a8ab0660e89 which specifically says that it fixes buffer overflow. The fix went to upstream release 2.4.0.
As for CVE-2020-28598 / https://talosintelligence.com/vulnerability_reports/TALOS-2020-1222: The code upstream has been different from the one in the report since 2021 with commit https://github.com/prusa3d/PrusaSlicer/commit/8a2a9dba2f8f94da0106b60df613cd04ada4d595#diff-86b904c5b1e56d10dbacff71e2c2c9307219bd261dedf11fcfb3a942935b10e3 which removed the invocation of mesh.repair(), so the code in admesh is not reached in this scenario. The fix went to upstream release 2.4.0.
What are the expected steps from where? Two of those Talos pages have just Vendor Disclosure and Public Release, two also have Vendor patched. Who is the Vendor in this case? Is that the upstream (https://github.com/prusa3d/PrusaSlicer/) or someone else? Granted, the commits did not refer to any CVE identifiers, so the NVD also tracks them as unfixed. But then, it tracks them against cpe:2.3:a:prusa3d:prusaslicer:2.2.0:-:*:*:*:*:*:*, not against generic prusa slicer.