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
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.").
Can this be changed to only read input files from the current working directory, but not all the initialization files?
Filed upstream.
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.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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
*** Bug 639544 has been marked as a duplicate of this bug. ***
*** Bug 647599 has been marked as a duplicate of this bug. ***
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. :)
*** Bug 657697 has been marked as a duplicate of this bug. ***
pdfmerge-1.0.3 works for me
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
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
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
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
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.
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.
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.
Has this fix made it to EPEL-4, or only EPEL-5+ and Fedora-13+?
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
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.
(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.
(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.
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.
(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.
(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.
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
(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
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.