Bug 699708

Summary:	Security review bug - Error handling
Product:	Ghostscript	Reporter:	Ken Sharp <ken.sharp>
Component:	Security (public)	Assignee:	Ray Johnston <ray.johnston>
Status:	RESOLVED FIXED
Severity:	normal	CC:	cbuissar, chris.liddell
Priority:	P4
Version:	unspecified
Hardware:	PC
OS:	Windows 7
Customer:		Word Size:	---

Description Ken Sharp 2018-09-04 15:45:24 UTC

See the Twiki, Admin web GhostscriptSecurity

" Another one of Tavis's more complex vectors involved redefining the error handler. Our code generally assumes that when an error is raised, we're done, this is particularly true of the current PDF interpreter. But redefining the error handler to throw away the errors means that the (PostScript) code can continue to execute.

There's no practical way for us to audit the code to be certain that this can never cause a problem. However, what we can do, at least for -dSAFER, is 'lock' the error handling, so that it can't be overwritten, so the program will stop as we expect.

Chris reminded me that this feature was an absolute requirement of a printer manufacturer we dealt with back at Global Graphics, so its almost certainly something we should have anyway. "

Comment 1 Chris Liddell (chrisl) 2018-09-06 16:32:27 UTC

I didn't realise this had been entered in bugzilla until I'd already got this working....

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=fb713b3818b

That implements a solution: we copy the default error handlers from errordict (during initialization) into the (pre-existing) dictionary gserrordict. We then make gserrordict noaccess. It also makes the default error handler procedure executeonly.

When SAFER is in force, we ignore errordict, and only pull the handler from gserrordict.

As before, gserrordict also contains Ghostscript specific error(s) which we don't want in errordict (where they might confuse jobs that expect only the errors Adobe includes), and also that shouldn't ever be manipulated by jobs, anyway.

Thus Postscript jobs that expect to be able to manipulate errordict can still do so, but the changes will have no effect (in SAFER).

I'm going to leave this open: topic for discussion: should we provide a solution that allows only specific errors to be "locked". The example that springs to mind is embedded systems would probably want to ensure the VMerror is always handled correctly, but may want to allow other errors to be replaced.

Comment 2 Ray Johnston 2018-09-11 16:17:29 UTC

As far as I am concerned (and based on experience with GS embedded customers),
this can be closed.

Customers that want to control handling of errors will modify the handler
in errordict, and will most likely want that error handler to be used rather
than what some PS job may have stuck in errordict, but if they want to, their
error handler can load the handler from errordict and execute it.

Comment 3 Ray Johnston 2018-10-16 14:38:35 UTC

Now that Chris (et al.) have made the errordict a "dummy" version in SAFER
mode, and the gserrordict cannot be changed, this can be closed.