Integer overflow in the ReadImage function in
plug-ins/file-bmp/bmp-read.c in GIMP 2.6.7 might allow remote
attackers to execute arbitrary code via a BMP file with crafted width
and height values that trigger a heap-based buffer overflow.
Just sidenote hello from QA team.
Hanno is currently not entirely active in gimp development (last commit at 18 March).
We would recommend that someone who care backport the patch and stable the 2.9.7, then dropping of all older versions should be proceeded.
I've added 2.6.7-r1 with the patch from gimp git. I found no sample bmp in the security reports so I couldn't test it but it should be fine.
CC-ing archs. ppc64 also needs to stabilize babl and gegl. mips and x86-fbsd have no keyword on 2.6.7-r1 yet, cc-ing them also. If you can't re-keyword 2.6.7-r1, your arch will be without gimp soon.
Stable for HPPA.
Secunia discovered more heap-based buffer overflows when parsing .PSD files (CVE-2009-3909):
The following two commits fix the PSD issue:
According to upstream, a new 2.6 release is planned "in the next few days"
The patch linked in $URL is not sufficient. These are also required to fix the BMP issue:
Maybe we should wait for an official release.
*** Bug 287478 has been marked as a duplicate of this bug. ***
Integer overflow in the read_channel_data function in
plug-ins/file-psd/psd-load.c in GIMP 2.6.7 might allow remote
attackers to execute arbitrary code via a crafted PSD file that
triggers a heap-based buffer overflow.
Citing myself from comment #2:
ppc64 also needs to stabilize babl and gegl. mips and x86-fbsd have no keyword on 2.6.8 yet, cc-ing them also. If you can't re-keyword 2.6.8, your arch will be without gimp soon.
alpha/ia64/sparc stable, and bsd/mips doesn't do stable keywords.
Marked ppc stable.
bsd/mips don't have keywords at all on 2.6.8, so they'll loose gimp-support altogether. I wrote them a mail, though I'll remove all old ebuilds within a few days.
Else I think we're ready for glsa. I think it deserves a GLSA, security, what do you think?
No vote needed. GLSA request filed according to policy (http://www.gentoo.org/security/en/vulnerability-policy.xml).
This issue was resolved and addressed in
GLSA 201209-23 at http://security.gentoo.org/glsa/glsa-201209-23.xml
by GLSA coordinator Sean Amoss (ackle).