Bug 699676

Summary:	PDF interpreter can leave dangerous operators available
Product:	Ghostscript	Reporter:	Ken Sharp <ken.sharp>
Component:	Security (public)	Assignee:	Chris Liddell (chrisl) <chris.liddell>
Status:	RESOLVED FIXED
Severity:	normal	CC:	cbuissar, taviso
Priority:	P4
Version:	unspecified
Hardware:	PC
OS:	Windows 7
Customer:		Word Size:	---

Description Ken Sharp 2018-08-27 10:35:47 UTC

This started in bug #699671, see Comment #1 from Ray.

Because this is a different problem to the original report (really, quite a different problem) I've chosen to make a new report here for it.

Essentially the problem is that runpdfbegin pushes a dictionary which contains procedures (executable arrays in PostScript). Some of those procedures use operators which have potentially dangerous effects and are not supposed to be available after startup. Of course an array which is not executeonly can be read, and the operator definition repurposed.

We need to check considerably more than just the PDF interpreter, there are numerous procedures stored in systemdict and its subsidiary dictionaries, many of which are also not created with the executeonly attribute. We need to check/modify *all* of them.

Text of original comment :
I didn't understand (at first) the "appears to expose undefined names".

What it does when "runpdfbegin" stops is that it leaves GS_PDF_ProcSet on
the dict stack, and apparently the "CS" proc in that causes a segfault.

The GS_PDF_ProcSet is currently in userdict, and items can be loaded from it.

A more serious issue is that the dictionary is DANGEROUS, so I have changed
this to P1, critical. I have a PoC that allows access to systemdict, so pretty
much anything can be done.

We need to make sure this dictionary isn't left laying around in userdict,
and make sure the PDF interpreter never leaves it (or other PDF interpreter
procset dicts) on the dict stack after an error, and (for extra precaution)
make it executeonly.

As a lower priority, we may want to scan the various procs to make sure that
none of them can cause segfaults (as CS does in this example).

Comment 1 Ken Sharp 2018-08-27 10:40:12 UTC

Add Tavis to this report as a courtesy, otherwise he won't be able to see it.

Comment 2 Ken Sharp 2018-08-28 13:06:17 UTC

This very large commit 4b00990640258f464b02ce3f721a22fcb59b289b makes almost all the PDF interpreter functions executeonly, which prevents anyone from reading their contents, and copying any dangerous operators that may be present.

There is one case (text redefinitions of basic path construction) where we cna't do this; the reason is an ugly hack for an invalid PDF file. To detect and fix the invalid file, we inspect the path construction operators. If we make them executeonly, then that fails.

However, the routines called by those pieces of code are themselves executeonly, so there is no possibility of exploiting them.