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? [1] https://bugs.chromium.org/p/project-zero/issues/detail?id=1729&desc=2
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.
(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.
More issues: https://www.openwall.com/lists/oss-security/2019/03/21/1
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.
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.
*** Bug 676154 has been marked as a duplicate of this bug. ***
@ Maintainer(s): Please bump to 9.27!
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. Attaching: 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
Created attachment 582346 [details] Bump jbig2dec 0.14 -> 0.16
Created attachment 582348 [details] ghostscript-gpl-9.27-patchset-1.tar.xz
Created attachment 582488 [details] ghostscript-gpl-9.27.ebuild Oh, wait, there is a change in jbig2dec-0.16.ebuild: The SRC_URI switches from a downloads.ghostscript.com URL to a github.com/ArtifexSoftware/ghostpdl-downloads URL, which is the download link from https://jbig2dec.com/ , which is linked from https://www.ghostscript.com/ . 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 ( https://www.gentoo.org/support/security/vulnerability-treatment-policy.html ) 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?
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: >=app-text/ghostscript-gpl-9.27 >=media-libs/jbig2dec-0.16 >=app-text/qpdf-8.3.0 >=net-print/cups-filters-1.22.5 I installed these versions & successfully printed on x86: app-text/ghostscript-gpl-9.27 media-libs/jbig2dec-0.16 app-text/qpdf-8.4.2 net-print/cups-filters-1.25.1 [1] https://bugs.archlinux.org/task/62251 and https://github.com/OpenPrinting/cups-filters/blob/master/NEWS
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: https://www.debian.org/security/2019/dsa-4518
Ghostscript 9.50 was released on 2019-10-15: https://ghostscript.com/pipermail/gs-devel/2019-October/010232.html """ 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. """
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=afdbdbedba9222816f18bbf03d102bdb73ce3a15 commit afdbdbedba9222816f18bbf03d102bdb73ce3a15 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2019-10-24 22:18:04 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> 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 <whissi@gentoo.org>
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=95e9fef0a7017db7d82613ae4a9f83bd5b22262f commit 95e9fef0a7017db7d82613ae4a9f83bd5b22262f Author: Andreas K. Huettel <dilfridge@gentoo.org> AuthorDate: 2020-03-28 21:53:42 +0000 Commit: Andreas K. Huettel <dilfridge@gentoo.org> CommitDate: 2020-03-28 21:54:13 +0000 app-text/ghostscript-gpl: Remove old Bug: https://bugs.gentoo.org/676264 Package-Manager: Portage-2.3.89, Repoman-2.3.20 Signed-off-by: Andreas K. Huettel <dilfridge@gentoo.org> app-text/ghostscript-gpl/Manifest | 2 - .../ghostscript-gpl/ghostscript-gpl-9.26.ebuild | 196 --------------------- 2 files changed, 198 deletions(-)
ALl affected versions removed
Thanks all.
Added to an existing GLSA request.
This issue was resolved and addressed in GLSA 202004-03 at https://security.gentoo.org/glsa/202004-03 by GLSA coordinator Thomas Deutschmann (whissi).
