Originally, Common Vulnerabilities and Exposures assigned an identifier CVE-2010-2055 to the following Ghostscript vulnerability: Ghostscript 8.71 and earlier reads initialization files from the current working directory, which allows local users to execute arbitrary PostScript commands via a Trojan horse file, related to improper support for the -P- option to the gs program. References: [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2055 [2] https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2055 -- later a CVE identifier of CVE-2010-4820 was assigned to the insecure gs initialization issue. References: [3] https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-4820 [4] https://bugzilla.redhat.com/show_bug.cgi?id=771853#c1 [5] http://bugs.ghostscript.com/show_bug.cgi?id=691339 -- Yet later (the actual reason of this bug) Ghostscript upstream applied the more secure (-P- and -dSAFER) options to all various scripts, as shipped within ghostscript package. This bug is solely dedicated to the following upstream patch: [6] http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=4574142
This issue affects the versions of the ghostscript package, as shipped with Red Hat Enterprise Linux 5 and 6. -- This issue did not affect the versions of the ghostscript package, as shipped with Fedora release of 16 and 17, as the current versions in these distributions already contain upstream patch [6].
Below is the status of this bug : => The original patch for that incident was the following, introduced in ghostscript-9.08 : - "starting_arg_file" should only apply once. http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=407cc61e => However, this has been reverted in ghostscript-9.16 by the following commit : - Bug 695711: Resolve issue with relative paths for FONTPATH http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=dbcb29d2 Reasoning for the revert was that it caused problems with, for example, the "-sFONTPATH=..." option when the path is relative rather than absolute.
Helloy Cedric, are you trying to say that the current ghostscript is again vulnerable?
I believe so : Recompiling ghostscript-9.20 : # gs --version 9.20 # strace -e open gs -P- /usr/share/ghostscript/*/lib/gslp.ps |& grep 'open("[^/]' open("ProcSet/CIDInit", O_RDONLY) = -1 ENOENT (No such file or directory) open("NimbusMonoPS-Regular", O_RDONLY) = -1 ENOENT (No such file or directory) open("NimbusMonoPS-Regular", O_RDONLY) = -1 ENOENT (No such file or directory) open("NimbusMonoPS-Regular", O_RDONLY) = -1 ENOENT (No such file or directory)
[cedric@fedora-devel ghostscript]$ cat NimbusMonoPS-Regular %!PS (test) run [cedric@fedora-devel ghostscript]$ cat test (myfile) (w) file (%pipe%echo 'hello' > myfile) (w) file [cedric@fedora-devel ghostscript]$ ls myfile ls: cannot access 'myfile': No such file or directory [cedric@fedora-devel ghostscript]$ gs -P- /usr/share/ghostscript/*/lib/gslp.ps GPL Ghostscript 9.20 (2016-09-26) Copyright (C) 2016 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Can't find (or can't open) font file /usr/share/ghostscript/9.20/Resource/Font/NimbusMonoPS-Regular. Loading NimbusMonoPS-Regular font from NimbusMonoPS-Regular... 4226108 2606407 3874224 2569723 1 done. Loading NimbusMonoPS-Regular font failed. Can't find (or can't open) font file /usr/share/ghostscript/9.20/Resource/Font/NimbusMonoPS-Regular. Loading NimbusMonoPS-Regular font from NimbusMonoPS-Regular... 4226108 2606783 3874224 2579040 1 done. Loading NimbusMonoPS-Regular font failed. Querying operating system for font files... Can't find (or can't open) font file /usr/share/ghostscript/9.20/Resource/Font/NimbusMonoPS-Regular. Loading NimbusMonoPS-Regular font from NimbusMonoPS-Regular... 4226108 2654442 6009252 4662062 1 done. Loading NimbusMonoPS-Regular font failed. Didn't find this font on the system! Unable to substitute for font. [...] GPL Ghostscript 9.20: Unrecoverable error, exit code 1 [cedric@fedora-devel ghostscript]$ cat myfile hello
Hello Cedric, I'm aware of the issues with fonts, but is that the security issue? I will be fixing this minor issue with fonts after RHEL7 devel phase ends. To be honest, I'm not sure how this fonts relates to the -dSAFER option issue (which has been addressed in the latest build in bodhi). https://bodhi.fedoraproject.org/updates/ghostscript-9.20-2.fc25 https://bodhi.fedoraproject.org/updates/ghostscript-9.20-2.fc24 https://bodhi.fedoraproject.org/updates/ghostscript-9.20-2.fc23
The problem is that option -P-, which should be used by scripts that will read untrusted content (e.g. gslj), is supposed to prevent gs from looking for libraries in the current directory. I believe that the effect of this flaw is pretty much similar to CVE-2010-2055.
OK, I will look into it, and I will try to discuss it with upstream on IRC. However, I can't give any ETA, I'm in the middle of something urgent ATM.
I am unable to reproduce issue outline in comment 31 ... it seems that it might have been fixed after v.9.20, however, despite several bisect attempts, I am currently unable to pinpoint a particular fix
(In reply to Cedric Buissart from comment #35) > I am unable to reproduce issue outline in comment 31 ... it seems that it > might have been fixed after v.9.20, however, despite several bisect > attempts, I am currently unable to pinpoint a particular fix I think you can't seem to find the fix via git-bisect, because the actual fix is a combination of several fixes. Were you testing the upstream's vanilla build, or some of the packages we have in Fedora?
I was testing with upstream only, building using options as close as Fedora as possible. Yes, I am afraid it's going to be a set of fixes.
(In reply to Cedric Buissart from comment #38) > I was testing with upstream only, building using options as close as Fedora > as possible. I think the fix is caused by these changes: * upstream uses the latest (URW)++ fonts * upstream has it own vanilla build without our downstream patches Previously, we were using a set of custom downstream patches (IMO) negatively affecting Ghostscript's functionality, often introducing downstream bugs. As part of this, we were also using outdated (URW)++ fonts and custom fonts paths. I have worked on bringing the Fedora's Ghostscript package as close as possible to upstream vanilla build. Some of the changes are already in F27, the rest of them will be part of F28. Here's the wiki change: https://fedoraproject.org/wiki/Changes/GhostscriptPackageUpdate28 I think the easiest way to confirm the issue is no longer present is comparing Ghostscript from F25, F27 and F28. There are quite significant changes between each "edition"... :)
Unable to reproduce on recent RHEL-7 versions of ghostscript.