Bug 642427 - ghostscript-8.71-16.fc13.i686 breaks pdfmerge-1.0-4.fc12.noarch
Summary: ghostscript-8.71-16.fc13.i686 breaks pdfmerge-1.0-4.fc12.noarch
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: pdfmerge
Version: 13
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Dominic Hopf
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 639544 657697 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-12 21:19 UTC by Alex Bartl
Modified: 2012-01-31 17:51 UTC (History)
6 users (show)

Fixed In Version: pdfmerge-1.0.4-1.el4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-23 19:54:13 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Ghostscript 691736 None None None Never

Description Alex Bartl 2010-10-12 21:19:26 UTC
Converting PDFs in a local directora results in an error as follows:

[root@alx tmp]# pdfmerge A.pdf B.pdf result.PDF

Error: /invalidfileaccess in --run--
Operand stack:
   (./A.pdf)   (r)
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1878   1   3   %oparray_pop   1877   1   3   %oparray_pop   1861   1   3   %oparray_pop   1755   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   1878   1   4   %oparray_pop   --nostringval--
Dictionary stack:
   --dict:1154/1684(ro)(G)--   --dict:0/20(G)--   --dict:75/200(L)--   --dict:75/200(L)--
Current allocation mode is local
Last OS error: 2
Current file position is 316
GPL Ghostscript 8.71: Unrecoverable error, exit code 1

Comment 1 Tim Waugh 2010-10-25 15:51:40 UTC
The cause is that we use a different (more secure) build default in ghostscript now which is equivalent to the command line option "-P-".  To allow reading files from the current directory, pdfmerge should use the ps2pdf command line option "-P" (or "-I.").

Comment 2 Tomas Hoger 2010-10-26 10:38:03 UTC
Can this be changed to only read input files from the current working directory, but not all the initialization files?

Comment 3 Tim Waugh 2010-10-28 13:24:09 UTC
Filed upstream.

Comment 4 Tim Waugh 2010-10-28 15:35:14 UTC
Answer is: basically no, but if the PostScript part of pdfmerge were to be moved to live in a "safe" directory then I think things would work correctly; c.f. ps2epsi, which does something similar.

Comment 5 Fedora Admin XMLRPC Client 2010-12-09 22:38:41 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 6 Dominic Hopf 2010-12-09 23:29:07 UTC
I took the ownership of this package since Rahul orphaned it. Upstream seems pretty dead, thus im going to continue this work there too. I've created a project on github with the original sources at [1], I know there is still some things to do. Anyone interested to contribute is welcome. I'll take care of remaining bugs on the weekend. :)

[1] https://github.com/dmaphy/pdfmerge

Comment 7 Dominic Hopf 2010-12-09 23:46:15 UTC
*** Bug 639544 has been marked as a duplicate of this bug. ***

Comment 8 Dominic Hopf 2010-12-11 17:12:15 UTC
*** Bug 647599 has been marked as a duplicate of this bug. ***

Comment 9 Dominic Hopf 2010-12-11 17:33:48 UTC
There is a new version of this package available in Koji:

http://koji.fedoraproject.org/koji/packageinfo?packageID=6563

I'd appreciate if you could test and give feedback if that works for you. :)

Comment 10 Dominic Hopf 2010-12-11 17:36:15 UTC
*** Bug 657697 has been marked as a duplicate of this bug. ***

Comment 11 Sami Farin 2010-12-11 17:58:40 UTC
pdfmerge-1.0.3 works for me

Comment 12 Fedora Update System 2010-12-13 21:58:06 UTC
pdfmerge-1.0.3-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/pdfmerge-1.0.3-1.fc13

Comment 13 Fedora Update System 2010-12-13 21:58:24 UTC
pdfmerge-1.0.3-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/pdfmerge-1.0.3-1.fc14

Comment 14 Fedora Update System 2010-12-13 21:58:37 UTC
pdfmerge-1.0.3-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/pdfmerge-1.0.3-1.el5

Comment 15 Fedora Update System 2010-12-14 17:03:21 UTC
pdfmerge-1.0.3-1.el5 has been pushed to the Fedora EPEL 5 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update pdfmerge'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/pdfmerge-1.0.3-1.el5

Comment 16 Fedora Update System 2010-12-23 19:54:01 UTC
pdfmerge-1.0.3-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 17 Fedora Update System 2010-12-23 19:58:32 UTC
pdfmerge-1.0.3-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 18 Fedora Update System 2010-12-30 17:27:46 UTC
pdfmerge-1.0.3-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 19 Tomas Hoger 2012-01-04 13:02:53 UTC
Has this fix made it to EPEL-4, or only EPEL-5+ and Fedora-13+?

Comment 20 Dominic Hopf 2012-01-04 20:41:39 UTC
Hi Tomas,

as far as I remember I only updated the package for Fedora 13+ and EPEL-5+. I usually update packages from current distro release upwards when starting to maintain a package. I'm afraid I'm not having a RHEL4 based box around to test stuff also.

I can build a package anyway if you are willing to test it.


Regards,
Dominic

Comment 21 Tomas Hoger 2012-01-06 17:55:45 UTC
There's an upcoming RHEL-4 ghostscript update that disables searching of the current working directory by default.  I have confirmed that it breaks pdfmerge version in EPEL-4.  I have also tested it with EPEL-5 pdfmerge version (pdfmerge-1.0.4-1.el5) which works fine again.  Can you get the same version to EPEL-4?  I can quickly retest such package too and +1 in bodhi.  Given that this is noarch and not too long perl script, I do not expect it to behave differently form EPEL-5 version.

Few notes from the quick look at the pdfmerge 1.0.4:
- it's still unsafe to use in a directory writeable by other user than the one invoking it, as it works around the problem by adding . to search path again using -I.
- its usage message claims it now supports -I option, but that does not seem to be true
- ps2pdf is called with -I. -I.. .  Why is -I.. needed?  That should actually make it more unsafe than the old version with gs that does search CWD.  As it was safe before to run pdfmerge is a subdirectory of /tmp only accessible to the user running it.

Comment 22 Tomas Hoger 2012-01-06 18:54:34 UTC
(In reply to comment #21)
> - ps2pdf is called with -I. -I.. .  Why is -I.. needed?  That should actually
> make it more unsafe than the old version with gs that does search CWD.  As it
> was safe before to run pdfmerge is a subdirectory of /tmp only accessible to
> the user running it.

https://github.com/dmaphy/pdfmerge/issues/1 fix it seems.

Comment 23 Dominic Hopf 2012-01-06 21:26:35 UTC
(In reply to comment #21)
> There's an upcoming RHEL-4 ghostscript update that disables searching of the
> current working directory by default.  I have confirmed that it breaks pdfmerge
> version in EPEL-4.  I have also tested it with EPEL-5 pdfmerge version
> (pdfmerge-1.0.4-1.el5) which works fine again.  Can you get the same version to
> EPEL-4?  I can quickly retest such package too and +1 in bodhi.  Given that
> this is noarch and not too long perl script, I do not expect it to behave
> differently form EPEL-5 version.
Here is a scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3625826

> Few notes from the quick look at the pdfmerge 1.0.4:
> - it's still unsafe to use in a directory writeable by other user than the one
> invoking it, as it works around the problem by adding . to search path again
> using -I.
I can add a check to the code if the files to be merged all are owned by the same user. Would that be a considerable security fix from your point of view?

> - its usage message claims it now supports -I option, but that does not seem to
> be true
Removed the hint in the usage for now, seems it was inserted by accident with a patch back in December 2010..

> - ps2pdf is called with -I. -I.. .  Why is -I.. needed?  That should actually
> make it more unsafe than the old version with gs that does search CWD.  As it
> was safe before to run pdfmerge is a subdirectory of /tmp only accessible to
> the user running it.
Yep, an idea to fix the reported issue at GitHub, maybe also a bit more secure if I check for the owning user first.

Comment 24 Dominic Hopf 2012-01-06 21:34:41 UTC
For the record, this is the concerning bug where the misleading usage text was introduced: https://bugzilla.redhat.com/show_bug.cgi?id=657697. I guess it was just a confusing formulation.

Comment 25 Tomas Hoger 2012-01-08 13:49:00 UTC
(In reply to comment #23)
> I can add a check to the code if the files to be merged all are owned by the
> same user. Would that be a considerable security fix from your point of view?

Ownership of the input files is not a problem.  I'd guess it's actually expected that pdfmerge should be able to do something like:

  pdfmerge /usr/share/doc/whatever/*.pdf all.pdf

Ignoring for a bit that this does not work for other reasons, upstream commit 5fa52f77ec makes that worse by an extra ownership check.  I'd say the check is unneeded and the change is better reverted.

The real problem is that with -I. -I.. ghostscript searched . and .. when looking for its initialization and library files.  So when pdfmerge is run in /tmp, there may be a trojan horse postscript initialization file that is executed before gs switches to the "safer" mode.  A local attacker can use that to run arbitrary code as the victim user.

This demonstrates how -I.. makes things worse:

As attacker, create malicious gs initialization file in /tmp:

$ cat /tmp/gs_cidtt.ps 
(/home/victim/not.bashrc) (a) file
(/usr/bin/id
) writestring

As victim, create a subdir in /tmp where you want to merge PDFs:

$ mkdir /tmp/safe-dir

$ cp /usr/share/doc/foo/in1.pdf /usr/share/doc/bar/in2.pdf /tmp/safe-dir

$ cd /tmp/safe-dir

$ cat ~/not.bashrc 
ok content

$ pdfmerge in1.pdf in2.pdf out.pdf 
Successfully merged to out.pdf

$ cat ~/not.bashrc 
ok content
/usr/bin/id

Of course, similar can happen with just -I. if merging is done directly in /tmp.  That case probably has other issues, as attacker can do a symlink attack and clobber target files with contents of output or intermediate files.  That's a matter of expectations, whether pdfmerge is expected to be safe for use in such world writeable directories.  If so, there are few changes needed.

Comment 26 Tomas Hoger 2012-01-08 14:42:23 UTC
(In reply to comment #23)
> Here is a scratch build:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=3625826

Installs cleanly, test merge worked with both the latest released and upcoming EL4 ghostscript.

Comment 27 Fedora Update System 2012-01-12 22:55:56 UTC
pdfmerge-1.0.4-1.el4 has been submitted as an update for Fedora EPEL 4.
https://admin.fedoraproject.org/updates/pdfmerge-1.0.4-1.el4

Comment 28 Dominic Hopf 2012-01-12 22:58:36 UTC
(In reply to comment #26)
> (In reply to comment #23)
> > Here is a scratch build:
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=3625826
> 
> Installs cleanly, test merge worked with both the latest released and upcoming
> EL4 ghostscript.

I've did a build and requested an update for EL4:

https://admin.fedoraproject.org/updates/pdfmerge-1.0.4-1.el4

Comment 29 Fedora Update System 2012-01-31 17:51:49 UTC
pdfmerge-1.0.4-1.el4 has been pushed to the Fedora EPEL 4 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.