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.

Artifex Software mupdf v1.24.9 was discovered to contain a segmentation fault via the component /tools/pdfextract.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted PDF file.

An issue was discovered in decodeutf8 in base/gputf8.c in Artifex Ghostscript before 10.04.0. Overlong UTF-8 encoding leads to possible ../ directory traversal.

An issue was discovered in psi/zfile.c in Artifex Ghostscript before 10.04.0. Out-of-bounds data access in filenameforall can lead to arbitrary code execution.

An issue was discovered in base/gsdevice.c in Artifex Ghostscript before 10.04.0. An integer overflow when parsing the filename format string (for the output filename) results in path truncation, and possible path traversal and code execution.