Re: Might --enable-compile-inits make things more secure?

Chris Liddell <[email protected]> Wed, 12 Dec 2018 13:24:42 +0000
Newsgroups gmane.comp.printing.ghostscript.devel
Message-ID <[email protected]>
It's certainly not a stupid idea. It has come up before, quite a few
times. Unfortunately it rather falls apart with the realities of how
people use Ghostscript, and how they expect it to behave.

So, in terms of improving security: --enable-compile-inits builds all
the intiialisation, resource and font files into the binary, so there is
vastly reduced chance of a party being able to place malicious code into
those start-up/resource files. Still not infallible, though.

In terms of removing access to the "outer" file system, well, no.

Postscript can easily handled as a byte stream, but PDF is a random
access format, and whilst Ghotscript allows it to be piped into stdin,
all that happens (behind the scenes) is Ghostcript simply redirects that
stdin stream to a temporary file, and then interprets that temp file. So
still using the disk.

Also, for high resolution rendering, PDF/Postscript output, Ghostscript
uses temporary files - so still using the disk.

Most importantly, probably, would be fonts/CIDFonts. One the most
regular questions we get asked is how to get Ghostscript to render a
Postscript or PDF file "correctly" (or, at least, legibly) which doesn't
have all the non-standard fonts/CIDFonts embedded. For that, Ghostscript
needs to be able to read the font files from disk.

Also, most font formats involve interpreting Postscript in some form
(the exceptions being Truetype and CFF), also it's common for Postscript
to "poke around" in the internals of font dictionaries. Those two facts
preclude handling font data completely "internally", isolated from the
Postscript interpreter.

There is simply no way users will accept using only the base 35
Postscript fonts, and one CIDFont substitute

Fundamentally, there is also the fact the Postscript spec includes the
facility to read/write/interpret files that, whilst not universally
used, it also not *that* rare.


Regards,

Chris


On 12/12/2018 11:20, Johannes Meixner wrote:
> 
> Hello,
> 
> sorry in advance if this is a stupid idea
> (I really don't know enough about the internals)
> but out of curiosity I can't resist to ask nevertheless:
> 
> I am wondering if "configure --enable-compile-inits"
> might help to make Ghostscript with -dSAFER more secure.
> 
> https://ghostscript.com/doc/9.26/Make.htm#Precompiled_data
> reads that it "improves security" but there is no explanation
> which kind of improved security it results.
> 
> My vague understanding is that with -dSAFER it is not
> easily possible to limit file access only to stdin, stdout,
> and stderr because Ghostscript needs to access its own
> Resource files during runtime (e.g. a font that needs
> to be loaded on a later page) so that -dSAFER cannot disable
> general file access on the system disk at startup time.
> 
> If my vague understanding is right I am wondering if it helps
> to get Ghostscript's own Resource files separated from
> arbitrary other files on the system disk by using
> "configure --enable-compile-inits".
> 
> Perhaps with "configure --enable-compile-inits" it is possible
> to let -dSAFER disable file access on the "outer" system disk
> at startup time and only keep access to Ghostscript's own
> built-in %rom% file system.
> 
> If access on the "outer" system disk could be generally disabled
> with -dSAFER at startup time it should at least mitigate possible
> misuse of special Ghostscript internal operators.
> 
> 
> Kind Regards
> Johannes Meixner