Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 676264 (CVE-2019-3835, CVE-2019-3838, CVE-2019-6116)

Summary: <app-text/ghostscript-gpl-9.28_rc4: multiple vulnerabilities (CVE-2019-{3835,3838,6116})
Product: Gentoo Security Reporter: Hanno Böck <hanno>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Severity: normal CC: chkno, dilfridge, guillaume, Manfred.Knick, maracay, mgorny, printing, teika
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard: B2 [glsa+ cve]
Package list:
Runtime testing required: ---
Bug Depends on: 693002    
Bug Blocks:    
Description Flags
Bump ghostscript-gpl 9.26 -> 9.27
Bump jbig2dec 0.14 -> 0.16
ghostscript-gpl-9.27.ebuild none

Description Hanno Böck gentoo-dev 2019-01-26 10:45:09 UTC
I'd like to raise an issue here about the systemic security issues in ghostscript.

To summarize: ghostscript implements postscript as a fully-featured programming language with all kinds of file and code execution operations. It has a weak kind of sandbox (the -DSAFER parameter), but in practice it doesn't work. The latest instance of this is a code execution bug with a reliable public exploit and non released fix in #676154, but this isn't about an individual bug.

Ghostscript is systemically flawed and from what I can gather it's unlikely that this situation will change any time soon. Upstream handles security poorly (read the project zero bug [1]).

Various applications make use of ghostscript indirectly, in many cases these can get triggered automatically, e.g. by desktop searches, thumbnailers or tools like imagemagick and even less can be vulnerable.

So I'd like to see this as a distribution-wide problem spanning multiple packages. In my view no user should inadvertently install anything where ghostscript gets potentially executed on untrusted content without a very clear warning to the user what that means.

In imagemagick right now the postscript policy is disabled by default, which is a good start. We have packages with IUSE="+postscript", I believe we should remove them all. Maybe we should consider renaming the flag to "postscript-insecure" distributionwide to make the risk clear.

Other thoughts?

Comment 1 Andreas K. Hüttel archtester gentoo-dev 2019-01-26 16:20:36 UTC
As someone who is actually doing work with Gentoo (which involves a surprising lot of vector graphics and print manipulation), that's imho not really an option.

(The first thing I had to do to keep any workflow going was to undo the ImageMagic policy changes.)

I'm all for keeping a system secure, but we need to keep it functional too.
Comment 2 Hanno Böck gentoo-dev 2019-01-26 17:56:04 UTC
(In reply to Andreas K. Hüttel from comment #1)
> As someone who is actually doing work with Gentoo (which involves a
> surprising lot of vector graphics and print manipulation), that's imho not
> really an option.

I'm not saying we should disable all ghostscript support, just that we shouldn't enable a piece of software that has by design RCE vulns at places where it gets executed without a clear warning.
Comment 3 Hanno Böck gentoo-dev 2019-03-21 15:45:06 UTC
More issues:
Comment 4 Eddie Chapman 2019-03-25 19:40:24 UTC
The latest 2 issues posted to oss-security (CVE-2019-3835 and CVE-2019-3838) both have upstream "fixes" public in upstream's git repo. Despite the sorry state of affairs with Ghostscript in general, should Gentoo at least patch app-text/ghostscript-gpl with these "fixes" (double quotes as no idea if they really fix the issues) despite there being no new upstream release? Or maybe backporting these fixes is non-trivial?

Touching on the wider question raised here: is a ghostscript patched with these upstream fixes any more secure than an unpatched qhostscript? Is applying them a waste of time because bad actors can just easily take advantage of multiple other unpatched/systemic flaws with the same or similar consequences? Whack-a-mole?

Maybe individual flaws which are highlighted via CVE assignment become important to address and fix none-the-less, because now they've received lots of attention, handy reproducers are published, and they become easy pickings the many less skilled/knowledgeable bad guys.

Genuinely posing these questions, though acutely aware that no easy answers.
Comment 5 Yury German Gentoo Infrastructure gentoo-dev 2019-03-27 23:56:55 UTC
CVE ID: CVE-2019-6116
   Summary: In Artifex Ghostscript through 9.26, ephemeral or transient procedures can allow access to system operators, leading to remote code execution.

CVE ID: CVE-2019-3835
   Summary: It was found that the superexec operator was available in the internal dictionary in ghostscript before 9.27. A specially crafted PostScript file could use this flaw in order to, for example, have access to the file system outside of the constrains imposed by -dSAFER.

CVE ID: CVE-2019-3838
   Summary: It was found that the forceput operator could be extracted from the DefineResource method in ghostscript before 9.27. A specially crafted PostScript file could use this flaw in order to, for example, have access to the file system outside of the constrains imposed by -dSAFER.
Comment 6 Yury German Gentoo Infrastructure gentoo-dev 2019-03-27 23:59:29 UTC
*** Bug 676154 has been marked as a duplicate of this bug. ***
Comment 7 Thomas Deutschmann (RETIRED) gentoo-dev 2019-05-13 15:15:58 UTC
@ Maintainer(s): Please bump to 9.27!
Comment 8 chkno 2019-07-10 09:13:59 UTC
Created attachment 582344 [details]
Bump ghostscript-gpl 9.26 -> 9.27

I made these four changes to get 9.27 to build (on x86_64):

1. Made ghostscript-gpl requrie jbig2dec 0.16 or later (>=media-libs/jbig2dec-0.16)
2. Bumped jbig2dec's version from 0.14 to 0.16 (just by renaming the jbig2dec ebuild).
3. Made a minor change to context in runlibfileifexists.patch so it applies cleanly.
4. Removed unnecessary changes to the license boilerplate (copyright year & vendor mailing address) in in urw-fonts-naming-1.patch that were not applying cleanly.

ghostscript-gpl-9.27.ebuild for #1 (one DEPEND line changed from 9.26)
jbig2dec-0.16.ebuild for #2 (no change from 0.14)
ghostscript-gpl-9.27-patchset-1.tar.xz for #3 and #4
Comment 9 chkno 2019-07-10 09:14:48 UTC
Created attachment 582346 [details]
Bump jbig2dec 0.14 -> 0.16
Comment 10 chkno 2019-07-10 09:15:27 UTC
Created attachment 582348 [details]
Comment 11 chkno 2019-07-10 22:13:26 UTC
Created attachment 582488 [details]

Oh, wait, there is a change in jbig2dec-0.16.ebuild: The SRC_URI switches from a URL to a URL, which is the download link from , which is linked from .

Also, I encountered a build parallelism (MAKEOPTS="-j2") problem while testing on x86:

i686-pc-linux-gnu-gcc ... -o ./obj/gsmd5.o -c ./obj/gsmd5.c
In file included from ./base/memory_.h:23:0,
                 from ./obj/gsmd5.h:1,
                 from ./obj/gsmd5.c:56:
./base/std.h:25:10: fatal error: arch.h: No such file or directory
 #include "arch.h"
compilation terminated.
make: *** [base/lib.mak:395: obj/gsmd5.o] Error 1
make: *** Waiting for unfinished jobs....
./soobj/aux/genarch ./soobj/arch.h

So find attached a new ghostscript-gpl-9.27.ebuild that turns off parallel builds (emake -j1).

With this change, ghostscript-gpl-9.27 successfully builds for me on x86 and amd64.  GLSA policy ( ) says that 9.27 must be marked stable on alpha, amd64, ppc, ppc64, and x86 before a GLSA can be issued.  I don't have an alpha, ppc, or ppc64 machine.

Anything else I can do to help?
Comment 12 chkno 2019-07-11 04:18:23 UTC
Ah, looks like there is another issue: ghostscript 9.27 removes the 'pdfdict' command (for security reasons) that the stable version of cups-filters uses.  cups-filters switches to the supported ghostscript command 'runpdfbegin' in 1.22.5.  So bumping ghostscript to 9.27 requires bumping cups-filters to 1.22.5 or later, or cups-filters breaks and cups cannot print [1].  The symptom of this going awry is this error message appearing in cups' debug logs:

    GPL Ghostscript 9.27: Unrecoverable error, exit code 1
    Process is dying with \"Unable to determine number of pages, page count: -1\", exit stat 3

How should this be encoded in the ghostscript and/or cups-filters ebuilds?

  Should ghostscript-gpl-9.27.ebuild RDEPEND on !<net-print/cups-filters-1.22.5?

  Should all cups-filters ebuilds less than 1.22.5 change their RDEPEND on
  ghostscript from >=app-text/ghostscript-gpl-9.09[cups] to
  >=app-text/ghostscript-gpl-9.09[cups] <app-text/ghostscript-gpl-9.27[cups]?

  Or both?

Stabilizing a cups-filters 1.22.5 or later then further requires stabilizing a app-text/qpdf to 8.3.0 or later.

So this is the list of packages that need a new stable version to push the ghostscript 9.27 security fix:


I installed these versions & successfully printed on x86:


[1] and
Comment 13 Teika kazura 2019-09-12 05:06:17 UTC
Another bunch of vulterabilities prior to 9.28 in which -dSAFER is bypassed, as CVE-2019-14811,  CVE-2019-14813, and CVE-2019-14817. There's also CVE-2019-14812.

For a summary, see Debian DSA:
Comment 14 Arfrever Frehtes Taifersar Arahesis 2019-10-24 01:30:59 UTC
Ghostscript 9.50 was released on 2019-10-15:

The more astute among you might notice that 9.28 has morphed into 9.50.
In a recent discussion amongst the Ghostscript developers, it became
clear that the redesign and reimplementation of the file security
features warranted more recognition than just the usual single digit
version increment. Hence we opted to bump it up to 9.50.
Comment 15 Arfrever Frehtes Taifersar Arahesis 2019-10-24 23:36:28 UTC

commit afdbdbedba9222816f18bbf03d102bdb73ce3a15
Author:     Thomas Deutschmann <>
AuthorDate: 2019-10-24 22:18:04 +0000
Commit:     Thomas Deutschmann <>
CommitDate: 2019-10-24 22:29:05 +0000

    app-text/ghostscript-gpl: bump to v9.50
    Package-Manager: Portage-2.3.78, Repoman-2.3.17
    Signed-off-by: Thomas Deutschmann <>
Comment 16 Larry the Git Cow gentoo-dev 2020-03-28 21:54:28 UTC
The bug has been referenced in the following commit(s):

commit 95e9fef0a7017db7d82613ae4a9f83bd5b22262f
Author:     Andreas K. Huettel <>
AuthorDate: 2020-03-28 21:53:42 +0000
Commit:     Andreas K. Huettel <>
CommitDate: 2020-03-28 21:54:13 +0000

    app-text/ghostscript-gpl: Remove old
    Package-Manager: Portage-2.3.89, Repoman-2.3.20
    Signed-off-by: Andreas K. Huettel <>

 app-text/ghostscript-gpl/Manifest                  |   2 -
 .../ghostscript-gpl/ghostscript-gpl-9.26.ebuild    | 196 ---------------------
 2 files changed, 198 deletions(-)
Comment 17 Andreas K. Hüttel archtester gentoo-dev 2020-03-28 21:55:24 UTC
ALl affected versions removed
Comment 18 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-03-28 21:56:58 UTC
Thanks all.
Comment 19 Thomas Deutschmann (RETIRED) gentoo-dev 2020-04-01 19:47:06 UTC
Added to an existing GLSA request.
Comment 20 GLSAMaker/CVETool Bot gentoo-dev 2020-04-01 19:53:12 UTC
This issue was resolved and addressed in
 GLSA 202004-03 at
by GLSA coordinator Thomas Deutschmann (whissi).