Page MenuHomePhabricator

Multiple ghostscript vulnerabilities
Closed, ResolvedPublic


On oss-security, Travis Ormandy reported an issue which allows the filesystem to be read and file contents to be accessed by taking advantage of an error in the implementation of Ghostscript invocation with -dSAFER:

Tavis observed the issue in the context the ImageMagick identify command, but the issue affects any program which uses Ghostscript.

A bug report has been submitted to Ghostscript, but has not yet been acted on.

We need to determine the extent to which we are susceptible to this issue (i.e., which extensions are affected, if any, besides PdfHandler and Math), then implement a temporary mitigation until the issue is fixed upstream and packages are released for our production OS'es.

Hat tip to @csteipp for bringing it to my attention on IRC.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 30 2016, 1:26 AM
dpatrick renamed this task from File enumeration possible via ghostscript input processing to File enumeration possible via Ghostscript input processing.Sep 30 2016, 1:27 AM
dpatrick triaged this task as Unbreak Now! priority.
dpatrick updated the task description. (Show Details)

That's not a concern for us. All the files managed by us that are accessible by an unprivileged user are publicly available in puppet anyway and on the image scalers ghostscript is additionally contained by firejail.

Later mesages in the thread suggest its possible to execute arbitrary code if you can give a ps file to ghostscript (or convert) even with -dSAFER set.


convert is fully contained in firejail, the conversion process runs with all privileges dropped, without network and with a seccomp filter.

But the PdfHandler extension shells out to ghostscript and might be affected, needs to be checked. There's no upstream fix on the ghostscript side yet, though.

dpatrick updated the task description. (Show Details)Oct 1 2016, 1:05 AM

But the PdfHandler extension shells out to ghostscript and might be affected, needs to be checked. There's no upstream fix on the ghostscript side yet, though.

PdfHandler uses both convert and gs, neither of which are currently contained by firejail in production.

Is it possible to use firejail in a pipeline, as ghostscript and convert are used at If so, can we set $wgPdfProcessor and $wgPdfPostProcessor to /usr/local/bin/mediawiki-firejail-ghostscript and /usr/local/bin/mediawiki-firejail-convert, respectively?

If it can't be used in a pipeline, can we add a config parameter which will wrap the full invocation of the pipeline at in a firejail-ed call to bash -c?

A wrapper for convert is already present on all app servers: /usr/local/bin/mediawiki-firejail-convert

I've created to provide a similar wrapper for ghostscript. I don't know how the PdfHandlerExtension works, though, but maybe you could cherrypick the patch to beta and run some tests with the settings in beta?

I tracked this down a little further: There are three issues around:

  • file enumeration via getenv, filenameforall. This was assigned CVE-2013-5653 and affects jessie (but not trusty)
  • Information disclosure via .libfile. This doesn't have a CVE ID and affects trusty and jessie.
  • Arbitrary code execution via .putdeviceparams. This also doesn't have a CVE ID, but doesn't affect neither trusty or jessie (it relies on a later regression).

The first two issues are insignificant for our use case, the conversions run with the www-data user, which does not have access to anything sensitive not already publicly available.

Still, we should work on containing the pdfhandler extension with high priority (there might be further things lurking in the ghostscript codebase). I'll work on the server-side changes today.

MoritzMuehlenhoff renamed this task from File enumeration possible via Ghostscript input processing to Multiple ghostscript vulnerabilities.Oct 4 2016, 7:46 AM
MoritzMuehlenhoff lowered the priority of this task from Unbreak Now! to High.
Krenair added a subscriber: Krenair.Oct 4 2016, 8:48 AM

The www-data user has access to all the mediawiki secrets like database passwords and other sensitive things

The second issue still needs shell access to exploit it.

I've merged into ops/puppet, which installs /usr/local/bin/mediawiki-firejail-ghostscript on all app servers. This is a wrapper, which runs gs with a firejail profile, which prevents network access, drops all caps, enables a seccomp filter and blacklists /home, /sbin/, /usr/sbin and various core system files/commands.

I've tested a few invocations by copying a postscript file to /tmp and running /usr/local/bin/mediawiki-firejail-ghostscript on it.

I'm not sure how the PdfHandler extension works/how to test it, but extensions/PdfHandler/extension.json configures PdfProcessor to "gs" (which should use an absolute pathname BTW), so configuring it to /usr/local/bin/mediawiki-firejail-ghostscrip should be all that's needed. @dpatrick, could you take it from here?

greg added a subscriber: greg.Oct 4 2016, 4:17 PM
Bawolff claimed this task.Oct 4 2016, 8:09 PM

I'll be testing this, this week.

Bawolff removed Bawolff as the assignee of this task.Oct 5 2016, 9:45 PM
Reedy added a subscriber: Reedy.Aug 5 2017, 2:14 AM
$wgPdfProcessor = '/usr/local/bin/mediawiki-firejail-ghostscript';

I guess this was all fixed by T164000

Anyone adverse to resolving this bug and opening it up?

MoritzMuehlenhoff closed this task as Resolved.Aug 5 2017, 11:55 AM
MoritzMuehlenhoff claimed this task.

The underlying ghostscript vulnerabilities have been fixed/rolled out on the production cluster for a long time, closing.

Reedy changed the visibility from "Custom Policy" to "Public (No Login Required)".Aug 5 2017, 1:38 PM