A heap buffer overflow flaw was found in the way the libwmf library processed WMF files containing BMP images. A specially crafted WMF file could cause an application using libwmf to crash or, possibly, execute arbitrary code. Original report: http://seclists.org/oss-sec/2015/q2/597
Created libwmf tracking bugs for this issue: Affects: fedora-all [bug 1227244]
Created attachment 1033697 [details] a fix seeing as DecodeImage assumes that one pixel is one byte then it would appear that the most straight-forward fix is to only call DecodeImage if that is the case
I believe that there are further problems. The RLE decoding doesn't seem to check that the "count" fits into the image. ==4960== Invalid write of size 1 ==4960== at 0x4E4E525: DecodeImage (bmp.h:924) ==4960== by 0x4E4E525: ReadBMPImage (bmp.h:1147) ==4960== by 0x4E4E525: wmf_ipa_bmp_read (bmp.h:477) ==4960== by 0x509C941: meta_dib_brush (meta.h:2187) ==4960== by 0x509C941: WmfPlayMetaFile (player.c:922) ==4960== by 0x50A06F9: wmf_play (player.c:323) ==4960== by 0x40130F: wmf2svg_draw (wmf2svg.c:208) ==4960== by 0x4019A6: wmf2svg_file (wmf2svg.c:439) ==4960== by 0x400FCE: main (wmf2svg.c:458) ==4960== Address 0x7b26810 is 0 bytes after a block of size 32 alloc'd ==4960== at 0x4C28C0F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==4960== by 0x50900A7: wmf_malloc (api.c:482) ==4960== by 0x4E4DD4E: ReadBMPImage (bmp.h:1131) ==4960== by 0x4E4DD4E: wmf_ipa_bmp_read (bmp.h:477) ==4960== by 0x509C941: meta_dib_brush (meta.h:2187) ==4960== by 0x509C941: WmfPlayMetaFile (player.c:922) ==4960== by 0x50A06F9: wmf_play (player.c:323) ==4960== by 0x40130F: wmf2svg_draw (wmf2svg.c:208) ==4960== by 0x4019A6: wmf2svg_file (wmf2svg.c:439) ==4960== by 0x400FCE: main (wmf2svg.c:458) ==4960== And ==5176== Invalid write of size 1 ==5176== at 0x4E4E225: DecodeImage (bmp.h:888) ==5176== by 0x4E4E225: ReadBMPImage (bmp.h:1147) ==5176== by 0x4E4E225: wmf_ipa_bmp_read (bmp.h:477) ==5176== by 0x509C941: meta_dib_brush (meta.h:2187) ==5176== by 0x509C941: WmfPlayMetaFile (player.c:922) ==5176== by 0x50A06F9: wmf_play (player.c:323) ==5176== by 0x40130F: wmf2svg_draw (wmf2svg.c:208) ==5176== by 0x4019A6: wmf2svg_file (wmf2svg.c:439) ==5176== by 0x400FCE: main (wmf2svg.c:458) ==5176== Address 0x7b267f8 is 0 bytes after a block of size 8 alloc'd ==5176== at 0x4C28C0F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5176== by 0x50900A7: wmf_malloc (api.c:482) ==5176== by 0x4E4DD4E: ReadBMPImage (bmp.h:1131) ==5176== by 0x4E4DD4E: wmf_ipa_bmp_read (bmp.h:477) ==5176== by 0x509C941: meta_dib_brush (meta.h:2187) ==5176== by 0x509C941: WmfPlayMetaFile (player.c:922) ==5176== by 0x50A06F9: wmf_play (player.c:323) ==5176== by 0x40130F: wmf2svg_draw (wmf2svg.c:208) ==5176== by 0x4019A6: wmf2svg_file (wmf2svg.c:439) ==5176== by 0x400FCE: main (wmf2svg.c:458) ==5176==
Created attachment 1034253 [details] fix for follow up rle decoding check
(In reply to Stefan Cornelius from comment #5) > I believe that there are further problems. The RLE decoding doesn't seem to > check that the "count" fits into the image. This is CVE-2015-4588 via http://www.openwall.com/lists/oss-security/2015/06/16/4
Fernando Muñoz just pointed out that there are two invalid read/heap use after free issues. http://www.openwall.com/lists/oss-security/2015/06/17/3 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784192 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784205
(In reply to Stefan Cornelius from comment #10) > Fernando Muñoz just pointed out that there are two invalid read/heap use > after free issues. > http://www.openwall.com/lists/oss-security/2015/06/17/3 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784192 Mhhh, hard to say how critical this one really is. I guess it's best to just assume the worst case and fix it. meta_dc_restore() frees polyrect.TL and polyrect.BR but then ends up calling FR->region_clip() on it. Fix should be relatively straight-forward, I think. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784205 This one seems harmless to me. Valgrind did not catch the OOB read on 64bit; it's visible on 32bit, though. >while (objects[i].type && (i < NUM_OBJECTS (API))) i++; should really be >while ((i < NUM_OBJECTS (API)) && objects[i].type) i++; so that we don't access objects[i] if i is already OOB. There are multiple similar checks throughout the code, e.g. see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784205;att=1;filename=fuzz1.patch;msg=5
Created attachment 1042306 [details] the patch from deb784205 to keep them all together here
Created attachment 1042307 [details] my new fix for deb784192
libwmf-0.2.8.4-43.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 1052931 [details] Correction for missing line numbers in src/player/meta.h Caolan, The deb784192 fixed in comment 15 is missing any line numbers for the first hunk. --- libwmf-0.2.8.4/src/player/meta.h +++ libwmf-0.2.8.4/src/player/meta.h + if (FR->region_clip) FR->region_clip (API,&polyrect); + wmf_free (API,polyrect.TL); wmf_free (API,polyrect.BR); } Based off the context, the only place this applies would be line number 2588. Patch attached that reflects that. Does it look correct to you? Jason
Any update or comments on the incomplete CVE-2015-4696 fix caused by missing line numbers in the patch?
(In reply to Fedora Update System from comment #17) > libwmf-0.2.8.4-43.fc21 has been pushed to the Fedora 21 stable repository. > If problems still persist, please make note of it in this bug report. At a minimum, the fc21, fc22, and fc23 SRPMs still have the CVE-2015-4696 patch with missing line numbers on the first patch hunk. I checked the three SRPMs below. http://dl.fedoraproject.org/pub/fedora/linux/updates/21/SRPMS/l/libwmf-0.2.8.4-45.fc21.src.rpm http://dl.fedoraproject.org/pub/fedora/linux/updates/22/SRPMS/l/libwmf-0.2.8.4-45.fc22.src.rpm https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/source/SRPMS/l/libwmf-0.2.8.4-45.fc23.src.rpm
CVE-2015-4588 now has a separate bug entry: bug#1272993
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 6 Via RHSA-2015:1917 https://rhn.redhat.com/errata/RHSA-2015-1917.html