Key Takeaways
- Vulnerability disclosed in Ghostscript prior to version 10.01.2 leads to code execution.
- Exploitation can occur upon opening a file.
- Ghostscript is used heavily in Linux and is often installed by default.
- Windows Open-Source productivity and creativity tools such as Inkscape use the Ghostscript windows port.
- The Kroll Cyber Threat Intelligence (CTI) team has developed a viable exploit for this vulnerability and is using it to advance detection efforts.
- Organizations can take action by updating to the version of Ghostscript with the security patch applied.
Overview
Ghostscript, an open-source interpreter for the PostScript language and PDF files, recently disclosed a vulnerability prior to the 10.01.2 version. This vulnerability CVE-2023-36664 was assigned a CVSS score of 9.8 that could allow for code execution caused by Ghostscript mishandling permission validation for pipe devices (with the %pipe% or the | pipe character prefix).
Debian released a security advisory mentioning possible execution of arbitrary commands:
“It was discovered that Ghostscript, the GPL PostScript/PDF interpreter, does not properly handle permission validation for pipe devices, which could result in the execution of arbitrary commands if malformed document files are processed.”
Ghostscript Usage
Ghostscript was first released in 1988 and has been part of many distributions default installs. t is rarely used directly, it is frequently utilized by other open-source software packages to help with printing or converting files. It is a required dependency for “cups-filters,” which is a core component of the Common Unix Printing System (CUPS), Linux’s primary mechanism for printing and print services. Other applications make use of Ghostscript for reading and saving PostScript (PS), Embedded PostScript (EPS) or PDF files. On a Debian 12 system, 131 packages depend on Ghostscript. The list of applications that use Ghostscript includes notable desktop and productivity applications such as LibreOffice, Inkscape and Scribus, along with other tools such as ImageMagick (which itself is a dependency of many important applications). When the applications that use Ghostscript are ported to other operating systems such as Windows, they will continue to use a port of Ghostscript on the new operating system, this means that rather than impacting only one operating system, the vulnerability has the potential to affect many, particularly, those with printing or publishing applications that make use of open-source components.
Vulnerability
This vulnerability disclosure indicates that the issue relates to operating system pipes, which are a mechanism for separate pieces of software to talk to each other through the output of one application being the input of another. These pipes are often represented by the “|” symbol on the command line, for example:
cat /etc/hosts | grep localhost
In this case, the cat command is “piping” its output to the grep command, which is filtering that output to only the lines that contain the “localhost” string.
The How to Use Ghostscript documentation on the Ghostscript website details how to use pipes within a command.
The vulnerability description also states that the issue relates to a permissions validation.
Upon investigating the Git history of the Ghostscript package, it is possible to find the commits associated with these issues, including one referencing the %pipe% device.
The new code wraps the call to the function “gp_file_name_reduce()” inside an “if” block, and it will only allow it to be executed if the path passed in does not start with the string “%pipe”.
Figure 1- Git Commit to Fix Vulnerability
The new functionality to protect the call to “gp_file_name_reduce” indicates that the vulnerability is likely in that code path.
Figure 2 - Vulnerable Function Showing Comments Indicating Purpose
From the comments in the gp_file_name_combine_generic function, we can see its purpose: it takes multiple paths, combines them and attempts to simplify them by removing relative path references where appropriate. This, combined with the commit comments, indicates that if a specially crafted path is passed in, it might be possible to make this function return something other than what is expected.
Figure 3 - File Open Function, Triggering Validation Code Path
It is evident that the file open function, along with several other file-related functions, makes calls to the “gp_validate_path” in order to decide whether to proceed with file IO requests.
Figure 4 - Validate Function Called with Path from Outputted from Vulnerable Function
The function “gp_validate_path” is a wrapper for ”gp_validate_path_len”, which uses a validate function to check if it’s allowed to write to a certain location. This location has been modified by the vulnerable function “gp_file_name_reduce” before it is used in the validate function, leading to full exploitation.
Figure 5 - Screenshot of Successful Exploitation from POC File Being Loaded into LibreOffice
In order to validate whether the above vulnerability is exploitable, and to find out if it can be triggered by simply opening a file, the Kroll CTI team has developed a working Proof of Concept (POC) that is triggered simply by opening an Embedded PostScript (EPS) file in Ghostscript directly, or via an application that uses Ghostscript for processing files. View the video below to see the exploit running.
