Bugzilla – Bug 1227377
VUL-0: CVE-2024-29511: ghostscript: arbitrary file read/write through Tesseract configuration
Last modified: 2024-07-16 08:13:59 UTC
Artifex Ghostscript before 10.03.1, when Tesseract is used for OCR, has a directory traversal issue that allows arbitrary file reading (and writing of error messages to arbitrary files) via OCRLanguage. For example, exploitation can use debug_file /tmp/out and user_patterns_file /etc/passwd. References: https://bugs.ghostscript.com/show_bug.cgi?id=707510 http://www.openwall.com/lists/oss-security/2024/07/03/7 https://bugs.ghostscript.com/show_bug.cgi?id=707662 https://codeanlabs.com/blog/research/cve-2024-29510-ghostscript-format-string-exploitation/ http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-29511 https://www.cve.org/CVERecord?id=CVE-2024-29511 https://git.ghostscript.com/?p=ghostpdl.git%3Ba=commitdiff%3Bh=3d4cfdc1a44 https://bugzilla.redhat.com/show_bug.cgi?id=2295648
----------------------------------------------------------- # osc cat Printing ghostscript ghostscript.changes ... For openSUSE and SUSE Ghostscript is built '--without-tesseract' (see the entry below dated 'Mon Jul 18 07:28:54 UTC 2022'). ... Mon Jul 18 07:28:54 UTC 2022 ... - update to 9.56.1: ... * We have added the capability to build with the Tesseract OCR engine. ... - Configure --without-tesseract because this requires C++ (it might be added if Tesseract support in Ghostscript is needed). ----------------------------------------------------------- # osc cat Printing ghostscript ghostscript.spec ... # --without-tesseract because this requires C++ (it might be added if Tesseract support in Ghostscript is needed). ... %configure \ ... --without-tesseract -----------------------------------------------------------
I think we are not affected?
(In reply to Johannes Meixner from comment #3) > I think we are not affected? Thanks for the quick response! OCR only added with 9.53/9.54, so SLE does not even come with the vulnerable code. For new/upcoming products the functionality is disabled.
I think it was fixed in upstream Ghostscript 10.03.0 according to https://ghostscript.readthedocs.io/en/gs10.03.0/News.html that reads (excerpt): ----------------------------------------------------------- A vulnerability was identified in the way Ghostscript/GhostPDL called tesseract for the OCR devices, which could allow arbitrary code execution. As as result, we strongly urge anyone including the OCR devices in their build to update as soon as possible. ----------------------------------------------------------- but no CVE is mentioned there. The same text is also in https://ghostscript.readthedocs.io/en/gs10.03.1/News.html but again no CVE is mentioned there. Because SUSE and openSUSE is not and never was affected and because I didn't know about a CVE I skipped this text in ghostscript.changes to not raise false alarm to our users. Now since a CVE is known I don't know if I should mention CVE-2024-29511 in ghostscript.changes as "not affected"? At least as far as I remember what we did in the past with the packages that I maintain we did not mention CVEs in our RPM changelogs when our packages were not affected.
(In reply to Johannes Meixner from comment #6) > The same text is also in > > https://ghostscript.readthedocs.io/en/gs10.03.1/News.html That now has: 'Fixes for CVE-2024-33869, CVE-2023-52722, CVE-2024-33870, CVE-2024-33871 and CVE-2024-29510' > Because SUSE and openSUSE is not and never was affected > and because I didn't know about a CVE > I skipped this text in ghostscript.changes > to not raise false alarm to our users. > > Now since a CVE is known I don't know if I should mention > CVE-2024-29511 in ghostscript.changes as "not affected"? > > At least as far as I remember what we did in the past > with the packages that I maintain we did not mention CVEs > in our RPM changelogs when our packages were not affected. Because of the SLF process changes I think it would be good to have the CVE/bsc references's added to that version entry in the changes file for Factory. Because that will allow us to track the CVEs via the changes files, i.e. we know where a fix went to. We never enforced the references for Factory, but it would be overall better to have them in the changes I think. With SLF even more now.