Hi,

CVE-2024-29509 - heap buffer overflow via the PDFPassword parameter

memcpy(P->data, Password, PasswordLen); /PDFPassword (foo\000bar) def CVE-2024-29506 - stack buffer overflow in pdfiapplyfilter() if (ctx->args.pdfdebug) { char str[100]; memcpy(str, (const char )n->data, n->length); str[n->length] = '\0'; dmprintf1(ctx->memory, "FILTER NAME:%s\n", str); } CVE-2024-29507 - stack buffer overflow via CIDFSubstPath/Font params char fontfname[gpfilenamesizeof]; // 4096

// .. <snip> ...

if (ctx->args.cidfsubstpath.data == NULL) { memcpy(fontfname, fsprefix, fsprefixlen); } else { fsprefixlen = ctx->args.cidfsubstpath.size; }

if (ctx->args.cidfsubstfont.data == NULL) { // ... <snip> ... } else { defcidfallacklen = ctx->args.cidfsubstfont.size; } CVE-2024-29508 - heap pointer leak in pdfbasefontalloc() if (pfname->size > 0) { fontname.data = pfname->chars; fontname.size = pfname->size; while (pdfhassubsetprefix(fontname.data, fontname.size)) { / Strip off an existing subset prefix. / fontname.data += SUBSETPREFIXSIZE; fontname.size -= SUBSETPREFIXSIZE; } } else { gssnprintf(fnbuf, sizeof(fnbuf), ".F" PRIINTPTR, (intptrt)copied); fontname.data = (byte )fnbuf; fontname.size = strlen(fnbuf); }

Resulting in, for example:

CVE-2024-29511 - arbitrary file read/write through Tesseract config mark /OutputFile (/tmp/notused) /OCRLanguage (../../../../../tmp/test) % loads /tmp/test.traineddata /OutputDevice /ocr .dicttomark setpagedevice debugfile /tmp/out userpatternsfile /etc/passwd

will result in a file /tmp/out containing:

Error: failed to insert pattern 'root:x:0:0:root:/root:/bin/bash' Error: failed to insert pattern 'bin:x:2:2:bin:/bin:/usr/sbin/nologin' Error: failed to insert pattern 'sys:x:3:3:sys:/dev:/usr/sbin/nologin' Error: failed to insert pattern 'sync:x:4:65534:sync:/bin:/bin/sync' <etc>

In Postscript we can:

1. Construct the traineddata file under /tmp/ 3. Read the resulting output data in /tmp/out

CVE-2024-29510 - format string injection in uniprint device

https://bugs.ghostscript.com/showbug.cgi?id=707662 https://codeanlabs.com/blog/research/cve-2024-29510-ghostscript-format-string-exploitation/

---

Cheers, Thomas

Null pointer dereference flaw was found in gxdefaultcreatebufdevice().

https://bugs.ghostscript.com/showbug.cgi?id=704945 http://git.ghostscript.com/?p=ghostpdl.git;h=ae1061d948d88667bdf51d47d918c4684d0f67df

On Sun, Sep 09, 2018 at 12:26:01PM -0700, Tavis Ormandy wrote: On Sat, Sep 8, 2018 at 3:42 AM Marius Bakke <mbakke () fastmail com> wrote: Tavis Ormandy <taviso () google com> writes: Quick update, this <http://git.ghostscript.com/?p=ghostpdl.git&a=commitdiff&h=5812b1b78fc4> commit fixes that problem, but I noticed that fix is incomplete and can be bypassed, so filed another bug for that (the new bug is 699718). I see <https://bugs.chromium.org/p/project-zero/issues/detail?id=1640> is now closed. As far as I can tell, these are the (only) commits necessary on top of 9.24[]:

https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=5812b1b78fc4d36fdc293b7859de69241140d590

https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=3e5d316b72e3965b7968bb1d96baa137cd063ac6

https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=643b24dbd002fb9c131313253c307cf3951b3d47

Which are all variations of CVE-2018-16509. Is my understanding correct? Mitre has assigned CVE-2018-16802 to these 3 commits.

Ciao, Marcus

On Sat, Sep 8, 2018 at 3:42 AM Marius Bakke <mbakke () fastmail com> wrote: Tavis Ormandy <taviso () google com> writes: Quick update, this <http://git.ghostscript.com/?p=ghostpdl.git&a=commitdiff&h=5812b1b78fc4> commit fixes that problem, but I noticed that fix is incomplete and can be bypassed, so filed another bug for that (the new bug is 699718). I see <https://bugs.chromium.org/p/project-zero/issues/detail?id=1640> is now closed. As far as I can tell, these are the (only) commits necessary on top of 9.24[]:

https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=5812b1b78fc4d36fdc293b7859de69241140d590

https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=3e5d316b72e3965b7968bb1d96baa137cd063ac6

https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=643b24dbd002fb9c131313253c307cf3951b3d47

Which are all variations of CVE-2018-16509. Is my understanding correct? Yes, I think that's enough for all the issues I reported. There are some more security commits in git (like this one <http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=fb713b3818b52d8a6cf62c951eba2e1795ff9624>) that are not from me though. That one in particular seems like a good idea, errordict is like window.onerror in PostScript, a top-level exception handler. It's hard to believe there are many legitimate untrusted documents using complex exception handling logic ¯\(ツ)/¯ Many thanks to Tavis and P0 for finding these and keeping us in the loop!

[] You'll also need this to make 2&3 apply:

https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=e914f1da46e33decc534486598dc3eadf69e6efb

A null pointer vulnerability was found in memgetbitsrectangle() when trying to read from unallocated memory.

Upstream bug:

https://bugs.ghostscript.com/showbug.cgi?id=697676

Upstream patch:

http://git.ghostscript.com/?p=ghostpdl.git;h=309eca4e0a31ea70dcc844812691439312dad091

An use-after-free vulnerability was found in mupdf pdftonum. A maliciously created file could cause the application to crash.

Upstream bugs:

http://bugs.ghostscript.com/showbug.cgi?id=697015 http://bugs.ghostscript.com/showbug.cgi?id=697019

Upstream patch:

http://git.ghostscript.com/?p=mupdf.git;h=1e03c06456d997435019fb3526fa2d4be7dbc6ec

References:

http://seclists.org/oss-sec/2016/q4/149 https://blogs.gentoo.org/ago/2016/09/22/mupdf-use-after-free-in-pdftonum-pdf-object-c/

If you call .sethalftone5 with an empty operand stack, ghostscript crashes. This flaw could be exploitable

Upstream bug : - Bug 697203 - NULL dereference in .sethalftone5 http://bugs.ghostscript.com/showbug.cgi?id=697203

Upstream patch : - Bug 697203: check for sufficient params in .sethalftone5 http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=f5c7555c303

Reference : http://seclists.org/oss-sec/2016/q4/98

It was found that getenv and filenameforall ignore -dSAFER possibly allowing filesystem enumeration.

Upstream bug:

http://bugs.ghostscript.com/showbug.cgi?id=694724

Upstream patch:

http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=ab109aaeb3ddba59518b036fb288402a65cf7ce8

Reference: http://seclists.org/oss-sec/2016/q3/651

Reproducer:

%!PS (HOME) getenv { print (\n) print } { (variable not found\n) print } ifelse

Multiple integer underflows in the icmLutallocate function in International Color Consortium (ICC) Format library (icclib), as used in Ghostscript 9.06 and Argyll Color Management System, allow remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a crafted (1) PostScript or (2) PDF file with embedded images, which triggers a heap-based buffer overflow. NOTE: this issue is also described as an array index error.

Ghostscript included the current working directory in its library search path by default. If a user ran Ghostscript without the "-P-" option in an attacker-controlled directory containing a specially-crafted PostScript library file, it could cause Ghostscript to execute arbitrary PostScript code. With this update, Ghostscript no longer searches the current working directory for library files by default. (CVE-2010-4820)

Note: The fix for CVE-2010-4820 could possibly break existing configurations. To use the previous, vulnerable behavior, run Ghostscript with the "-P" option (to always search the current working directory first).

A memory corruption vulnerability caused by long names was discovered [1] in Ghostscript 8.64 and earlier. A specially crafted PDF file could result in the execution of arbitrary code if opened or printed (i.e. via CUPS).

This was corrected in upstream Ghostscript 8.70 [2], version 8.64 and previous are affected by this flaw (all the way back to Ghostscript 7.05).

References:

[1] http://bugs.ghostscript.com/showbug.cgi?id=690523 [2] http://svn.ghostscript.com/viewvc?view=rev&revision=9797

Security flaws were found in the way gs handled its initialization: 1, library search path include '.' (current working directory) by default, causing ghostscript to search '.' for initialization and library postscript files 2, explicit use of "-P-" command line option, did not prevent ghostscript from executing PostScript commands, contained within "gsinit.ps" file.

A local attacker could use this flaw to execute arbitrary PostScript commands, if the victim was tricked into opening a PostScript file in the directory writeable by the attacker

References: [1] http://bugs.ghostscript.com/showbug.cgi?id=691339 [2] http://bugs.ghostscript.com/showbug.cgi?id=691350 [3] http://www.securityfocus.com/archive/1/511433 [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583316 [5] https://bugzilla.novell.com/showbug.cgi?id=608071 [6] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583183

A buffer overflow vulnerability in Ghostscript's parser function was reported. A specially crafted postscript file could result in the execution of arbitrary code if opened or printed (i.e. via CUPS). Note that stack protections in the compiler render this into nothing more than a denial of service. This has been corrected in upstream Ghostscript 8.71; at least 8.64 and 8.70 are affected by this issue. Testing of Ghostscript 8.15 shows it does not suffer from this flaw.

Acknowledgements:

Red Hat would like to thank Rodrigo Rubira Branco of Check Point Vulnerability Discovery Team for responsibly reporting this issue.

Created attachment 373324 [details] ghostscript backtrace

Description of problem: When cups prints a PDF, it passes it at some point through pstoraster which calls gs. I noticed a PDF I was working on caused printing to fail, and it appears that some of the debugging output (which pstoraster turns on) from the gs cups driver can trigger a buffer overflow in the gs debug handling (which uses vsprintf - bad bad bad).

I think there are two issues here. One is that somehow gs ended up with MediaType argument without null termination (at least that's how it appears). The other is that ghostscript's print handling code uses (v)sprintf when it should be using (v)snprintf. In fact, ghostscript uses (v)sprintf with an "%s" format modifier over 50 times in the source code, several instances of which are probably unsafe (such as here).

Consider the following code from base/gsmisc.c: int errprintf(const gsmemoryt mem, const char fmt, ...) { ... char buf[PRINTFBUFLENGTH]; ... count = vsprintf(buf, fmt, args); errwrite(mem, buf, count); if (count >= PRINTFBUFLENGTH) { count = sprintf(buf, "PANIC: printf exceeded %d bytes. Stack has been corrupted.\n", PRINTFBUFLENGTH); errwrite(mem, buf, count); } ...

Just marvellous -- ghostscript expects vsprintf to return sanely if it overflows (which it doesn't), and then expects to print a nice panic message. It would be a 5 line patch to fix this so that it uses vsnprintf, and if count+1 exceeds the buffer length then it can print a warning that the message was truncated instead. Same goes for outprintf.

I will attach the stack trace from gdb, the cups error log and the PDF which caused the problem.

I wasn't sure if this was security-sensitive or not, but I ticked the box just to be on the safe side. With all the sanity checking that gcc adds to (v)sprintf these days, it's probably very hard to exploit.

Version-Release number of selected component (if applicable): ghostscript-8.70-1.fc12.i686

How reproducible: No idea - works every time on this PDF though.

Steps to Reproduce: 1. Open PDF in evince 2. Print PDF to any printer 3. Wait for message saying "printing failed" or somesuch.

Additional info: To attach gdb, I put a 'sleep 20' command in the pstoraster shell script (/usr/lib/cups/filter/pstoraster) just before it executed gs, then I "printed" the PDF, found the sleeping bash process and attached gdb to it.

Heap-based buffer overflow in the big2decodesymboldict function (jbig2symboldict.c) in the JBIG2 decoding library (jbig2dec) in Ghostscript 8.64, and probably earlier versions, allows remote attackers to execute arbitrary code via a PDF file with a JBIG2 symbol dictionary segment with a large run length value.

A denial of service flaw was found in Ghostscript's CCITTFax decoding filter. An attacker could create a specially-crafted PDF file which could cause Ghostscript to crash, or, potentially execute arbitrary code, when opened by the victim.

Multiple integer overflows and multiple insufficient upper-bounds checks on certain variable sizes were originally discovered in the Ghostscript's International Color Consortium Format Library (icclib). It was found, the original patch, addressing this issue was incomplete.

Multiple integer overflows and multiple insufficient upper-bounds checks on certain variable sizes were originally discovered in the Ghostscript's International Color Consortium Format Library (icclib). It was found, the original patch, addressing this issue was incomplete.

icc.c in the International Color Consortium (ICC) Format library (aka icclib), as used in Ghostscript 8.64 and earlier and Argyll Color Management System (CMS) 1.0.3 and earlier, allows context-dependent attackers to cause a denial of service (application crash) or possibly execute arbitrary code by using a device file for processing a crafted image file associated with large integer values for certain sizes, related to an ICC profile in a (1) PostScript or (2) PDF file with embedded images.

Multiple insufficient upper-bounds checks on certain sizes were found in the Ghostscript's International Color Consortium Format Library (icclib). An attacker could use this flaw to potentially execute arbitrary code by providing a specially-crafted image file for processing via the Ghotstscript's device file.

Multiple integer overflows in icc.c in the International Color Consortium (ICC) Format library (aka icclib), as used in Ghostscript 8.64 and earlier and Argyll Color Management System (CMS) 1.0.3 and earlier, allow context-dependent attackers to cause a denial of service (heap-based buffer overflow and application crash) or possibly execute arbitrary code by using a device file for a translation request that operates on a crafted image file and targets a certain "native color space," related to an ICC profile in a (1) PostScript or (2) PDF file with embedded images.

Multiple integer overflows were found in the Ghostsript's International Color Consortium Format Library (icclib). An attacker could use this flaw to potentially execute arbitrary code by requesting to translate a specially- crafted image file created on one device into another's device native color space via a device file.

Buffer overflow in the BaseFont writer module in Ghostscript 8.62, and possibly other versions, allows remote attackers to cause a denial of service (ps2pdf crash) and possibly execute arbitrary code via a crafted Postscript file.

Stack-based buffer overflow in the zseticcspace function in zicc.c in Ghostscript 8.61 and earlier allows remote attackers to execute arbitrary code via a postscript (.ps) file containing a long Range array in a .seticcspace operator.

A denial of service flaw was found in Ghostscript's CCITTFax decoding filter. An attacker could create a specially-crafted PDF file which could cause Ghostscript to crash, or, potentially execute arbitrary code, when opened by the victim.