Bugzilla – Bug 617866
VUL-0: CVE-2010-1205: libpng overflows CVE-2010-1205
Last modified: 2022-07-25 09:58:52 UTC
http://libpng.org/pub/png/pngnews.html states it is fixing 2 new bugs. Can you check these?
Date: Mon, 28 Jun 2010 13:35:51 +0200 From: Jan Lieskovsky <jlieskov@redhat.com> Reply-To: oss-security <oss-security@lists.openwall.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090825) To: "Steven M. Christey" <coley@linus.mitre.org> Cc: oss-security <oss-security@lists.openwall.com> Hi Steve, vendors, libpng upstream has released latest v1.4.3 and v1.2.44 versions, addressing two security issues: [a], out-of-bounds write to memory -- this already got a CVE id of "CVE-2010-1205", [b], memory-leak bug, involving images with malformed sCAL chunks, which could lead to an application crash. References: [1] http://www.libpng.org/pub/png/libpng.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=608644 Steve, could you allocate a CVE id for the [b] issue? Thanks && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team
I have updated libpng12 and libpng14 -> fixed for Factory. Do we have a minimal patch or should be derived from libpng-1.2.44-1.2.43.diff.txt? Do we have any testcase?
Please use CVE-2010-2249 for issue [b]. I am not aware about any other fixes/testcases except what is public anyway.
I am about to make SWAMP for this issue. SInce AFAIR libpng has so many weird packagenames, can you enumerate which packages need updates, so I can give swamp the exact names.
(In reply to comment #4) > weird packagenames, ... There are six packages of libpng: libpng12-0 libpng12-devel libpng12-compat-devel libpng14-14 libpng14-devel libpng14-compat-devel In libpng12-0, libpng12-devel, libpng14-14 and libpng14-devel is versioned stuff and can be installed in parallel in opposite to libpng-1?-compat-devel packages, which contains things like png.h and therefore must conflict. Note, that this is true for 11.3 and Factory only. > ..., can you enumerate which packages need updates, I expect that *-devel packages will not change.
The SWAMPID for this issue is 34189. This issue was rated as important. Please submit fixed packages as soon as possible. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
(In reply to comment #3) > Please use CVE-2010-2249 for issue [b]. > > I am not aware about any other fixes/testcases except what is public anyway. There are any public testcase?
i have not seen any.. i queried the png team for reproducers here.
(In reply to comment #8) > i queried the png team for reproducers here. It would be very very good to have them, thanks!
no reply yet :(
http://code.google.com/p/chromium/issues/detail?id=45983
Created attachment 373779 [details] spark.png crashing png e.g. open in firefox
needinfo done
Date: Mon, 5 Jul 2010 08:41:17 -0700 From: John Bowler <jbowler@frontiernet.net> To: oss-security@lists.openwall.com, 'PNG/MNG implementation discussion list' <png-mng-implement@lists.sourceforge.net> Subject: [oss-security] RE: [png-mng-implement] [oss-security] CVE Request -- libpng v1.4.3 and v1.2.44 -- memory leak while processing PNG image with malformed sCAL chunks X-Mailer: Microsoft Office Outlook 12.0 From: Marcus Meissner [mailto:meissner@suse.de] >> > > [b], memory-leak bug, involving images with malformed sCAL chunks, >> > > which could lead to an application crash. >> oss-sec, png-mng-implement ... do you have testimages or a reproducer for the sCAL issue? > >As found on: >http://code.google.com/p/chromium/issues/detail?id=45983 > >The sample crashing PNG is: >http://www.ee.oulu.fi/~aki/spark.png That doesn't show issue [b] - the sCAL leak. The original demonstration was provided by a program to generate the test image, because the test image is somewhat large (20MByte with the default settings). +Unfortunately the original program didn't compile, but it's easy to fix (it used a piece of non-exported libpng data, but that data is just the string "sCAL".) I guess I can post the fixed version, but I'd prefer permission of the person to post it - Vegard Nossum. The "sample crashing PNG" was generated by radamsa using the 'surfy' fuzzer on the PNGSuite test images to generate broken images. I've subsequently run radamsa using all the fuzzers and more images without +finding more problems, but the more input images that are used the more likely problems will be detected (since there are more patterns for radamsa to find and tweak.) Radamsa is a Scheme program that, unfortunately, requires its own specific Scheme compiler "owl-lisp" (i.e. it won't compile against Scheme48 and its libraries.) However, there's a self-contained binary +distribution (it contains all the owl libraries required). More information is here: http://code.google.com/p/ouspg/wiki/Radamsa This includes how to download and compile the binary (the download is a decimal encoded Scheme/LISP heap). The source is somewhat bleeding-edge - I eventually found that I could build radamsa r260 with +owl-lisp r83, but that was a long long time ago - June 21. I also found that I still had to use a binary of owl-lisp to bootstrap it, but by then I was pretty much convinced that it was probably safe ;-) John Bowler <jbowler@acm.org>
Date: Mon, 5 Jul 2010 12:10:58 -0400 From: Glenn Randers-Pehrson <glennrp@gmail.com> To: PNG/MNG implementation discussion list <png-mng-implement@lists.sourceforge.net> Cc: oss-security@lists.openwall.com Subject: [oss-security] Re: [png-mng-implement] [oss-security] CVE Request -- libpng v1.4.3 and v1.2.44 -- memory leak while processing PNG image with malformed sCAL chunks I did not intend to reveal the "crashing PNG" before Firefox 3.5.7 had been released. Glenn
Thanks Marcus, I can reproduce the problem now.
I get the crash even if I have libpng 1.4.3 installed.
Follows a backtrace of the MozillaFirefox-3.6.4-3.2.x86_64 crash -- it is same for both libpng 1.4.2 and libpng 1.4.3 installed. Moreover, i don't see any reference to libpng, therefore it seems to me that it is not a testcase for CVE-2010-1205. True? #0 match_widget_class_recursive (list=<value optimized out>, length=<value optimized out>, path=<value optimized out>, path_reversed=<value optimized out>) at gtkrc.c:4792 #1 0x00007ffff13e3f02 in gtk_rc_styles_match (rc_styles=0x7fffe10176d0 = {...}, sets=0x7ffff6ddf5c0 = {...}, path_length=39, path=0x7fffe1bc3310 "GtkWindow.GtkAlignment.GtkHBox.GtkLabel", path_reversed= 0x7fffe1bc32e0 "lebaLktG.xoBHktG.tnemngilAktG.wodniWktG") at gtkrc.c:1872 #2 0x00007ffff13e4232 in IA__gtk_rc_get_style (widget=0x7fffe1b160e0) at gtkrc.c:1978 #3 0x00007ffff14b6fd8 in gtk_widget_reset_rc_style (widget=0x7fffe1b160e0) at gtkwidget.c:6500 #4 0x00007ffff13843e1 in gtk_label_get_link_colors (widget=0x7fffe1b160e0, link_color=0x7fffffff7fd8, visited_link_color=0x7fffffff7fe0) at gtklabel.c:2201 #5 0x00007ffff13880b9 in parse_uri_markup (label=0x7fffe1b160e0) at gtklabel.c:2233 #6 gtk_label_set_markup_internal (label=0x7fffe1b160e0) at gtklabel.c:2314 #7 gtk_label_recalculate (label=0x7fffe1b160e0) at gtklabel.c:1868 #8 0x00007ffff1389390 in IA__gtk_label_set_markup (label=0x7fffe1b160e0, str=<value optimized out>) at gtklabel.c:2422 #9 0x00007ffff146e964 in IA__gtk_tooltip_set_markup (tooltip=0x7fffe168c2e0, markup=0x0) at gtktooltip.c:223 #10 0x00007ffff146efc9 in gtk_tooltip_reset (widget=0x7fffffff8138, tooltip=0x7fffe168c2e0, x=0x7fffffff814c, y= 0x7fffffff8148) at gtktooltip.c:487 #11 gtk_tooltip_run_requery (widget=0x7fffffff8138, tooltip=0x7fffe168c2e0, x=0x7fffffff814c, y=0x7fffffff8148) at gtktooltip.c:823 #12 0x00007ffff146fa2f in _gtk_tooltip_handle_event (event=0x7fffe1033580) at gtktooltip.c:1363 #13 0x00007ffff13957a8 in IA__gtk_main_do_event (event=0x7fffe1033580) at gtkmain.c:1689 #14 0x00007ffff0de144c in gdk_event_dispatch (source=<value optimized out>, callback=<value optimized out>, user_data=<value optimized out>) at gdkevents-x11.c:2372 #15 0x00007ffff1d50a93 in g_main_dispatch (context=0x7ffff6d6e7a0) at gmain.c:1960 #16 IA__g_main_context_dispatch (context=0x7ffff6d6e7a0) at gmain.c:2513 #17 0x00007ffff1d51270 in g_main_context_iterate (context=0x7ffff6d6e7a0, block=1, dispatch=1, self=<value optimized out>) at gmain.c:2591 #18 0x00007ffff1d51510 in IA__g_main_context_iteration (context=0x7ffff6d6e7a0, may_block=1) at gmain.c:2654 #19 0x00007ffff5a345e3 in nsBaseAppShell::DoProcessNextNativeEvent (this=0x7fffe6f26b80, mayWait=<value optimized out>) at /usr/src/debug/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:155 #20 0x00007ffff5a346db in nsBaseAppShell::OnProcessNextEvent (this=0x7fffe6f26b80, thr=0x7ffff6d1f670, mayWait=1, recursionDepth=<value optimized out>) at /usr/src/debug/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:311 #21 0x00007ffff5b4e7c0 in nsThread::ProcessNextEvent (this=0x7ffff6d1f670, mayWait=1, result=0x7fffffff840c) at /usr/src/debug/mozilla/xpcom/threads/nsThread.cpp:508 #22 0x00007ffff5b23420 in NS_ProcessNextEvent_P (thread=<value optimized out>, mayWait=<value optimized out>) at nsThreadUtils.cpp:250 #23 0x00007ffff5aae58f in mozilla::ipc::MessagePump::Run (this=0x7fffe8f0b5c0, aDelegate=0x7fffe8f13360) at /usr/src/debug/mozilla/ipc/glue/MessagePump.cpp:142 #24 0x00007ffff5af6db4 in MessageLoop::Run (this=0x7fffe8f13360) at /usr/src/debug/mozilla/ipc/chromium/src/base/message_loop.cc:173 #25 0x00007ffff5a34425 in nsBaseAppShell::Run (this=0x7fffe6f26b80) at /usr/src/debug/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:174 #26 0x00007ffff591f172 in nsAppStartup::Run (this=0x7fffe6fce2c0) at /usr/src/debug/mozilla/toolkit/components/startup/src/nsAppStartup.cpp:183 #27 0x00007ffff52e32d5 in XRE_main (argc=<value optimized out>, argv=<value optimized out>, aAppData=<value optimized out>) at /usr/src/debug/mozilla/toolkit/xre/nsAppRunner.cpp:3483 #28 0x0000000000402858 in main (argc=2, argv=0x7fffffffe258) at /usr/src/debug/mozilla/xulrunner/stub/nsXULStub.cpp:583
(In reply to comment #18) > Follows a backtrace of the MozillaFirefox-3.6.4-3.2.x86_64 crash -- it is same > for both libpng 1.4.2 and libpng 1.4.3 installed. Moreover, i don't see any > reference to libpng, therefore it seems to me that it is not a testcase for > CVE-2010-1205. True? Not true: http://code.google.com/p/chromium/issues/detail?id=45983#c5 " From bugzilla #580451: this seems to be caused by libpng calling row_callback with a row_num outside of the image, which often causes an out of range write unless the caller checks whether the row is in range. " Nevertheless, that libpng 1.4.2 and libpng 1.4.3 behaves the same way is confusing for me.
my bad... firefox seems to use its own copy of libpng, I assumed it used system libpng. I am not sure I have a reproducing program currently.
Created attachment 376154 [details] Differences between 1.4.2 and 1.4.3 Here we have changes in files pngpread.c and pngrutil.c between said versions. Not sure so far which of them are relevant and really needed for fixing this bug.
Note that libpng 1.2.44 and 1.4.3 went into 11.3. I have derived a patch for libpng12-0 package from 11.2 from the said differences, see home:pgajdos:branches:openSUSE:11.2:Update:Test/libpng12-0 To be honest, I don't understand these differences fully and I didn't test it at all so far if this patch break something.
I have compared the patch with debian one and it seems very similar. I've tested it on 11.2 at it seems ok. Packages are submitted via subpac for sles9 and sle10-sp3 and onwards I created following submit requrests: ibs: sle11 #7876, sle11-sp1 #7877 obs: 11.1 #46368, 11.2 #46369 I will test libpng more early next week, but in the meantime the update process can continue I think. Sorry for the delay.
there's something wrong with the submit requests in the ibs. They complain about a conflict in the spec file. Could you check please?
(In reply to comment #25) > there's something wrong with the submit requests in the ibs. They complain > about a conflict in the spec file. Could you check please? Sure, no idea how it happened. Please try 7987, 7986.
(In reply to comment #26) > (In reply to comment #25) > > there's something wrong with the submit requests in the ibs. They complain > > about a conflict in the spec file. Could you check please? > > Sure, no idea how it happened. > Please try 7987, 7986. sorry, I cannot reproduce this bug using the testcase(spark.png) in firefox.
(In reply to comment #20) > my bad... > > firefox seems to use its own copy of libpng, I assumed it used system libpng. > > I am not sure I have a reproducing program currently. So, is there any reproducing program now?
> So, is there any reproducing program now? As far as I know, no.
Petr, we also need the fixes for moblin 2.0 and 2.1.
actually the moblin teams respionsibility. see rtacker bugs.
Update released for: libpng-devel, libpng12-0, libpng12-0-debuginfo, libpng12-0-debuginfo-32bit, libpng12-0-debuginfo-x86, libpng12-0-debugsource, libpng14-14, libpng3, libpng3-debuginfo Products: openSUSE 11.1 (debug, i586, ppc, ppc64, x86_64) openSUSE 11.2 (debug, i586, x86_64)
remove needinfo flag
Update released for: libpng-devel, libpng-devel-32bit, libpng12-0, libpng12-0-32bit, libpng12-0-debuginfo, libpng12-0-debuginfo-32bit, libpng12-0-debuginfo-64bit, libpng12-0-debuginfo-x86, libpng12-0-debugsource, libpng12-0-x86, libpng3 Products: SLE-DEBUGINFO 11-SP1 (i386, ia64, ppc64, s390x, x86_64) SLE-DESKTOP 11-SP1 (i386, x86_64) SLE-SDK 11-SP1 (i386, ia64, ppc64, s390x, x86_64) SLE-SERVER 11-SP1 (i386, ia64, ppc64, s390x, x86_64) SLES4VMWARE 11-SP1 (i386, x86_64)
Update released for: libpng-devel, libpng-devel-32bit, libpng12-0, libpng12-0-32bit, libpng12-0-debuginfo, libpng12-0-debuginfo-32bit, libpng12-0-debuginfo-64bit, libpng12-0-debuginfo-x86, libpng12-0-debugsource, libpng12-0-x86, libpng3 Products: SLE-DEBUGINFO 11 (i386, ia64, ppc64, s390x, x86_64) SLE-DESKTOP 11 (i386, x86_64) SLE-SDK 11 (i386, ia64, ppc64, s390x, x86_64) SLE-SERVER 11 (i386, ia64, ppc64, s390x, x86_64)
Update released for: libpng, libpng-32bit, libpng-64bit, libpng-debuginfo, libpng-devel, libpng-devel-32bit, libpng-devel-64bit, libpng-x86 Products: SLE-DESKTOP 10-SP3 (i386, x86_64) SLE-SAP-APL 10-SP3 (x86_64) SLE-SERVER 10-SP3 (i386, ia64, ppc, s390x, x86_64)
Update released for: libpng, libpng-devel Products: Novell-Linux-POS 9 (i386) Open-Enterprise-Server 9 (i386) SUSE-CORE 9 (i386, ia64, ppc, s390, s390x, x86_64)
all releaased, moblin still in qa
Update released for: libpng-devel, libpng12-0, libpng12-0-debuginfo, libpng12-0-debuginfo-32bit, libpng12-0-debuginfo-x86, libpng12-0-debugsource, libpng3 Products: SUSE-MOBLIN 2.1 (i386) SUSE-MOBLIN 2.1-DEBUG (i386)
Update released for: libpng-devel, libpng12-0, libpng12-0-debuginfo, libpng12-0-debuginfo-32bit, libpng12-0-debuginfo-x86, libpng12-0-debugsource, libpng3 Products: SUSE-MOBLIN 2.0 (i386) SUSE-MOBLIN 2.0-DEBUG (i386)
This is an autogenerated message for OBS integration: This bug (617866) was mentioned in https://build.opensuse.org/request/show/42216 Factory / libpng14 https://build.opensuse.org/request/show/42217 Factory / libpng12 https://build.opensuse.org/request/show/46368 11.1 / libpng12-0 https://build.opensuse.org/request/show/46369 11.2:Test / libpng12-0