seems there's a problem. "Really increased sprintf buffer from 50 to 52 chars in pngrutil.c to avoid buffer overflow." (from README). Could you please check and provide a GLSA?
Confirmed that =1.2.10 definitely has too small a buffer there.
"png_decompress_chunk() in pngrutil.c doesn't check the chunk_name entries in PNG pictures and copies them into a too small buffer. DoS can happen plus execution of malicious code." (translated from German) That's what http://www.heise.de/newsticker/meldung/74850 says.
Really cheesy patch :( Instead of sanitizing the buffer operation they really just added 2 bytes to the buffer. If somebody wrecks the code that reads chunk_name the hole is open again ...
The affected piece of code is :
#if !defined(PNG_NO_STDIO) && !defined(_WIN32_WCE)
if (ret == Z_BUF_ERROR)
sprintf(umsg,"Buffer error in compressed datastream in %s chunk",
else if (ret == Z_DATA_ERROR)
sprintf(umsg,"Data error in compressed datastream in %s chunk",
sprintf(umsg,"Incomplete compressed datastream in %s chunk",
chunk_name is a char, (IMHO including the final \0).
i'm nearly sure this is not exploitable for code injection.
And i think this is not exploitable for DoS, since the data is generally aligned on a 2^n bytes. The buffer is only 2 bytes too short (52/50, next power of 2 is 56 or 64).
However, this is still a bug, but not a security issue as for me. Assigning to Auditing then, unless you find a working exploit.
Actually, one byte may be enough, I remember exploits that needed one or two bytes only - you just need the 'right' ones.
> Actually, one byte may be enough, I remember exploits that needed one or two
> bytes only - you just need the 'right' ones.
not here : it's impossible to overwrite a calling address or so.
Futhermore, i really think that the overwritten data is not used by any other variable.
Now, I'm no way the auditing hero here, but I guess it would depend on the order of the local variables, right? But even if the buffer _was_ the first variable, you could at max. smash the caller base pointer. I see no way to reliably exploit this to any extent.
1.2.12 in portage
You would have to be pretty brave to brand that unexploitable on all the architectures, compilers, kernels, etc we ship. 2 bytes is certainly enough to do some damage, the base pointer, as Wolf mentioned, is probably a good target with some compilers.
Moving back to vulnerabilities.
stabiling libpng-1.2.12 will probably break:
graphicsmagick-1.1.7 bug 137498 (x86 and ppc stable)
x11-misc/xvidcap-1.1.3 bug 137042
and does break:
imagemagick-18.104.22.168 bug 136452 KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ~ppc-macos ppc64 sh sparc x86"
David has put a libpng patch to fix it here (bug 136452) https://bugs.gentoo.org/attachment.cgi?id=90440&action=view
(In reply to comment #10)
> stabiling libpng-1.2.12 will probably break:
> graphicsmagick-1.1.7 bug 137498 (x86 and ppc stable)
> x11-misc/xvidcap-1.1.3 bug 137042
> and does break:
> imagemagick-22.214.171.124 bug 136452 KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc
> ~ppc-macos ppc64 sh sparc x86"
> David has put a libpng patch to fix it here (bug 136452)
Note that the patch only fixes the bug in libpng. There is a bug in imagemagick too (fixed in =imagemagick-126.96.36.199), see bug 136452 for details. We will have to stable =imagemagick-188.8.131.52 too or patching =imagemagick-184.108.40.206 - stabling 220.127.116.11 seems to be certainly more sane to me.
Tavis do you think we should wait for a better patch or mark this one stable?
The patch looks good to me, I think this we should push this to stable asap.
Arches please test and mark stable.
Stable on ppc.
stable on ppc64
compiles fine in x86 and works fine (tested with gqview)
x86 happy, thanks!
net-print/cups needs a DEP fix otherwise there's a nice up/downgrade loop.
Same for me - cups has a dependency on <libpng-1.2.10 which loops up/downgrading of libpng. please fix
Adding printing to CC to fix the dep problem.
(In reply to comment #22)
> net-print/cups needs a DEP fix otherwise there's a nice up/downgrade loop.
* see bug 136346 -- working on the loop issue.
DEP issue on bug #136346 is now fixed, so we can proceed.
sparc happy, sparc stable.
allready stable on hppa
if we think it's exploitable for code injection, it's an A2. If not, it's an A3. In both cases, it deserves a GLSA. But i agree there is still a weak hazard to be exploitable.
This issue is disputed by other vendors. Changing status to glsa? until we decide wether to issue a GLSA or not.
Hm, why the hesitation? Even if it's not expoitable in code exec sense, it could still be used to DoS server apps, which would merit a GLSA anyway. (?)
In which case it would be A3 or A4 (most likely the latter unless you can completely crash services with this).
I tend to vote yes.
My yes should be obvious.
[14:06] <taviso> jaervosz: yeah, but they have control of compilers, cflags, etc and can examine all of the binaries in use, we cant, and cant rule out exploitability
Thx everyone, this is in GLSA 200607-06
Does not affect current (2008.0) release. Removing release.