Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 138433 - media-libs/libpng 1.2.12 released to address buffer overflow (CVE-2006-3334)
Summary: media-libs/libpng 1.2.12 released to address buffer overflow (CVE-2006-3334)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL: http://puzzle.dl.sourceforge.net/sour...
Whiteboard: A2(?) [glsa] jaervosz
Keywords:
Depends on: 138736
Blocks: 138672
  Show dependency tree
 
Reported: 2006-06-29 02:06 UTC by Sebastian
Modified: 2019-12-25 20:03 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian 2006-06-29 02:06:24 UTC
Hi there,

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?

Thanks
Sebastian
Comment 1 Wolf Giesen (RETIRED) gentoo-dev 2006-06-29 02:22:29 UTC
Confirmed that =1.2.10 definitely has too small a buffer there.
Comment 2 Sebastian 2006-06-29 02:29:06 UTC
"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.

:)
S.
Comment 3 Wolf Giesen (RETIRED) gentoo-dev 2006-06-29 04:00:24 UTC
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 ...
Comment 4 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-06-29 04:07:14 UTC
The affected piece of code is :

#if !defined(PNG_NO_STDIO) && !defined(_WIN32_WCE)
         char umsg[50];

         if (ret == Z_BUF_ERROR)
            sprintf(umsg,"Buffer error in compressed datastream in %s chunk",
                png_ptr->chunk_name);
         else if (ret == Z_DATA_ERROR)
            sprintf(umsg,"Data error in compressed datastream in %s chunk",
                png_ptr->chunk_name);
         else
            sprintf(umsg,"Incomplete compressed datastream in %s chunk",
                png_ptr->chunk_name);
         png_warning(png_ptr, umsg);
#else


chunk_name is a char[5], (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.
Comment 5 Wolf Giesen (RETIRED) gentoo-dev 2006-06-29 04:14:51 UTC
Actually, one byte may be enough, I remember exploits that needed one or two bytes only - you just need the 'right' ones.
Comment 6 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-06-29 04:30:15 UTC
> 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.
Comment 7 Wolf Giesen (RETIRED) gentoo-dev 2006-06-29 06:54:39 UTC
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. 
Comment 8 SpanKY gentoo-dev 2006-06-29 16:05:21 UTC
1.2.12 in portage
Comment 9 Tavis Ormandy (RETIRED) gentoo-dev 2006-06-29 16:13:23 UTC
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.
Comment 10 Daniel Black (RETIRED) gentoo-dev 2006-06-29 17:22:46 UTC
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-6.2.5.5  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
Comment 11 David Nadlinger 2006-06-30 01:02:55 UTC
(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-6.2.5.5  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

Note that the patch only fixes the bug in libpng. There is a bug in imagemagick too (fixed in =imagemagick-6.2.8.0), see bug 136452 for details. We will have to stable =imagemagick-6.2.8.0 too or patching =imagemagick-6.2.5.5 - stabling 6.2.8.0 seems to be certainly more sane to me.
Comment 12 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-06-30 09:13:27 UTC
Tavis do you think we should wait for a better patch or mark this one stable?
Comment 13 Tavis Ormandy (RETIRED) gentoo-dev 2006-06-30 14:16:57 UTC
The patch looks good to me, I think this we should push this to stable asap.
Comment 14 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-07-01 00:10:24 UTC
Arches please test and mark stable.
Comment 15 Fabian Groffen gentoo-dev 2006-07-01 01:09:33 UTC
ppc-macos stable
Comment 16 Lars Weiler (RETIRED) gentoo-dev 2006-07-01 02:31:20 UTC
Stable on ppc.
Comment 17 Simon Stelling (RETIRED) gentoo-dev 2006-07-01 02:51:22 UTC
amd64 stable
Comment 18 Markus Rothe (RETIRED) gentoo-dev 2006-07-01 03:05:20 UTC
stable on ppc64
Comment 19 Jesus de Santos Garcia 2006-07-01 05:22:24 UTC
compiles fine in x86 and works fine (tested with gqview)
Comment 20 Andrej Kacian (RETIRED) gentoo-dev 2006-07-01 07:04:31 UTC
x86 happy, thanks!
Comment 21 Thomas Cort (RETIRED) gentoo-dev 2006-07-01 11:01:31 UTC
alpha stable.
Comment 22 Gustavo Zacarias (RETIRED) gentoo-dev 2006-07-01 14:21:24 UTC
net-print/cups needs a DEP fix otherwise there's a nice up/downgrade loop.
Comment 23 Marcel Meckel 2006-07-02 03:55:22 UTC
Same for me - cups has a dependency on <libpng-1.2.10 which loops up/downgrading of libpng. please fix
Comment 24 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-07-02 07:36:09 UTC
Adding printing to CC to fix the dep problem.
Comment 25 michael@smith-li.com 2006-07-03 09:34:35 UTC
(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.
Comment 26 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-07-03 10:08:16 UTC
DEP issue on bug #136346 is now fixed, so we can proceed.
Comment 27 Gustavo Zacarias (RETIRED) gentoo-dev 2006-07-03 13:05:47 UTC
sparc happy, sparc stable.
Comment 28 René Nussbaumer (RETIRED) gentoo-dev 2006-07-04 04:44:55 UTC
allready stable on hppa
Comment 29 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-07-04 07:11:56 UTC
Hi,
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.
Comment 30 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-07-06 00:01:25 UTC
This issue is disputed by other vendors. Changing status to glsa? until we decide wether to issue a GLSA or not.
Comment 31 Wolf Giesen (RETIRED) gentoo-dev 2006-07-06 00:45:09 UTC
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. (?)
Comment 32 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-07-06 01:08:02 UTC
In which case it would be A3 or A4 (most likely the latter unless you can completely crash services with this).
Comment 33 Thierry Carrez (RETIRED) gentoo-dev 2006-07-06 09:41:12 UTC
I tend to vote yes.
Comment 34 Wolf Giesen (RETIRED) gentoo-dev 2006-07-06 10:36:30 UTC
My yes should be obvious.
Comment 35 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-07-08 05:32:59 UTC
[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
Comment 36 Thierry Carrez (RETIRED) gentoo-dev 2006-07-19 10:15:00 UTC
Thx everyone, this is in GLSA 200607-06
Comment 37 Peter Volkov (RETIRED) gentoo-dev 2008-03-06 09:33:11 UTC
Does not affect current (2008.0) release. Removing release.