Bug 1227243 (CVE-2015-0848) - CVE-2015-0848 libwmf: heap overflow when decoding BMP images
Summary: CVE-2015-0848 libwmf: heap overflow when decoding BMP images
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2015-0848
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=important,public=20150601,repo...
Depends On: 1227244 1227427 1227428 1227429 1227430 1227431
Blocks: 1227245
TreeView+ depends on / blocked
 
Reported: 2015-06-02 08:49 UTC by Martin Prpič
Modified: 2019-06-08 20:37 UTC (History)
3 users (show)

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.
Clone Of:
Environment:
Last Closed: 2015-10-21 09:31:07 UTC


Attachments (Terms of Use)
a fix (608 bytes, patch)
2015-06-02 10:42 UTC, Caolan McNamara
no flags Details | Diff
fix for follow up rle decoding check (3.18 KB, patch)
2015-06-03 11:25 UTC, Caolan McNamara
no flags Details | Diff
the patch from deb784205 to keep them all together here (1.77 KB, patch)
2015-06-23 12:55 UTC, Caolan McNamara
no flags Details | Diff
my new fix for deb784192 (416 bytes, patch)
2015-06-23 12:56 UTC, Caolan McNamara
no flags Details | Diff
Correction for missing line numbers in src/player/meta.h (642 bytes, patch)
2015-07-17 02:21 UTC, Jason Unovitch
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:1917 normal SHIPPED_LIVE Important: libwmf security update 2015-10-20 20:10:07 UTC

Description Martin Prpič 2015-06-02 08:49:00 UTC
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

Comment 1 Martin Prpič 2015-06-02 08:49:27 UTC
Created libwmf tracking bugs for this issue:

Affects: fedora-all [bug 1227244]

Comment 2 Caolan McNamara 2015-06-02 10:42:25 UTC
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

Comment 5 Stefan Cornelius 2015-06-02 18:29:24 UTC
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==

Comment 7 Caolan McNamara 2015-06-03 11:25:25 UTC
Created attachment 1034253 [details]
fix for follow up rle decoding check

Comment 9 Stefan Cornelius 2015-06-16 07:58:25 UTC
(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

Comment 10 Stefan Cornelius 2015-06-17 08:29:21 UTC
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

Comment 12 Stefan Cornelius 2015-06-17 14:30:42 UTC
(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

Comment 14 Caolan McNamara 2015-06-23 12:55:39 UTC
Created attachment 1042306 [details]
the patch from deb784205 to keep them all together here

Comment 15 Caolan McNamara 2015-06-23 12:56:18 UTC
Created attachment 1042307 [details]
my new fix for deb784192

Comment 17 Fedora Update System 2015-06-24 16:00:39 UTC
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.

Comment 19 Jason Unovitch 2015-07-17 02:21:56 UTC
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

Comment 20 Jason Unovitch 2015-07-23 00:57:36 UTC
Any update or comments on the incomplete CVE-2015-4696 fix caused by missing line numbers in the patch?

Comment 21 Jason Unovitch 2015-08-09 22:44:09 UTC
(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

Comment 22 Stefan Cornelius 2015-10-19 11:45:17 UTC
CVE-2015-4588 now has a separate bug entry: bug#1272993

Comment 23 errata-xmlrpc 2015-10-20 16:10:30 UTC
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


Note You need to log in before you can comment on or make changes to this bug.