A vulnerability was identified in Artifex Ghostscript up to 10.09.0. Affected is the function type1callsubr of the file devices/vector/gdevpsfx.c of the component Pdfwrite. The manipulation leads to stack-based buffer overflow. Remote exploitation of the attack is possible. The exploit is publicly available and might be used. It is suggested to install a patch to address this issue. A solution was implemented: "I've chosen to fix this slightly differently by using the defined macro in the font parsing loop rather than in the callsubr function, because this better matches the pattern of 'normal' usage."

Ghostscript for Windows is vulnerable to local privilege escalation through PostScript resource file hijacking. Due to the application searching for PostScript resource files in predictable paths under C:\\gs\\ that do not exist by default on Windows installations, combined with Windows default ACLs allowing any authenticated user to create directories at the root of C:\\, an attacker who is an authenticated local user can create the expected directory structure and plant a malicious PostScript file. When any user or service subsequently runs Ghostscript, the planted file is automatically loaded and executed with the full privileges of the Ghostscript process. This results in full compromise of Ghostscript process context, as well as running arbitrary code on the machine with Ghostscript process privileges.

This issue was fixed in version 10.08.0.

A flaw has been found in Artifex MuPDF up to b6d17493700c621c0e70036980a6ebd06d2202c9. Affected by this vulnerability is the function pdfopenfilter of the file pdf-stream.c of the component PDF Xref Loading. Executing a manipulation can lead to null pointer dereference. The attack can be launched remotely. The exploit has been published and may be used. This patch is called 3df1e30f9d7b77260e13bd0dbe1928ddeba8386e. Applying a patch is advised to resolve this issue.

Ghostscript before 10.08.0 contains a heap-based buffer overflow vulnerability in the JPEG 2000 output adapter (base/sjpxopenjpeg.c) that allows attackers to cause memory corruption by supplying a crafted PDF containing a JPEG 2000 image with mismatched component subsampling factors. When image components declare different subsampling values, the non-samescale sub-byte-depth output path allocates a row buffer sized for packed output but writes a full byte per output column regardless of bit depth, overflowing the allocation and corrupting internal chunk-allocator metadata to achieve code execution.

An integer overflow in the jbig2arithiaidctxnew() function of Artifex commit cc37d0 allows attackers to cause a Denial of Service (DoS) via a crafted input.

MuPDF before 1.27.0-rc1 contains an uncontrolled recursion vulnerability in the EPUB CSS rendering engine that allows remote attackers to cause a denial of service by supplying a maliciously crafted EPUB file with deeply nested HTML elements and inline CSS styles. The function valuefrominheritableproperty() in css-apply.c recurses through the CSS property inheritance chain without a depth limit, exhausting the process stack and causing a crash in any application using MuPDF for EPUB rendering.

Gabriel Corona wrote in <7758b7f4-a71a-48a6-b4a9-516700650a7e () free fr>: |> Sandboxes should only allow allowlist of file types and make everything |> else fall back to a safe default. This could be a simple text editor |> (no IDE support!) for text files, and a hex editor (or an error) for |> binary files. | |That sounds extremely inconvenient. Running an email client in a |sandbox? It can't open a PDF or a JPEG (or worse, you'll get an |hex-editor) ...

Actually, i think what is missing is some intermediate step. This includes more control commands for RFC 1524 Mailcap files, which i am all for, and hope certain new things in the IETF (structured email, SML, to name it) do not loose it. 'Maybe even extend it.

For example, my MUA (but do not look) introduced certain new control commands (x-mailx-async, x-mailx-last-resort, x-mailx-ignore, too name some) , but none that fits here specifically -- however, mailcap (and other supported approaches of starting programs for data formats) are by default only used in "copiousoutput" mode, you need a special mimeview' command to invoke other things. Long story, this results in chains like

application/pdf;\ mupdf %s;\ test = [ -n "$DISPLAY" ] >/dev/null 2>&1;\ nametemplate = %s.pdf; x-mailx-ignore application/pdf;\ infile=%s\;\ trap "rm -f \"$infile\"" EXIT\;\ trap "exit 75" INT QUIT TERM\;\ mupdf "$infile";\ test = [ -n "$DISPLAY" ] >/dev/null 2>&1;\ nametemplate = %s.pdf; x-mailx-async; x-mailx-test-once application/pdf;\ pdfinfo %s\; pdftotext -layout %s -;\ test = command -v pdfinfo >/dev/null 2>&1;\ copiousoutput; nametemplate=%s.pdf; x-mailx-test-once

or

image/;\ display %s;\ test = { [ -n "$DISPLAY" ] && command -v display\; } >/dev/null 2>&1;\ x-mailx-ignore image/;\ infile=%s\;\ trap "rm -f \"$infile\"" EXIT\;\ trap 'exit 75' INT QUIT TERM\;\ display "$infile";\ test = { [ -n "$DISPLAY" ] && command -v display\; } >/dev/null 2>&1;\ x-mailx-async; x-mailx-test-once image/;\ identify %s;\ test = command -v identify >/dev/null 2>&1;\ copiousoutput; x-mailx-noquote; x-mailx-test-once

and the second ones are used for mimeview', the third it is when normally viewing emails. (pdftotext not initially -- but i am lazy, .. like you say.)

Short story: neither, i think, pdfinfo(1) nor pdftotext(1) (nor identify(1)) actually execute integrated Script, at least. But it is still not truly nice.

Best would surely be some viewer who has a "stepped approach", showing only some infos first, asking for confirmation or the action to be applied, before displaying an image or whatever. And then going into some safe mode when truly going "in full" on the data as such. Of course implementing such a thing in that very way is an extensive effort, and not always doable.

But maybe it is time -- instead of simply rewriting the same mess in Rust (gdk-pixbuf) -- to create "priviledge-separated" media viewers, where the image/data format specific stuff is in a completely separated "process", and only readily prepared data in a common type (X11 bitmap or what) is then send via IPC / made available in some shared mapping for some display/player. (It could be such things already exist, i live only in dwm / st / tmux, and have only fewest graphical things beside that.)

|If the sandboxed application is badly integrated and can't open files |and URIs, the user (me included) will prefer using the non-sandboxed |version in order to get things done (or will prefer using a more |user-friendly OS). This would defeat the purpose of having sandboxed |applications.

Over a decade ago an Irish forwarded a message from Trinity College Dublin; it is astounding "how rich" emails can get in real life. One does not want to use the above approach (what was, actually, shown). But priviledge-separated multimedia viewer, which maybe "goes in full" (video, audio .. play) only on explicit request, instead of simply linking/loading in more and more formats through shallow ad-hoc format converters that use format dedicated libraries, i think that is a problem.

--steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

A vulnerability was determined in Artifex MuPDF up to 1.28.0. The impacted element is the function fzsubsetcffforgids of the file subset-cff.c of the component CFF Index Handler. This manipulation causes out-of-bounds read. The attack can only be executed locally. The exploit has been publicly disclosed and may be utilized. The project was informed of the problem early through a bug report but has not responded yet.

MuPDF before 1.27 contains an ANSI injection vulnerability in mutool that allows attackers to inject arbitrary ANSI escape sequences through crafted PDF metadata fields. Attackers can embed malicious ANSI escape codes in PDF metadata that are passed unsanitized to terminal output when running mutool info, enabling them to manipulate terminal display for social engineering attacks such as presenting fake prompts or spoofed commands.

An integer overflow vulnerability in 'pdf-image.c' in Artifex's MuPDF version 1.27.0 allows an attacker to maliciously craft a PDF that can trigger an integer overflow within the 'pdfloadimageimp' function. This allows a heap out-of-bounds write that could be exploited for arbitrary code execution.

A flaw has been found in Artifex MuPDF up to 1.26.1 on Windows. The impacted element is the function getsystemdpi of the file platform/x11/winmain.c. This manipulation causes uncontrolled search path. The attack requires local access. The attack is considered to have high complexity. The exploitability is regarded as difficult. Upgrading to version 1.26.2 is sufficient to resolve this issue. Patch name: ebb125334eb007d64e579204af3c264aadf2e244. Upgrading the affected component is recommended.

MuPDF versions 1.23.0 through 1.27.0 contain a double-free vulnerability in fzfillpixmapfromdisplaylist() when an exception occurs during display list rendering. The function accepts a caller-owned fzpixmap pointer but incorrectly drops the pixmap in its error handling path before rethrowing the exception. Callers (including the barcode decoding path in fzdecodebarcodefromdisplaylist) also drop the same pixmap in cleanup, resulting in a double-free that can corrupt the heap and crash the process. This issue affects applications that enable and use MuPDF barcode decoding and can be triggered by processing crafted input that causes a rendering-time error while decoding barcodes.

A null pointer dereference occurs in the function breakwordforoverflowwrap() in MuPDF 1.26.4 when rendering a malformed EPUB document. Specifically, the function calls fzhtmlsplitflow() to split a FLOWWORD node, but does not check if node->next is valid before accessing node->next->overflowwrap, resulting in a crash if the split fails or returns a partial node chain.

Artifex Ghostscript through 10.05.1 has a stack-based buffer overflow in pdfmarkcoercedest in devices/vector/gdevpdfm.c via a large size value.

In Artifex GhostXPS before 10.06.0, there is a stack-based buffer overflow in xpsunpredicttiff in xpstiff.c because the samplesperpixel value is not checked.

In Artifex Ghostscript through 10.05.1, ocrbeginpage in devices/gdevpdfocr.c has an integer overflow that leads to a heap-based buffer overflow in ocrline8.

Artifex Ghostscript through 10.05.1 has a stack-based buffer overflow in pdfwritecmap in devices/vector/gdevpdtw.c.

An issue in Artifex mupdf 1.25.6, 1.25.5 allows a remote attacker to cause a denial of service via an infinite recursion in the mutool clean utility. When processing a crafted PDF file containing cyclic /Next references in the outline structure, the stripoutline() function enters infinite recursion

A vulnerability was found in Artifex GhostPDL up to 3989415a5b8e99b9d1b87cc9902bde9b7cdea145. It has been classified as problematic. This affects the function pdfferror of the file devices/vector/gdevpdf.c of the component New Output File Open Error Handler. The manipulation leads to null pointer dereference. It is possible to initiate the attack remotely. The identifier of the patch is 619a106ba4c4abed95110f84d5efcd7aee38c7cb. It is recommended to apply a patch to fix this issue.

gslibctxstashsanitizedarg in base/gslibctx.c in Artifex Ghostscript before 10.05.1 lacks argument sanitization for the # case. A created PDF document includes its password in cleartext.

In Artifex Ghostscript before 10.05.0, decodeutf8 in base/gputf8.c mishandles overlong UTF-8 encoding. NOTE: this issue exists because of an incomplete fix for CVE-2024-46954.

An issue was discovered in Artifex Ghostscript before 10.05.0. The NPDL device has a Compression buffer overflow for contrib/japanese/gdevnpdl.c.

An issue was discovered in Artifex Ghostscript before 10.05.0. A buffer overflow occurs via an oversized Type 4 function in a PDF document to pdf/pdffunc.c.

An issue was discovered in Artifex Ghostscript before 10.05.0. A buffer overflow occurs during serialization of DollarBlend in a font, for base/writet1.c and psi/zfapi.c.

An issue was discovered in Artifex Ghostscript before 10.05.0. A buffer overflow occurs for a long TTF font name to pdf/pdffmap.c.

An issue was discovered in Artifex Ghostscript before 10.05.0. The BJ10V device has a Print buffer overflow in contrib/japanese/gdev10v.c.

An issue was discovered in Artifex Ghostscript before 10.05.0. A buffer overflow occurs when converting glyphs to Unicode in psi/zbfont.c.

An issue was discovered in Artifex Ghostscript before 10.05.0. The NPDL device has a Compression buffer overflow for contrib/japanese/gdevnpdl.c.

An issue was discovered in Artifex Ghostscript before 10.05.0. The DOCXWRITE TXTWRITE device has a text buffer overflow via long characters to devices/vector/doccommon.c.

An issue was discovered in Artifex Ghostscript before 10.05.0. Access to arbitrary files can occur through a truncated path with invalid UTF-8 characters, for base/gpmswin.c and base/winrtsup.cpp.