Bug 1227243 (CVE-2015-0848)
| Summary: | CVE-2015-0848 libwmf: heap overflow when decoding BMP images | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Martin Prpič <mprpic> | ||||||||||||
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> | ||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | |||||||||||||
| Severity: | high | Docs Contact: | |||||||||||||
| Priority: | high | ||||||||||||||
| Version: | unspecified | CC: | caolanm, carnil, jason.unovitch | ||||||||||||
| Target Milestone: | --- | Keywords: | Security | ||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | All | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
| Doc Text: |
It was discovered that libwmf did not correctly process certain WMF (Windows Metafiles) containing BMP images. By tricking a victim into opening a specially crafted WMF file in an application using libwmf, a remote attacker could possibly use this flaw to execute arbitrary code with the privileges of the user running the application.
|
Story Points: | --- | ||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2015-10-21 09:31:07 UTC | Type: | --- | ||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||
| Documentation: | --- | CRM: | |||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
| Embargoed: | |||||||||||||||
| Bug Depends On: | 1227244, 1227427, 1227428, 1227429, 1227430, 1227431 | ||||||||||||||
| Bug Blocks: | 1227245 | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Martin Prpič
2015-06-02 08:49:00 UTC
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 |