Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 664236 (CVE-2018-16509) - <media-gfx/imagemagick-{6.9.10.10-r1,7.0.8.10-r1}: Ghostscript can be abused to execute arbitrary code (VU#332928)
Summary: <media-gfx/imagemagick-{6.9.10.10-r1,7.0.8.10-r1}: Ghostscript can be abused ...
Status: RESOLVED FIXED
Alias: CVE-2018-16509
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL: https://www.kb.cert.org/vuls/id/332928
Whiteboard: B2 [glsa+ cve]
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-22 09:00 UTC by Manfred Knick
Modified: 2024-01-04 07:17 UTC (History)
11 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Manfred Knick 2018-08-22 09:00:16 UTC
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 ]
Comment 1 Manfred Knick 2018-08-22 09:03:35 UTC
Proposed temporary

     WORKAROUND:

     "disable the processing of PS, EPS, PDF, and XPS content"

as described above.
Comment 2 Thomas Deutschmann (RETIRED) gentoo-dev 2018-08-22 13:00:28 UTC
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
Comment 3 Diogo Pereira 2018-08-22 16:27:27 UTC
(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.
Comment 4 Hanno Böck gentoo-dev 2018-08-23 06:28:43 UTC
This is also exploitable via Nautilus and likely a ton of other vectors.
Comment 5 Thomas Deutschmann (RETIRED) gentoo-dev 2018-08-23 15:33:08 UTC
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.
Comment 6 Hanno Böck gentoo-dev 2018-08-24 08:17:22 UTC
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" />
Comment 7 Manfred Knick 2018-08-24 09:27:42 UTC
(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.
Comment 8 Larry the Git Cow gentoo-dev 2018-08-24 14:34:58 UTC
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(-)
Comment 9 pavel sanda 2018-09-02 10:29:55 UTC
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?
Comment 10 Thomas Deutschmann (RETIRED) gentoo-dev 2018-09-02 12:32:28 UTC
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.
Comment 11 Moshe Kamensky 2018-09-09 10:40:48 UTC
What about just allowing writing PDFs by default? As far as I understand, the security issue is just with reading, no?
Comment 12 Thomas Deutschmann (RETIRED) gentoo-dev 2018-09-09 23:42:53 UTC
(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...
Comment 13 Manfred Knick 2018-09-10 10:53:07 UTC
(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?
Comment 14 Thomas Deutschmann (RETIRED) gentoo-dev 2018-09-18 21:59:36 UTC
(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.
Comment 15 Anton Bolshakov 2018-09-25 03:29:27 UTC
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.
Comment 16 GLSAMaker/CVETool Bot gentoo-dev 2018-10-06 17:10:44 UTC
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).
Comment 17 Oleh 2018-10-07 02:01:06 UTC
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
Comment 18 Oleh 2018-10-07 02:18:21 UTC
testsuite can be found here
https://bugs.chromium.org/p/project-zero/issues/detail?id=1640
Comment 19 Alexey Shvetsov archtester gentoo-dev 2018-10-22 21:13:27 UTC
This changes br0ke documentation generation for some packages
Comment 20 Thomas Deutschmann (RETIRED) gentoo-dev 2018-10-22 21:52:24 UTC
(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
Comment 21 Alexey Shvetsov archtester gentoo-dev 2018-12-14 19:35:24 UTC
Package is gromacs for example (gromacs-2019)
Comment 22 Thomas R. (TRauMa) 2020-02-18 11:19:52 UTC
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 .
Comment 23 Livid 2020-05-23 05:23:48 UTC
I second that. Probably safe to remove these.
Comment 24 Matt Whitlock 2020-06-30 00:42:33 UTC
I just ran into this today while trying to feed a PDF as input into ImageMagick's 'convert' program. Please remove the obsolete mitigation.
Comment 25 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-10-22 13:19:31 UTC
(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.