Re: [bug-gv] Re: Security issues

[Bernhard R. Link]

* address@hidden <address@hidden> [100530 12:02]:
> > 3) Scaning pdf2dsc using pdf2dsc.ps
> > Related to 2, there is an other issue: The scanning is done by
> > pdf2dsc.ps, which is specified on the command line. As far as I can
> > tell, gs looks for files specified as command line arguments in the
> > current directory first, even with -P-. So even with -P- this could
> > be exploited by adding a pdf2dsc.ps in the current directory (think
> > /tmp). I do not know how to fix this best. Perhaps shipping a postscript
> > file with gv (thus one has an absolute path) that reads and executes
> > the one from the system path?
> 
> Is not this a gs issue (as distinct from gv)? My Debian pdf2dsc bits
> come from package ghostscript.

There might be issues with the pdf2dsc script, but gv is not using it,
gv is giving gs the pdf2dsc.ps file without path. This is an issue of
gv.

> Is not it sufficient to modify the /usr/bin/pdf2dsc script to contain an
> absolute path for pdf2dsc.ps i.e. to include
>
> exec "$GS_EXECUTABLE" -q -P- -dNODISPLAY -dSAFER -dDELAYSAFER\
>     -sPDFname="$pdffile" -sDSCname="$dscfile"\
>     /usr/share/ghostscript/8.62/lib/pdf2dsc.ps -c quit
>
> (or somesuch)?

If you give an explicit path to the pdf2dsc.ps then it makes no sense to
have "$GS_EXECUTEABLE" configurable. Even worse, you need to get that
path at runtime, otherwise gv will not longer work when you upgrade
ghostscript. Thus I think it might be better to have some
GV_LIBDIR/pdf2dsc.ps which simply contains something like

| % find pdf2dsc.ps installed and execute that.
| % This way the correct one for the running gs is used...
| (pdf2dsc.ps) runlibfile

Which should always get the pdf2dsc.ps that belong to the ghostscript
interpreter used. Though someone with working -P- should test that.