Bug 455867 - openoffice.org: crash on malformed PCX image (CESA-2008-006)
openoffice.org: crash on malformed PCX image (CESA-2008-006)
Status: CLOSED DUPLICATE of bug 458056
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
source=internet,public=20080714,repor...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-18 09:43 EDT by Tomas Hoger
Modified: 2008-08-27 14:01 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-27 14:01:24 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)
a patch (864 bytes, patch)
2008-07-18 09:54 EDT, Caolan McNamara
no flags Details | Diff
Test .odf file from CESA-2008-006 (9.78 KB, application/vnd.oasis.opendocument.text)
2008-07-18 10:09 EDT, Tomas Hoger
no flags Details
PCX file causing crash, extracted from pcx.odt in CESA-2008-006 (1.17 KB, application/octet-stream)
2008-07-18 10:10 EDT, Tomas Hoger
no flags Details
crash report (7.19 KB, text/plain)
2008-07-28 22:21 EDT, lihuang
no flags Details
another .pcx file (1.19 MB, application/octet-stream)
2008-07-28 22:54 EDT, lihuang
no flags Details
salbmp.cxx diff between 2.3.0 and 2.4.1 (2.68 KB, patch)
2008-08-06 06:03 EDT, Tomas Hoger
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 91818 None None None Never

  None (edit)
Description Tomas Hoger 2008-07-18 09:43:05 EDT
Chris Evans of the Google Security Team reports an Openoffice.org crash
triggered by crafted PCX image:

  http://scary.beasts.org/security/CESA-2008-006.html

According to Chris, the issue should no longer affect current upstream 2.4.1,
but may affect unspecified older versions.
Comment 1 Caolan McNamara 2008-07-18 09:54:16 EDT
Created attachment 312137 [details]
a patch

I had taken a look at this today, hence the patch, but do we have any evidence
that it is a security bug now that
http://www.openoffice.org/security/cves/CVE-2008-2152.html is applied ?
Comment 2 Tomas Hoger 2008-07-18 10:05:15 EDT
(In reply to comment #1)
> I had taken a look at this today, hence the patch, but do we have any evidence
> that it is a security bug now that
> http://www.openoffice.org/security/cves/CVE-2008-2152.html is applied ?

Not yet clear.  It crashes F-8 OOo, which should have this patch applied.  But
valgrind only reports out-of-bound read, so may not be a security sensitive
issue. Not sure if it can have any worse impact.  I'm happy to hear opinions of
those more familiar with the beast^W^Wopenoffice.org internals.

Test did no crash OOo 1.1.x.
Comment 4 Tomas Hoger 2008-07-18 10:09:55 EDT
Created attachment 312140 [details]
Test .odf file from CESA-2008-006
Comment 5 Tomas Hoger 2008-07-18 10:10:40 EDT
Created attachment 312141 [details]
PCX file causing crash, extracted from pcx.odt in CESA-2008-006
Comment 6 Caolan McNamara 2008-07-18 10:15:34 EDT
"Not yet clear.  It crashes F-8 OOo, which should have this patch applied.  But
valgrind only reports out-of-bound read, so may not be a security sensitive
issue. Not sure if it can have any worse impact.  I'm happy to hear opinions of
those more familiar with the beast^W^Wopenoffice.org internals."

I think I cc'ed you on the email about it earlier today ? I'll wait for a second
opinion from sj at OOo but my opinion is that (after the previous alloc fix in
place to avoid a situation where we could be fooled into allocating too little
memory for future reads) that it should just attempt to allocate a gigantic
image which will crap out and die (safely) in < 2.4 and get caught with a
bad_alloc handler in >= 2.4.
Comment 7 Tomas Hoger 2008-07-18 10:56:18 EDT
(In reply to comment #6)
> I think I cc'ed you on the email about it earlier today ?

Yes, thank you!  I wanted to make sure there is a single place where notes
regarding this issue can be added.

> (after the previous alloc fix in place to avoid a situation where we
> could be fooled into allocating too little memory for future reads) that
> it should just attempt to allocate a gigantic image which will crap out
> and die (safely) in < 2.4 and get caught with a bad_alloc handler in >= 2.4.

Yes, it seems quite likely that that's what happening here.
Comment 10 Tomas Hoger 2008-07-21 08:39:33 EDT
Upstream bug report for PCX parser issue with proposed Caolan's patch:

http://www.openoffice.org/issues/show_bug.cgi?id=91818
Comment 11 lihuang 2008-07-28 22:21:50 EDT
Created attachment 312838 [details]
crash report

Reproduce with openoffice.org-draw-2.3.0-6.7.el5.x86_64 on RGEK5.2 x86_64
Client
Comment 12 lihuang 2008-07-28 22:54:53 EDT
Created attachment 312840 [details]
another .pcx file

Tried with another .pcx file . this time OOo works well

# file Blue\ hills8.pcx 
Blue hills8.pcx: PCX ver. 3.0 image data bounding box [0, 0] - [799, 599], 3
planes each of 8-bit image, 300 x 300 dpi, RLE compressed
Comment 14 Tomas Hoger 2008-08-06 06:03:38 EDT
Created attachment 313545 [details]
salbmp.cxx diff between 2.3.0 and 2.4.1

This change adds try-catch for std::bad_alloc exception, which should prevent OpenOffice.org from "crashing" in X11SalBitmap::ImplCreateDI when memory allocation fails.

Related upstream bug report:
http://www.openoffice.org/issues/show_bug.cgi?id=82997
Comment 15 Tomas Hoger 2008-08-27 14:01:24 EDT
Chris' test image actually uncovered multiple issues:

1) PCX image parser did not verify input values read from the input file and accepted even nonsensical values.  Additional sanity checks were add upstream, as noted in the upstream bug report:

  http://www.openoffice.org/issues/show_bug.cgi?id=91818

2) Because of 1), OpenOffice.org attempted to allocate memory chunk with negative size.  That value was later converted via signed -> unsigned conversion to a large positive value.  When memory allocator was not able to allocate that large memory chunk, it raised std::bad_alloc exception.  This exception was not properly handled by the bitmap code, resulting in an unexpected OpenOffice.org termination.  This issue was fixed upstream prior to release of upstream version 2.4.1.  Related upstream bug report:

  http://www.openoffice.org/issues/show_bug.cgi?id=82997

3) Additionally, OpenOffice.org's custom memory allocator contained a numeric truncation error that affected 64bit builds that do use OpenOffice.org's memory allocator.  This issue could result in memory corruption triggered by crafted file (PCX image, in this case), possibly allowing code execution.  Related upstream bug report:

  http://www.openoffice.org/issues/show_bug.cgi?id=92217


Only issue 3) has security implications and is tracked via bug #458056 and was assigned CVE id CVE-2008-3282.

*** This bug has been marked as a duplicate of bug 458056 ***

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