Bug 135675 - Problems with netpbm generated BMPs from 4 colour images
Summary: Problems with netpbm generated BMPs from 4 colour images
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: netpbm (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
high
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact: Ben Levenson
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-14 11:29 UTC by Nils Philippsen
Modified: 2013-07-02 23:02 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-25 11:17:02 UTC
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 11:31 UTC, Nils Philippsen
no flags Details
Proposed patch (552 bytes, patch)
2004-10-14 11:36 UTC, Nils Philippsen
no flags Details | Diff
fixes the bmp colour-depth problem (808 bytes, patch)
2004-10-18 10:40 UTC, Jindrich Novy
no flags Details | Diff

Description Nils Philippsen 2004-10-14 11:29:06 UTC
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 11:31:13 UTC
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 11:36:47 UTC
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 11:58:00 UTC
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 12:28:33 UTC
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 16:03:16 UTC
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 16:30:50 UTC
Reassigning this to netpbm.

Comment 7 Jindrich Novy 2004-10-18 09:03:36 UTC
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 10:07:01 UTC
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 10:40:21 UTC
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 10:48:27 UTC
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 11:25:01 UTC
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 11:17:02 UTC
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.