Description of problem: ---------- Forwarded message ---------- Date: Tue, 12 Oct 2004 22:23:48 +0100 From: Alan Cox <alan.org.uk> [...] Subject: [vendor-sec] BMP problems On the same subject here's a .bmp file that crashes gimp (gimp catches the plugin error and prints diagnostics). Ironically the file itself isnt hand crafted but a chance output from netpbm ... --------------------------------------- I've verified this in gimp-2.0.5-3. Although I think the chance that this bug has opened security holes is minute, because it runs against a g_assert_not_reached(), I've set severity to "security" and closed access (you never know...). We can always open it up later. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 105194 [details] BMP file that exposes the problem. Attached as application/octet-stream to not confuse browsers.
Created attachment 105195 [details] Proposed patch This patch checks for valid values of bpp upon entering ReadImage(). If bpp is invalid, it reports "Invalid number of bits per pixel." and returns -1 (which is how ReadImage() reports errors to the caller).
As the crash/core dump is induced by g_assert_not_reached, this doesn't seem to be a security problem anymore.
Cool. I've finished testing other apps and they all seem to correctly error it. Note that you can generate a file with this problem by feeding a 2 colour image to ppmtobmp so once gimp is fixed this bug wants reassigning to netpbm 8) Agree its not a security issue based on your analysis.
gimp-2.0.5-0.fc2.2 for FC2 and gimp-2.0.5-4 for Rawhide with the fixed BMP plugin are on the way.
Reassigning this to netpbm.
Nils, could you please modify the test for BMP bit depth to include 24 bps bitmaps? Please see snippet from ppmtobmp.c (netpbm-10.25) for supported BMP bit depths: ------snip------ if (cmdline_p->bppSpec) { if (cmdline_p->bpp != 1 && cmdline_p->bpp != 4 && cmdline_p->bpp != 8 && cmdline_p->bpp != 24) pm_error("Invalid -bpp value specified: %u. The only values valid\n" "in the BMP format are 1, 4, 8, and 24 bits per pixel", cmdline_p->bpp); } ------snip------ Alan, this looks like you have found ppmtobmp bug as it says only the bit depths above are supported when you specify -bpp=foo but it generates 2bps BMPs with no problem when fed by a 2bps ppm... Note that the image has actually 4 colours (2bps), so I changed the summary. (nice Mondrian-like art ;-)
Jindrich, I already updated the patch (see my brown paper bug FC2 update last week ;-). Note that BMP supports not only 1, 4, 8, 24 bpp but also 16 and 32 bpp (at least according to what GIMP people told me when I reported the error). Perhaps ppmtobmp should convert the bitdepth to the next larger valid one, e.g. 2bpp->4bpp?
Created attachment 105368 [details] fixes the bmp colour-depth problem Nils, this patch should tell ppmtobmp to behave less destructive to the gimp.
Nils, yes that's exactly what the patch does. But it has a slight disadvantage that 16bpp ppm is converted to 24bpp BMP and in case of 32bpp ppm some bad things could occur as ppmtobmp tries to calculate a histogram of the image and sometimes 4GB of memory is pretty hard to allocate ;-)
That's what I meant -- 16 and 32bpp are also valid, so ppmtobmp should just convert the data into 16 or 32bpp BMP files respectively (instead of trying to convert these). Notice that I suggested upward conversion which shouldn't involve histograms the size of Africa :-P.
This has been fixed upstream since netpbm-10.21.