| Summary: | media-libs/imlib-1.9.14: BMP Decoding Buffer Overflow May Let Remote Users Execute Arbitrary Code | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Matthias Geerdsen (RETIRED) <vorlon> | ||||||||
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||||||
| Status: | RESOLVED FIXED | ||||||||||
| Severity: | major | CC: | gnome | ||||||||
| Priority: | High | ||||||||||
| Version: | unspecified | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| URL: | http://securitytracker.com/id?1011104 | ||||||||||
| Whiteboard: | A2 [glsa] | ||||||||||
| Package list: | Runtime testing required: | --- | |||||||||
| Attachments: |
|
||||||||||
|
Description
Matthias Geerdsen (RETIRED)
2004-09-01 03:01:38 UTC
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 attachment 39049 [details, diff] 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 attachment 39050 [details, diff]
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 attachment 39067 [details]
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. |
