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