A flaw was found in gdk-pixbuf, affecting all versions. When parsing a specially crafted ICO file with pixel values that exceed the defined palette range, an out-of-bounds read can occur due to improper bounds checking against the actual palette size. This issue causes heap bytes to be interpreted as valid palette indices and rendered as RGB pixel values in the output image, allowing an attacker to extract heap contents via the generated output, such as a thumbnail.

A flaw was found in gdk-pixbuf, affecting all versions. When parsing a specially crafted ICO file with pixel values that exceed the defined palette range, an out-of-bounds read can occur due to improper bounds checking against the actual palette size. This issue causes heap bytes to be interpreted as valid palette indices and rendered as RGB pixel values in the output image, allowing an attacker to extract heap contents via the generated output, such as a thumbnail.

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)