Re: possible issue with ps2pdf (9.25) and transparency

At 12:56 17/09/2018 +0200, Johannes Meixner wrote:

OK, so reporting back on the discussions at our staff meeting. lets do a 
summary first then I'll tackle the inline points.

The current intention (subject to change during development) is that we 
will continue to harden Ghostscript in SAFER mode. There are several lines 
of development on this (some already completed), but one of them is to 
'undefine' as many PostScript operators and functions as possible. There is 
a limit to this, if we were to undefine everything that isn't standard 
PostScript then some features would simply stop working (eg PDF 
interpretation). So we don't know how far we can go, but you can definitely 
expect that more stuff will vanish.

All these lines of development will be against 'SAFER' being true. However, 
we recognise that this may be too coarse a granularity for some users. 
Therefore we will add some new switches, which will allow 'categories' of 
operations to be permitted.

Again this is 'to be defined' but at present we are considering 3 switches; 
-dUNSAFE_ERRORS, -dUNSAFE_POSTSCRIPT and -dUNSAFE_FILES, along with their 
opposites; SAFE_ERRORS, SAFE_POSTSCRIPT and SAFE_FILES. (names are subject 
to change, don't depend on these ones)

So if you select -dSAFER, every extension operator we can think of that 
won't break features will be undefined, file system access beyond specified 
directories will be disallowed, and the PostScript error handler will be 
ignored, using the internal one only.

You can then permit a category by selecting the appropriate 'UNSAFE' 
switch. Or you can run without SAFER and select which categories to disallow.


NOTE we anticipate making 'SAFER' the default for Ghostscript. We'e been 
saying for years we wanted to, now we intend to actually do it.

We do realise that some applications are going to be broken by this, 
hopefully they will be able to work around it.


>>In addition, some of the extension operators are required if the PDF 
>>interpreter is to work. The Ghostscript PDF interpreter is (largely) 
>>written in PostScript and in particular needs a group of operators such 
>>as runpdf, runpdfpagerange etc in order to operate. Also a number of 
>>these operators are used directly by our commercial customers so we can't 
>>simply deprecate them
>
>I assume those PDF interpreter extension operators are required
>while the PDF input pages are processed (and not e.g. only during
>Ghostscript initialization where they could be disabled afterwards)
>so that those extensions need to be available for arbitrary PDF
>input from untrusted origin that might misuse those extensions.

But its relatively easy to produce a PostScript file which pretends to open 
a PDF file, then abuses the operators. Its no better than having them 
available up front.

We have a plan for this and we hope the problem will go away long term, but 
it won't be immediate. (months to years to fully implement this)


>>Fundamentally I'm pretty happy with bundling the whole file system and 
>>non-standard operator usage together, if you want to do dangerous stuff,
>>then you can't use SAFER.
>
>But then one can no longer run Ghostscript in a strict PostScript compliant
>way which means "all standard PostScript is supported but nothing more".
>
>This is more a theoretical argument because I assume in practice
>99.99% of Ghostscript's users won't care because they never
>use Ghostscript directly but indirectly via other tools.
>
>Nevertheless personally I prefer in general to
>"Keep Separated Issues Separated" ( 'KSIS' ;-)
>cf. item 5 in RFC 1925 at
>https://tools.ietf.org/html/rfc1925

We definitely won't be restricting Ghostscript to 'just the list of 
standard operators', apart from anything else there are extensions (such as 
setcustomcolor) which aren't defined in the PLRM but are widely expected to 
be present. Also we suspect it will be impossible to remove all the 
extension operators form our own startup code.

However, in future, we expect that you can use -dSAFER -dUNSAFE_FILES 
-dUNSAFE_ERRORS, or more simply -dSAFE_POSTSCRIPT, to achieve something 
like this.



                     Ken