CVE-2012-4405 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-4405): Multiple integer underflows in the icmLut_allocate function in International Color Consortium (ICC) Format library (icclib), as used in Ghostscript 9.06 and Argyll Color Management System, allow remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a crafted (1) PostScript or (2) PDF file with embedded images, which triggers a heap-based buffer overflow. NOTE: this issue is also described as an array index error.
Are the current stable versions affected by this? (i.e. do they use the bundled icclib?)
(In reply to comment #1) > Are the current stable versions affected by this? (i.e. do they use the > bundled icclib?) Yes, see bug 206893
Created attachment 368598 [details] patch from debian This is what Ubuntu uses, source is acknowledged as RH. More later.
Okay more research would've been needed here (please screw my -r1 ebuild). Fedora removed the bundled lib already since gs 9.05: http://pkgs.fedoraproject.org/cgit/ghostscript.git/commit/?id=6d215360a2e3a6f683beca044836ad6feb56c540 As of ghostscript-gpl-9.07 it isn't even shipped within the upstream tarball anymore, it has been replaced by lcms{,2}. Upstream commit: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d8ca80d1cb480702c109414c46e381981c94ddcb BUT our current stable version is still 9.05-r1 which bundles the library so the bug is still valid. I've committed a new revision for 9.10 which just includes two upstream fixes for known segfault issues. I'd like to get ghostscript-gpl-9.10-r2 stabilized. As always there are a few open bugs but none are show stoppers.
Sounds good to me. Arches, please test and stabilize: =app-text/ghostscript-gpl-9.10-r2 Target arches: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
--- cups-filters-1.0.36-r1.ebuild 2014-01-16 19:06:50.099068746 +0100 +++ cups-filters-1.0.43-r1.ebuild 2014-01-05 22:54:10.000000000 +0100 [...] RDEPEND=" - <app-text/ghostscript-gpl-9.09 + >=app-text/ghostscript-gpl-9.09 Can we get some confirmation on stabilising both?
(In reply to Jeroen Roovers from comment #6) I see no problems with that. (The version dep is a protection against file collissions, but I see no real reasons to backport it, ...43 should be fine.) Arches, please test and stabilize with target "alpha amd64 arm hppa ia64 ppc ppc64 sparc x86" =app-text/ghostscript-gpl-9.10-r2 =net-print/cups-filters-1.0.43-r1 [You will get a block when you have foomatic-filters in your WORLD file. You'll need to deselect it and it will get unmerged then.]
(In reply to Andreas K. Hüttel from comment #7) > (In reply to Jeroen Roovers from comment #6) > > I see no problems with that. (The version dep is a protection against file > collissions, but I see no real reasons to backport it, ...43 should be fine.) > > Arches, please test and stabilize with target > "alpha amd64 arm hppa ia64 ppc ppc64 sparc x86" > > =app-text/ghostscript-gpl-9.10-r2 > =net-print/cups-filters-1.0.43-r1 > > [You will get a block when you have foomatic-filters in your WORLD file. > You'll need to deselect it and it will get unmerged then.] That would reversely pull in =net-print/cups-1.7.1 because of =net-print/cups-1.6.4's dependency on net-print/foomatic-filters
(In reply to Jeroen Roovers from comment #8) > > That would reversely pull in =net-print/cups-1.7.1 because of > =net-print/cups-1.6.4's dependency on net-print/foomatic-filters Should be fixed, I've changed that in cups-1.6.4 to read || ( >=net-print/cups-filters-1.0.43-r1[foomatic] net-print/foomatic-filters )
Just a note to avoid any confusion since I've just added -r3, the candidate for stabilization is still -r2 for now.
Stable for HPPA.
amd64 stable
x86 stable
alpha stable
ia64 stable
arm stable
ppc stable
ppc64 stable
sparc stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
(In reply to Agostino Sarubbo from comment #19) > Maintainer(s), please cleanup. Cleanup is done.
Arches and Maintainer(s), Thank you for your work. Added to new GLSA Request
This issue was resolved and addressed in GLSA 201412-17 at http://security.gentoo.org/glsa/glsa-201412-17.xml by GLSA coordinator Sean Amoss (ackle).