Bug 135675 - Problems with netpbm generated BMPs from 4 colour images
Problems with netpbm generated BMPs from 4 colour images
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: netpbm (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Jindrich Novy
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-14 07:29 EDT by Nils Philippsen
Modified: 2013-07-02 19:02 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-25 07:17:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
BMP file that exposes the problem. (320.07 KB, application/octet-stream)
2004-10-14 07:31 EDT, Nils Philippsen
no flags Details
Proposed patch (552 bytes, patch)
2004-10-14 07:36 EDT, Nils Philippsen
no flags Details | Diff
fixes the bmp colour-depth problem (808 bytes, patch)
2004-10-18 06:40 EDT, Jindrich Novy
no flags Details | Diff

  None (edit)
Description Nils Philippsen 2004-10-14 07:29:06 EDT
Description of problem:

---------- Forwarded message ----------
Date: Tue, 12 Oct 2004 22:23:48 +0100
From: Alan Cox <alan@lxorguk.ukuu.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:
Comment 1 Nils Philippsen 2004-10-14 07:31:13 EDT
Created attachment 105194 [details]
BMP file that exposes the problem.

Attached as application/octet-stream to not confuse browsers.
Comment 2 Nils Philippsen 2004-10-14 07:36:47 EDT
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).
Comment 3 Nils Philippsen 2004-10-14 07:58:00 EDT
As the crash/core dump is induced by g_assert_not_reached, this
doesn't seem to be a security problem anymore.
Comment 4 Alan Cox 2004-10-14 08:28:33 EDT
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.
Comment 5 Nils Philippsen 2004-10-14 12:03:16 EDT
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.
Comment 6 Nils Philippsen 2004-10-14 12:30:50 EDT
Reassigning this to netpbm.
Comment 7 Jindrich Novy 2004-10-18 05:03:36 EDT
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 ;-)
Comment 8 Nils Philippsen 2004-10-18 06:07:01 EDT
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?

Comment 9 Jindrich Novy 2004-10-18 06:40:21 EDT
Created attachment 105368 [details]
fixes the bmp colour-depth problem

Nils, this patch should tell ppmtobmp to behave less destructive to the gimp.
Comment 10 Jindrich Novy 2004-10-18 06:48:27 EDT
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 ;-)
Comment 11 Nils Philippsen 2004-10-18 07:25:01 EDT
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.
Comment 12 Jindrich Novy 2004-10-25 07:17:02 EDT
This has been fixed upstream since netpbm-10.21.

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