Bug 455867

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 ?

(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.

Created attachment 312140 [details]
Test .odf file from CESA-2008-006

Created attachment 312141 [details]
PCX file causing crash, extracted from pcx.odt in CESA-2008-006

"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.

(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.

Upstream bug report for PCX parser issue with proposed Caolan's patch:

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

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

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

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

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 ***