An exploitable heap out of bounds write vulnerability exists in the Fitz graphical library part of the MuPDF renderer. A specially crafted PDF file can cause a out of bounds write resulting in heap metadata and sensitive process memory corruption leading to potential code execution. Victim needs to open the specially crafted file in a vulnerable reader in order to trigger this vulnerability.

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 was found in mupdf 1.18.0. Double free of object during linearization may lead to memory corruption and other potential consequences.

Stack-based buffer overflow in jstestmain.c in mujstest in Artifex Software, Inc. MuPDF 1.10a allows remote attackers to have unspecified impact via a crafted image.

freeglut through 3.4.0 was discovered to contain a memory leak via the menuEntry variable in the glutAddMenuEntry function.

freeglut 3.4.0 was discovered to contain a memory leak via the menuEntry variable in the glutAddSubMenu function.

Stack-based buffer overflow in the xpsparsecolor function in xps/xps-common.c in MuPDF 1.3 and earlier allows remote attackers to execute arbitrary code via a large number of entries in the ContextColor value of the Fill attribute in a Path element.

An issue was discovered in Artifex MuPDF before 1912de5f08e90af1d9d0a9791f58ba3afdb9d465. The pdfrunxobject function in pdf-op-run.c encounters a NULL pointer dereference during a Fitz fzpaintpixmapwithmask painting operation. Versions 1.11 and later are unaffected.

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 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.

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

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.

pdfloadobjstm in pdf/pdf-xref.c in Artifex MuPDF 1.12.0 could reference the object stream recursively and therefore run out of error stack, which allows remote attackers to cause a denial of service via a crafted PDF document.

In MuPDF 1.12.0, there is an infinite loop vulnerability and application hang in the pdfparsearray function (pdf/pdf-parse.c) because EOF is not considered. Remote attackers could leverage this vulnerability to cause a denial of service via a crafted pdf file.

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/

Heap-based buffer overflow in the fzsubsamplepixmap function in fitz/pixmap.c in MuPDF 1.10a allows remote attackers to cause a denial of service (out-of-bounds read and crash) via a crafted image.

In Artifex MuPDF 1.12.0, the pdfreadnewxref function in pdf/pdf-xref.c allows remote attackers to cause a denial of service (segmentation violation and application crash) via a crafted pdf file.

In Artifex MuPDF 1.12.0, there is a heap-based buffer overflow vulnerability in the dopdfsavedocument function in the pdf/pdf-write.c file. Remote attackers could leverage the vulnerability to cause a denial of service via a crafted pdf file.

MuPDF through 1.18.1 has an out-of-bounds write because the cached color converter does not properly consider the maximum key size of a hash table. This can, for example, be seen with crafted "mutool draw" input.

Use-after-free vulnerability in the fzsubsamplepixmap function in fitz/pixmap.c in Artifex MuPDF 1.10a allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a crafted document.

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.

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.

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)