GNOME Bugzilla – Bug 151034
buffer overflow in bmp handling
Last modified: 2012-02-24 15:30:18 UTC
view the attached BMP in a imlib 1 based viewer. see it crash.
Created attachment 30933 [details] crash.bmp
Created attachment 30934 [details] [review] imlib-1.9.14-fix.patch patch that fixes the problem.
Not a security issue. WONTFIX. Please use something written in this century.
Ok, actually, it could be bad.
Created attachment 31137 [details] [review] imlib-1.9.14-suse-alt-bound.patch 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.
Downstream we tried patch from comment #2 without luck. Pasting comment: Chris White 2004-09-06 09:47 PST ------- 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 31333 [details] imlib strace output
Created attachment 31335 [details] [review] imlib-1.9.14-suse-alt-bound.patch Proposed patch, take 2. Patching gdk_imlib/io-bmp.c is not sufficient, Imlib/load.c also requires same fix.
Patch from #8 works fine.
According to http://ftp.gnome.org/pub/GNOME/sources/imlib/ the last tarball release was on 24-Sep-2004. Same for the last code commit: http://git.gnome.org/browse/archive/imlib/log/ Hence this application has been unmaintained for quite a while and its maintainer will not work on it soon. Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development.