Bug 692602 - -dSAFER produces spurious /invalidfileaccess with "run" operator
Summary: -dSAFER produces spurious /invalidfileaccess with "run" operator
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Regression (show other bugs)
Version: master
Hardware: PC Linux
: P4 normal
Assignee: Chris Liddell (chrisl)
QA Contact: Bug traffic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-16 01:25 UTC by Jonathan Nieder
Modified: 2014-02-17 04:40 UTC (History)
3 users (show)

See Also:
Customer:
Word Size: ---


Attachments
gs.1: -dSAFER documentation updates, inspired by Use.htm (3.04 KB, patch)
2012-02-22 00:32 UTC, Jonathan Nieder
Details | Diff
fix-up to use of "jobs" and "scripts" terms (1.22 KB, patch)
2012-02-29 17:02 UTC, Jonathan Nieder
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Nieder 2011-10-16 01:25:25 UTC
Hi,

With ghostscript-9.01~545 (Dont't search for initialization files in the current directory first, 2010-07-07), the default for SEARCH_HERE_FIRST flipped from 1 to 0.  That was an excellent change, since it means that unfriendly people can no longer cause ghostscript to run arbitrary postscript code by putting their own gs_init.ps in /tmp, for example.

As a side effect, though, it broke use of relative paths with the "run" operator when -dSAFER is set. If I run:

 man -t ls >ls.ps
 echo "(ls.ps) run" | gs

then I get a rendering of the ls(1) manpage.  On the other hand, if I run

 man -t ls >ls.ps
 echo "(ls.ps) run" | gs -dSAFER

then I get

 Error: /invalidfileaccess in --run--
 Operand stack:
    (ls.ps)   (r)

Likewise when the "run" command is inside a postscript file.

So it seems that SEARCH_HERE_FIRST=0 is overshooting its mark, and applying not only to initialization files but to files run later using "run". Reproducible with ghostscript 9.04~dfsg-2 from Debian and with commit 2e92d2916a. Noticed because it was causing some existing postscript files to stop working. What do you think?
Comment 1 Marcos H. Woehrmann 2011-11-03 20:15:08 UTC
Assign to Marcos to reproduce.
Comment 2 ozone 2012-02-18 20:34:22 UTC
Independently discovered this behavior in 8.63: with DELAYSAFER, relative paths to the run operator fail; I have to render the path to include the current working directory (which is counterintuitive, at best).
Comment 3 ozone 2012-02-18 22:03:20 UTC
Apologies; this turns out to be certain configurations of my toolchain. What I really want is an explicit path setting for the run/file operators (thereby avoiding DELAYSAFER entirely), which I have described in RFE #692863.
Comment 4 Ray Johnston 2012-02-18 22:32:06 UTC
It is EXACTLY the intent of SAFER mode (whether -dSAFER or -dDELAYSAFER)
to inhibit a (potentially malicious) PS program from reading, executing, 
deleting, renaming, etc. file systems that are not explicitly identified
by the invocation.

Paths that are named on the command line using -I___ will be added to
the "PermitFileReading" set of paths, but the CWD (i.e. '.' is NOT there
with 9.01+ so if it is desired -P or -I. should be specified as an option.

This (as far as I can tell from the previous discussion) is working as
intended.
Comment 5 ozone 2012-02-18 23:19:16 UTC
Documentation states that -I / -P path logic is NOT used for the run / file operators, is this no longer correct?
Comment 6 Jonathan Nieder 2012-02-19 00:24:30 UTC
(In reply to comment #4)

> It is EXACTLY the intent of SAFER mode (whether -dSAFER or -dDELAYSAFER)
> to inhibit a (potentially malicious) PS program from reading, executing, 
> deleting, renaming, etc. file systems that are not explicitly identified
> by the invocation.

Ok.  Then this is a documentation bug and a missing feature.

1. The documentation bug: gs/man/gs.1 explains:

	-dSAFER

		Disables the "deletefile" and "renamefile" operators
		and the ability to open files in any mode other than
		read-only.  This strongly recommended for spoolers,
		conversion scripts or other sensitive environments
		where a badly written or malicious PostScript program
		code must be prevented from changing important files.

   which if I understand you correctly is just wrong.

2. The missing feature: it would be nice to be able to print, view, or convert existing but potentially malicious postscript files that include other postscript files. It is okay if this requires an extra switch and only allows reading files in some directories and with a .ps extension, to avoid attacks that use a remote postscript interpreter to read sensitive information.
Comment 7 Henry Stiles 2012-02-21 20:11:50 UTC
The man page should be consistent with Use.htm.
Comment 8 Jonathan Nieder 2012-02-22 00:32:05 UTC
Created attachment 8374 [details]
gs.1: -dSAFER documentation updates, inspired by Use.htm

Sounds like a good idea. How about this patch?
Comment 9 Chris Liddell (chrisl) 2012-02-29 16:49:45 UTC
Small revision: Postscript files are conventionally referred to as "jobs" rather than "scripts" - other than that, patched committed in:

http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=90e6a8


Thanks for the contribution!

Chris
Comment 10 Jonathan Nieder 2012-02-29 17:02:44 UTC
Created attachment 8392 [details]
fix-up to use of "jobs" and "scripts" terms

(In reply to comment #9)
> Small revision: Postscript files are conventionally referred to as "jobs"
> rather than "scripts"

Thanks for explaining.  In the paragraph about how to use NOSAFER, I
really did mean "scripts" as in shell scripts.  In the first sentence
("Restricts file operations the script can perform") you are right that
it is clearer to say "jobs".

Here's a fix-up, as a patch against ghostpdl master.
Comment 11 Chris Liddell (chrisl) 2012-03-01 07:46:04 UTC
Patch committed.
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=867fb8

Thanks again, and sorry for my confusion.
Comment 12 Jonathan Nieder 2012-03-01 14:55:56 UTC
(In reply to comment #11)

No problem.  Thanks for your thoughtfulness.

Ciao,
Jonathan