ghostscript: multiple critical vulnerabilities, including remote command execution Project Member Reported by taviso@google.com, Today (15 hours ago) Issue description I sent the following mail to the oss-security mailing list: http://seclists.org/oss-sec/2018/q3/142 These are critical and trivial remote code execution bugs in things like ImageMagick, Evince, GIMP, and most other PDF/PS tools. [ https://bugs.chromium.org/p/project-zero/issues/detail?id=1640 ] Overview Ghostscript contains multiple -dSAFER sandbox bypass vulnerabilities, which may allow a remote, unauthenticated attacker to execute arbitrary commands on a vulnerable system. Description Ghostscript contains an optional -dSAFER option, which is supposed to prevent unsafe PostScript operations. Multiple PostScript operations bypass the protections provided by -dSAFER, which can allow an attacker to execute arbitrary commands with arbitrary arguments. This vulnerability can also be exploited in applications that leverage Ghostscript, such as ImageMagick. Impact By causing Ghostscript or a program that leverages Ghostscript to parse a specially-crafted file, a remote, unauthenticated attacker may be able to execute arbitrary commands with the privileges of the Ghostscript code. Solution The CERT/CC is currently unaware of a practical solution to this problem. Please consider the following workarounds: Disable PS, EPS, PDF, and XPS coders in ImageMagick policy.xml ImageMagick uses Ghostscript by default to process PostScript content. ImageMagick can be controlled via the policy.xml security policy to disable the processing of PS, EPS, PDF, and XPS content. For example, this can be done by adding these lines to the <policymap> section of the /etc/ImageMagick/policy.xml file on a RedHat system: <policy domain="coder" rights="none" pattern="PS" /> <policy domain="coder" rights="none" pattern="EPS" /> <policy domain="coder" rights="none" pattern="PDF" /> <policy domain="coder" rights="none" pattern="XPS" /> Check with your vendor for the proper location of this file on your platform. [ https://www.kb.cert.org/vuls/id/332928 ] GENTOO: Status: Unknown. If you are the vendor named above, please contact us to update your status. [ https://www.kb.cert.org/vuls/id/CHEU-B3UKMB ]
Proposed temporary WORKAROUND: "disable the processing of PS, EPS, PDF, and XPS content" as described above.
The initial problem is that Ghostscript can be abused to run unsafe operation although "-dSAFER" is used. One vector is using an image processing tool like media-gfx/imagemagick. An attacker could, for example, uploaded a malicious image to a web application which uses imagemagick to process (e.g. convert) the user generated content. Even if you have built media-gfx/imagemagick *without* USE=postscript, you are affected. Therefore Gentoo follows recommendation and installs a policy.xml file now by default which will disable PS, EPS, PDF, and XPS coders: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=02765dfc333e578af9e3fd525fc0067dc47d6528
(In reply to Thomas Deutschmann from comment #2) > Therefore Gentoo follows recommendation and installs a policy.xml file now > by default which will disable PS, EPS, PDF, and XPS coders: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=02765dfc333e578af9e3fd525fc0067dc47d6528 Please link to this bug in the elog message.
This is also exploitable via Nautilus and likely a ton of other vectors.
Yes, but this one is only about hardening of media-gfx/imagemagick. Keep in mind: In theory this shouldn't be needed if everyone would do it the right way. I.e. if you get untrusted input you should at least know what you expect. When you expect a PNG image, you should call > convert png:<untrusted input> output.jpg and *not* > convert <untrusted input> output.jpg Because when you don't specify input format, ImageMagick will apply some magic and probably execute the untrusted input like *documented*. So nobdoy should be really surprised that IM will execute GS/PS or other things when available and you tell IM "execute whatever I give you" :) The new policy.xml will at least prevent that IM can be used to run PS, EPS, PDF, and XPS, e.g. formats which can contain arbitrary code. And no, I will not talk about the idea to allow executing of arbitrary files which can contain arbitrary code because files are written in a 'dynamic' language in general. E.g. what do people expect?! Did anyone really believe "It is a complete language but -dSAFER will filter *any* *potential* instruction which could be abused"? So yes, any other application/library which will do same magic and execute the file in the end is somehow "affected" and can be abused.
The hardening policy is incomplete, CERT/CC has a more complete policy: https://www.kb.cert.org/vuls/id/332928 Particularly we miss the PS2/PS3 parts. Update policy from CERT/CC: <policy domain="coder" rights="none" pattern="PS" /> <policy domain="coder" rights="none" pattern="PS2" /> <policy domain="coder" rights="none" pattern="PS3" /> <policy domain="coder" rights="none" pattern="EPS" /> <policy domain="coder" rights="none" pattern="PDF" /> <policy domain="coder" rights="none" pattern="XPS" /> Right now in Gentoo: <policy domain="coder" rights="none" pattern="PS" /> <policy domain="coder" rights="none" pattern="EPS" /> <policy domain="coder" rights="none" pattern="PDF" /> <policy domain="coder" rights="none" pattern="XPS" />
(In reply to Hanno Boeck from comment #6) > The hardening policy is incomplete, CERT/CC has a more complete policy: ...................... ^^ ......... ...................... was ......... Obviously they must have realized the leakage and added an amendment in between: (citation from comment #0) > <policy domain="coder" rights="none" pattern="PS" /> > <policy domain="coder" rights="none" pattern="EPS" /> > <policy domain="coder" rights="none" pattern="PDF" /> > <policy domain="coder" rights="none" pattern="XPS" /> But yes, sure, let's incorporate those two also.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df7afbda6b12a68578833225e694cee011b20342 commit df7afbda6b12a68578833225e694cee011b20342 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-08-24 14:33:55 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-08-24 14:34:15 +0000 media-gfx/imagemagick: extend hardening - PS2 and PS3 coders are now disabled by default, too. - Instead of patching, we now use sed which should make it easier to extend policy.xml in future. Bug: https://bugs.gentoo.org/664236 Package-Manager: Portage-2.3.48, Repoman-2.3.10 RepoMan-Options: --force media-gfx/imagemagick/files/policy-hardening.patch | 15 -------------- .../imagemagick/files/policy-hardening.snippet | 9 ++++++++ ...0-r1.ebuild => imagemagick-6.9.10.10-r2.ebuild} | 22 ++++++++++++++------ ...10-r1.ebuild => imagemagick-7.0.8.10-r2.ebuild} | 24 +++++++++++++++------- media-gfx/imagemagick/imagemagick-9999.ebuild | 22 ++++++++++++++------ 5 files changed, 58 insertions(+), 34 deletions(-)
Hi, the ban of pdf/eps conversion in imagemagick is showstopper for app-office/lyx. vector graphics is arguably #1 input format of graphics there and after portage update it will stop work out of blue for its users. What can we do for the user now? Is this ban temporary or longterm? What about issuing news how to allow imagemagick to run locally if someone really needs it?
No, it is not temporary. The problem is the auto-magic within ImageMagick: If you don't limit input format, ImageMagick will execute whatever it will detect. So if GS is available on your system, IM will execute GS whenever it will find GS in specified input. PDF/EPS is a container format which could have GS embedded. :/ If user really needs a blocked format the user has to explicit allow that format by altering policy.xml file. Thanks to Gentoo's config protection feature, such changes will be preserved in future updates (i.e. when using dispatch-conf/etc-update user will be prompted). We don't plan to introduce a USE flag to control hardening because this would allow other packages to depend on "-<hardening-USE-flag>" and put users who aren't aware of that risk in danger. PS: You can always put something like > <policy domain="coder" rights="read|write" pattern="PDF" /> in ${HOME}/.config/ImageMagick/policy.xml to overwrite /etc/ImageMagi*/policy.xml for local users for example.
What about just allowing writing PDFs by default? As far as I understand, the security issue is just with reading, no?
(In reply to Moshe Kamensky from comment #11) > What about just allowing writing PDFs by default? As far as I understand, > the security issue is just with reading, no? That's a good question I cannot answer for sure. Please raise question upstream/join discussion on oss-security mailing list. But for now we will keep policy which will disable these coders completely which is the new default in Debian, Ubuntu, RedHat, OpenSUSE... If you know what you are doing feel free to alter these settings. See previous comment, you can do that even per user...
(In reply to Thomas Deutschmann from comment #12) > ... But for now we will > keep policy which will disable these coders completely which is the new > default in Debian, Ubuntu, RedHat, OpenSUSE... (In reply to Manfred Knick from comment #0) > GENTOO: Status: > > Unknown. > If you are the vendor named above, please contact us to update your status. > > [ https://www.kb.cert.org/vuls/id/CHEU-B3UKMB ] @ Thomas: Perhaps that can be upgraded correspondingly to above state now?
(In reply to Manfred Knick from comment #13) > @ Thomas: Perhaps that can be upgraded correspondingly to above state now? Gentoo sec project is currently not functional. The corresponding GLSA is pending since Wed, 22 Aug 18 18:06 ... but we need an advisory before we can update Cert status.
The current customised policy seems not functional and breaks documented default format. I hit this bug during converting *.jpg to pdf: convert `ls -1v` file.pdf convert: not authorized `PDF' @ error/constitute.c/IsCoderAuthorized/408 I tried to specify the format but it did not help: convert jpg:1_00001.jpg pdf:file.pdf convert: not authorized `PDF' @ error/constitute.c/IsCoderAuthorized/408.
This issue was resolved and addressed in GLSA 201810-04 at https://security.gentoo.org/glsa/201810-04 by GLSA coordinator Aaron Bauman (b-man).
The vulnerability is in ghostscript-gpl, which is already at fixed version after https://bugs.gentoo.org/635426 I think that cutting off commonly used functionality out of imagemagick could be revised. The exploit for imagemagick need to be checked against the new version of ghostscript-gpl-9.25
testsuite can be found here https://bugs.chromium.org/p/project-zero/issues/detail?id=1640
This changes br0ke documentation generation for some packages
(In reply to Alexey Shvetsov from comment #19) > This changes br0ke documentation generation for some packages Can you name some packages? Fix should be to create a policy in portage's home in src_*, see https://bugs.gentoo.org/664236#c10
Package is gromacs for example (gromacs-2019)
The mitigation is still in place, at least it was in my system, while all ghostscript versions in the tree are not vulnerable any more according to CERT. The changes mentioned above should probably be removed from /etc/ImageMagick-7/policy.xml .
I second that. Probably safe to remove these.
I just ran into this today while trying to feed a PDF as input into ImageMagick's 'convert' program. Please remove the obsolete mitigation.
(In reply to Matt Whitlock from comment #24) > I just ran into this today while trying to feed a PDF as input into > ImageMagick's 'convert' program. Please remove the obsolete mitigation. Please file a new bug. Note that this was discussed in bug 716674.
