Bugzilla Bug 62487

Bug at http://bugzilla.gnome.org/show_bug.cgi?id=151034
From http://securitytracker.com/id?1011104

imlib BMP Decoding Buffer Overflow May Let Remote Users Execute Arbitrary Code

SecurityTracker Alert ID:  1011104
SecurityTracker URL:  http://securitytracker.com/id?1011104
CVE Reference:  CAN-2004-0817   (Links to External Site)
Date:  Aug 31 2004
Impact:  Denial of service via network, Execution of arbitrary code via network, User access via network
Fix Available:  Yes   Exploit Included:  Yes   Vendor Confirmed:  Yes  

Version(s): 1.9.14

Description:  A vulnerability was reported in imlib in the processing of BMP images. A remote user can cause imlib to crash or potentially execute arbitrary code.

The vendor reported that a remote user can create a specially crafted BMP image file containing runlength-encoded images that, when decoded by the target user, will cause imblib to crash.

Marcus Meissner discovered this vulnerability.

A demonstration exploit image from Chris Evans is available at:
http://bugzilla.gnome.org/attachment.cgi?id=30933&action=view

Impact:  A remote user can create a BMP file that, when decoded by the target user, will cause imlib to crash. It may also be possible to cause arbitrary code to be executed. The specific impact depends on the application using imlib.

Solution:  A patch is available at:

http://bugzilla.gnome.org/attachment.cgi?id=30934&action=view
__________________
Note:
There was also a vulnerability in imlib2
http://securitytracker.com/id?1011105

This has been fixed by bumping the ebuild today:
*imlib2-1.1.2 (31 Aug 2004)

  31 Aug 2004; Mike Frysinger <vapier@gentoo.org> -files/1.1.0-gcc-3.4.patch,
  -imlib2-1.1.0.ebuild, -imlib2-1.1.1.ebuild, +imlib2-1.1.2.ebuild:
  Version bump + stable for security.

We've two affected packages : media-libs/imlib and media-libs/imlib2.

media-libs/imlib is still at unpatched 1.9.14 level, we need an ebuild bump.
media-libs/imlib2 is ready for GLSA with version 1.1.2.

No maintainer. vapier, you bumped imlib2, could you do the same for imlib ?

gnome maintains imlib-1.x

*bump*
Gnome team, please apply fix to imlib...

there's no metadata, gnome does not maintain this, it just happens to be
somewhere in our chain of (gnome1) deps & we're very short on time.

The patch looks fine to me, apply & test & go ahead afa the gnome team ic.

Created an attachment (id=39049) [edit]
Patch from meissner@suse.de 

Patch taken from http://bugzilla.gnome.org/attachment.cgi?id=30934&action=view
(Bug: http://bugzilla.gnome.org/show_bug.cgi?id=151034)

There is also a second patch available there by Dimitry V. Levin, but he
states:
"Here is a patch I'm going to use for updates.
While I'm not sure that result image will be correct, this patch addresses all
potential heap corruption problems found in loader_bmp() so far, and allows to
load as much bmp data as possible."

Created an attachment (id=39050) [edit]
simple patch to the ebuild to include the bmp patch

seems to apply and compile cleanly

Something seems wrong here.

I tried with xzgv ( which depends on imlib ) and tried the exploit, which gave
the correct effect ( xzgv took the big one ).  However, after applying the 
patch, re-emerging imlib, and even re-emerging xzgv, it still bites the big
one while loading the exploit file.

I did an strace to make sure, and sure enough it bites the big one shortly
after accessing imlib.  I think we should probably upstream this, and I'll
attach the relevant strace output for upstream to look at.

Created an attachment (id=39067) [edit]
imlib strace output

Reported upstream, resetting status whiteboard.

Version to use is imlib-1.9.14-r2

ppc sparc amd64: 

Mark stable

alpha hppa ia64 mips ppc64:

Mark stable for benifit of the GLSA

x86 was marked by me.

Test Case:

The problem was with imlib based programs crashing when opening an exploitable
BMP file.  This was the steps taken to test for this exploit:

1) A program that utilized imlib was established (xzgv)
2) I opened this bmp:

http://dev.gentoo.org/~chriswhite/example.bmp

   which crashed the program as expected.
3) Re-emerged imlib-1.9.14-r2, compiled fine
4) opened the example.bmp file again with xzgv and no crash occured.
5) Opened this bmp:

http://dev.gentoo.org/~chriswhite/Dexter3.bmp

and the image loaded fine.
6) Also tested on some .jpg's and .png's as well.

The only problem being that xzgv is only x86 marked.  The 2 options would be:

a) march xzgv on your arch and use that
b) use any other imlib based program you feel comfortable with (not imlib2
though).

Good luck and let us know of any conflicts that may occur.

sparc stable.

marked stable for ppc/hppa/amd64/ia64

Stable on alpha.

GLSA 200409-12
mips, ppc64 : mark stable to benefit from GLSA

Thanks,  stable on ppc64

Stable on mips.