This article is more than 1 year old

When something's weird in your ImageMagick upload, who ya gonna call? Ghostbusters!

Evil files bypass GhostScript sandbox, run malicious code

GhostScript's security sandbox is so weak, website admins, developers, and users should block ImageMagick and other tools from using the software altogether.

Returning from a sabbatical, noted Google Project Zero researcher Tavis Ormandy this week emitted new ways to execute arbitrary code on vulnerable servers and similar machines that process incoming files using GhostScript. He said exploitation is possible against pic wrangling toolkit ImageMagick, file viewer Evince, image editor Gimp, and other programs that pass data to GhostScript to process.

Earlier this week, Ormandy tweeted the bottom line: “This is your annual reminder to disable all the GhostScript coders in policy.xml.” He was referring back to an ImageMagick-related vuln disclosed in April 2017, and the policy.xml configuration file for controlling access to ImageMagick handlers.

Essentially, if you run a website, or app or some other online service, that uses ImageMagick to process user-submitted pictures – such as photos to turn into account profile pics – you should update your policy.xml to block any GhostScript code from running. What can happen is, a miscreant can upload a file – say, myface.png – and embed some PostScript in it that, when passed to a GhostScript handler via ImageMagick, triggers the execution of a smuggled-in command. That would allow scumbags to submit files to run malicious commands and hijack your computer systems.

Blame GhostScript

Crucially, the problem is not within ImageMagick, Evince, GIMP, etc – it's in the GhostScript backend they rely on. Right now, the best way to protect yourself is to disable any GhostScript handlers.

This CERT advisory also summarizes the issue: “Ghostscript contains multiple -dSAFER sandbox bypass vulnerabilities, which may allow a remote, unauthenticated attacker to execute arbitrary commands on a vulnerable system.”

Ormandy explained the technical details in this mailing list post, which leads with: “I strongly suggest that distributions start disabling PS, EPS, PDF and XPS coders in policy.xml by default.”

According to the Googler, an attacker can get past the sandbox by abusing a broken error handler, /invalidaccess; a bug in setcolor; a type confusion problem because LockDistillerParams isn't type-checked; and .tempfile permissions were broken at some point, so an attacker can create files at an arbitrary location.

And those were just what Ormandy found with a manual scan of the code. He's writing a fuzzer for Ghostscript, which should provide plenty of entertainment in the future.

“IMHO, -dSAFER is a fragile security boundary at the moment, and executing untrusted postscript should be discouraged, at least by default”, he added.

The CERT advisory provides an example of how to block GhostScript processing, assuming a Red Hat system. The sysadmin should add the following lines to the <policymap> section of /etc/ImageMagick/policy.xml:

<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" />

Get busy, sysadmins. As far as we're aware, no patches are available short of altering your policy.xml file, or removing any code that passes untrusted data to GhostScript. ®

More about

More about

More about


Send us news

Other stories you might like