Security Hardening Ghostscript
By Chris Liddell - Tuesday, October 15, 2019
The last three years have seen a number of well-publicized security vulnerabilities involving Ghostscript. Some of the publicity that surrounded these was sensationalized, causing undue panic and concern, (for example, there has never been an exploit proven to allow hijacking of a user’s system). Nevertheless, there have been several genuine “data leaking” exploits which we did, and do, take extremely seriously. PostScript and, to some extent, PDF have technical and user perception issues that make them a rare challenge where security is concerned.
It is often overlooked that PostScript is not just a page description language (PDL) but also a powerful object-oriented programming language. Additionally, PostScript includes operators for reading, writing and manipulating files and file systems.
Modern users understand that a programming language with file access capabilities will be vulnerable to security implications. But when PostScript was designed, security exploits were almost non-existent and therefore, no provisions were designed into the language for limiting access to the file system.
This represents an even greater risk when end-users willingly take PostScript (or PDF) files from unknown/untrusted sources, and run them without fully understanding the implications of such actions. Generally, modern users would not execute a Unix shell script, or Windows batch file, without knowing its providence, but are willing to do so with PostScript and PDF files.
When it became clear that security exploits were becoming more prevalent, steps were taken to allow control over file access in Ghostscript (PostScript itself has not been updated with these features).
These controls were initially focused on file and file system accesses explicitly from PostScript programs, and as such, were implemented in the PostScript interpreter, and used PostScript objects and virtual memory to store its data.
File accesses triggered implicitly, such as using the “OutputFile” device parameter, or the ICC profile files which are defined as user parameters, were either controlled by limiting certain aspects of PostScript (“setpagedevice”) or tacked-on as required.
As hacks and hackers became more sophisticated, it became clear that an early, core architecture decision made in Ghostscript made it almost impossible to completely secure the PostScript environment, specifically those file and file system controls. In addition, the limitations placed on PostScript’s device configuration (“setpagedevice”) meant a number of real-world jobs and industry standard test files, would fail, or produce unexpected results when run with the controls active.
Clearly, a new approach was required, one which removed the vulnerability implied by those early design decisions, whilst not requiring a major rewrite of the PostScript interpreter.
Inherent in the Ghostscript architecture is a separation between the interpreter(s) (PostScript/PDF, PCL/PXL, XPS), and the “core”. That core is where rendering, halftoning, color management, etc. occurs. It’s also where the interaction with the host operating system is handled, including interactions such as memory management and filesystem access.
Artifex engineers determined the best solution was to implement a new set of file access controls built into the core, at the level of the file system interaction with the host operating system, ensuring all file accesses in Ghostscript are subject to those controls (the same controls will be rolled into the PCL/PXL/PJL and XPS interpreters in a subsequent release).
Most importantly, the lists of directories and files that Ghostscript is permitted to read/write/control are no longer reliant on PostScript object storage, nor features of the PostScript interpreter. These lists are now stored in memory which cannot be accessed nor influenced by PostScript once the controls are activated. However, it ispossible to add paths to those lists before the controls are activated. Once the file access controls are activated in a Ghostscript instance, they cannot be deactivated.
Because the controls cover all file accesses, we no longer need to hobble Postscript’s device configuration, therefore “setpagedevice” works as intended.
It is important to note, the file access controls are now active by default. If a workflow requires running without such controls, then they can be deactivated by using the “-dNOSAFER” command line option.
We have tried to make user interaction with these new controls the same as in previous versions. The intent being that for the vast majority of users, the vast majority of the time, there will be no noticeable differences.
Nevertheless, some users will require more flexibility, so there are new custom PostScript operators:
.addcontrolpath
.activatepathcontrol
.currentpathcontrolstate
documented in doc/Language.htm
And four new command line parameters:
–permit-file-read
–permit-file-write
–permit-file-control
–permit-file-all
documented in doc/Use.htm
These allow the user to have more explicit control over what is added to each of the read/write/control lists.
The old behavior can still be accessed, by using the command line parameter “-dOLDSAFER”. However, we do not recommend this approach and encourage you to contact Artifex to discuss your options.