lolloj - Fotolia
More Ghostscript vulnerabilities, more PostScript problems
Researchers keep finding PostScript interpreter bugs. Find out how a new Ghostscript vulnerability enables remote code execution against web services and Linux desktop users.
Users of Ghostscript software are in danger, and many may be unaware of it because they do not realize that the web application service or Linux desktop app they're using calls on Ghostscript to process image files -- something that happens surprisingly often.
The latest Ghostscript vulnerability is a severe remote code execution flaw that was published along with a working exploit that could enable both remote code execution and denial-of-service attacks by remote attackers, with a low level of attack complexity.
Because the current version of Ghostscript -- 9.26 -- is vulnerable, users need to manually patch the bug to mitigate this vulnerability. Tavis Ormandy of Google's Project Zero recently shared the vulnerability, along with proof-of-concept exploit code demonstrating the ease with which an attacker could exploit the flaw.
Attackers and defenders alike have long known that PostScript can be exploited; this is far from the first PostScript-related bug. Ormandy reported a similar PostScript bug in 2016 and other related bugs since then on a regular basis.
While the PostScript vulnerabilities may differ in details, they all share the same underlying cause: PostScript itself is a powerful programming language that attackers can exploit.
Ghostscript is an interpreter for documents that use the PostScript file format programming language, which is widely used by printers to render document files into printable images. While its purpose is to describe documents for display, and most PostScript code is used to define how a document appears, it can also be used to execute malicious code and access files. As a fully featured interpreter of the PostScript language, Ghostscript executes code by design.
It isn't a good idea to execute code when interpreting any document files acquired from untrusted sources, so Ghostscript implements a simple command-line switch -- the -dSAFER flag -- which, when set, enables the execution of PostScript files while disabling the ability to execute external code or modify the files. This type of configuration flag is commonly used to turn software features on or off, and, at least in theory, this approach is an attempt to create a sandboxed environment. However, the bugs reported in recent years demonstrate that this approach doesn't work very well.
Most of the Ghostscript vulnerabilities that enable remote code execution give attackers the ability to trick PostScript's restricted mode, and because PostScript is a powerful programming language, there are many ways to exploit the interpreter. Many of them allow attackers to bypass the restrictions of the -dSAFER flag.
What's so scary about Ghostscript vulnerabilities?
Few people create and share raw PostScript documents, so it might seem like the impact of these flaws would be limited. Yet, Ghostscript is used automatically in many situations, often without the knowledge of the user.
Two different attack scenarios are especially troubling: exploits of web services that depend on the ImageMagick library and exploits of features incorporated into Linux desktop environments.
ImageMagick is a suite of command-line utilities for converting and manipulating a wide variety of image file formats, and these utilities are often incorporated into other software. For example, when web services do any kind of image manipulation, such as enabling users to upload and resize profile pictures or providing previews of uploaded files, they often use ImageMagick on the back end. ImageMagick also accepts PostScript files and processes those images with Ghostscript.
Worse, ImageMagick doesn't use the file extension to determine the format of an input file, but instead guesses the file format depending on the content of the file. So even if a webpage restricts file uploads to common extensions -- like JPG files -- passing those uploaded files to ImageMagick risks exposing them to the Ghostscript parser. An attacker merely has to rename a malicious PostScript file and give it a JPG extension to get Ghostscript to execute it.
It's possible to configure ImageMagick to disable the PostScript parser by modifying its policy.xml file, and the security advisory of the CERT Coordination Center at Carnegie Mellon University's Software Engineering Institute contains sample configuration lines that users can copy into their ImageMagick settings.
However, this approach to mitigation comes with its own drawbacks. To be completely safe from Ghostscript exploits, users need to disable support for other formats -- such as the popular PDF format --because those files can also embed malicious PostScript code, which Ghostscript would execute, as well.
The use of ImageMagick with an enabled Ghostscript back end is widespread. Jens Müller, who researches printer and PostScript security at Germany's Ruhr-University Bochum, has found code execution bugs caused by the use of ImageMagick and Ghostscript in services like Wikipedia, Steam and Microsoft OneDrive. I recently found a similar flaw in Mozilla's Pocket service.
The trouble with Ghostscript: Linux
On Linux desktop systems, Ghostscript can become a threat in quite a different way than it is for web applications. Linux desktop environments like Gnome and KDE contain many features that automatically parse files without any user interaction. Both popular desktops have file search tools -- Tracker in Gnome and Baloo in KDE -- that index all of a user's files automatically in the background and use different software packages to do the parsing.
As a result, simply storing a malicious PostScript file that contains an exploit in a user's Download directory can be enough to launch an attack. This is exacerbated by the fact that with Google's Chrome browser, a webpage can automatically trigger a file download with no user interaction. This is not just a risk due to Ghostscript, as software that processes other file formats can also contain security bugs.
Thumbnail creation tools pose another risk for Linux users. The document viewer Evince, which is part of the Gnome project, installs a small tool for file managers to create preview images. For PostScript files, it uses Ghostscript.
In response to security concerns, Evince has disabled PostScript support by default. But many Linux distributions still use it. The thumbnail creation process is standardized and, thus, all file managers supporting that standard will make use of the installed thumbnail tool.
Gnome developers have responded to this vulnerability by introducing sandboxing during the thumbnailing process for Tracker, the desktop file system indexer and search tool. They can use a sandboxing implementation called Bubblewrap, but only if it's available on the systems. No such sandboxing exists on other desktop environments, like KDE or Xfce.
In practice, the sandbox often isn't available even in Gnome. For example, in the current version of Ubuntu, the Bubblewrap sandbox is disabled. This doesn't mean PostScript code is allowed to run without limits: Ubuntu restricts the processes using the AppArmor security framework, but this restriction is limited.
Jann Horn, who also works for Project Zero, found a bypass for that protection last year. While that specific bypass has been fixed, Ormandy warned in his report about the latest Ghostscript bug: "Do not count on AppArmor protecting you, the policy is very relaxed."
Who's responsible for Ghostscript vulnerabilities?
Ghostscript, originally published under an open source license, is currently also available under a commercial license from Artifex Software Inc., the company that controls the Ghostscript project. The company has struggled with these issues, having made multiple incomplete attempts to fix them. Ormandy's frustration with Artifex's response was evident in his most recent bug report describing the need for multiple attempts to get a working patch.
While the bug is fixed now in Ghostscript's Git code repository, the latest release is still vulnerable. When contacted for comment on the vulnerability, Artifex replied: "The vulnerability you are referring to has in fact been fixed, and we will fix new problems if they arise." The company didn't respond to questions about why the fix wasn't released -- or whether it has plans to tackle the underlying problem of file and execution operations in Ghostscript in a more general way. So it doesn't appear the flood of Ghostscript remote code execution bugs will stop any time soon.
This begs the question of whether users should try to avoid the Ghostscript software altogether -- which, in itself, is problematic because Ghostscript is the only open source PostScript parser available. A safer alternative does not exist.
The PostScript format had some popularity in the past, particularly for the publication of scientific papers, which were commonly shared as PostScript files. But PostScript files have been largely replaced with PDFs.
While PDF viewers have had their fair share of security issues, as well, they don't seem to suffer from the systemic and easy-to-exploit code execution bugs that Ghostscript is vulnerable to. All mainstream browsers have embedded PDF viewers that receive a lot of security testing, and they should be relatively safe options.
For security reasons, it may be best to avoid PostScript files whenever possible and to disable the Ghostscript parser in places where it might get executed automatically.
