Apache OpenOffice (AOO) Bugzilla – Issue 46388
OpenOffice DOC document Heap Overflow
Last modified: 2013-08-07 14:41:36 UTC
OpenOffice DOC document Heap Overflow [Security Advisory] Advisory:[AD_LAB-05001] OpenOffice DOC document Heap Overflow Class: Design Error DATE:30/3/2005 Vulnerable: <=OpenOffice OpenOffice 1.1.4 Unvulnerable: Unknow Vendor: www.openoffice.org I.DESCRIPTION: ------------- OpenOffice.org is an office productivity suite, including word processing, spreadsheets, presentations, drawings, data charting, formula editing, and file conversion facilities. The vulnerability is caused due to a error within the .Doc document header processing.This can be exploited to cause a heap-based buffer overflow. II.DETAILS: ---------- There is a vulnerability in StgCompObjStream::Load() function, When reading DOC document information of format,memory is allocated by DOC provide length. DOC provided a 32 bits integer,and will use the low 16 bits of this number to allocate memory, but when reading doc information,still use the 32 bits number as length,this maybe cause heap overflow, and when free happened ,will cause write pointer,maybe cause arbitrary code excute . BOOL StgCompObjStream::Load() { memset( &aClsId, 0, sizeof( ClsId ) ); nCbFormat = 0; aUserName.Erase(); if( GetError() != SVSTREAM_OK ) return FALSE; Seek( 8L ); INT32 nMarker = 0; *this >> nMarker; if( nMarker == -1L ) { *this >> aClsId; INT32 nLen1 = 0; *this >> nLen1; // we can control this 32 bits int sal_Char* p = new sal_Char[ (USHORT) nLen1 ]; //use low 16 bits value to allocate memory if( Read( p, nLen1 ) == (ULONG) nLen1 ) //still use 32 bits int as length,if failed, // will goto free step,maybe cause write pointer. { aUserName = String( p, gsl_getSystemTextEncoding() ); .... nCbFormat = ReadClipboardFormat( *this ); } else SetError( SVSTREAM_GENERALERROR ); delete [] p; //free step,heap overflow cause write pointer. } return BOOL( GetError() == SVSTREAM_OK ); } example: if we provide 0x10000018 to nLen1,will allocate 0x18 length memory, Read( p, nLen1 ) still use 0x10000018 as length,then, read will fail, but readed length is bigger than allocated memory,and overwrite the next chunk. when goto delete [] p;,write pointer happened. we had triggered this problem successful,and cause arbitrary code excute . StartOffice maybe affected too. did not test. III.CREDIT: ---------- AD-LAB discovery this vuln:) Vulnerability analysis and advisory by A1rsupp1y. Special thanks to xalan's discussion. Thank to Sam,icbm,liangbin and all Venustech AD-Lab guys:P. V.DISCLAIMS: ----------- The information in this bulletin is provided "AS IS" without warranty of any kind. In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages. Copyright 1996-2005 VENUSTECH. All Rights Reserved. Terms of use. VENUSTECH Security Lab VENUSTECH INFORMATION TECHNOLOGY CO.,LTD(http://www.venustech.com.cn) Security Trusted {Solution} Provider Service
Created attachment 24466 [details] test under linux with OOo.1.1.4 and 1.1.2
MRU->FLR: are the information here of any worth to you?
Set appropriate target.
set to NEW to move issue out of oooqa-queue considering also that milestone was set to OOolater
airsupply, can you provide info if this issue also exists with development builds of 2.0? thanks, Max
Max, this issue also exists with development builds of 2.0 too,i have tested OOo_1.9.87. thanks,airsupply
FLR: please have a look. thanks, Max, volunteer
flr: The overflow attack can be averted, by masking to higher bits out: if( Read( p, nLen1&0xFFFF ) == (ULONG) (nLen1&0xFFFF) ) //still use 32 bits int as length,if I don't think that this patch will affect functionality. Shall we try to put the patch in OOo2.0?
i think we should patch this bug faster ,for malicious attacker can send other people a malicious .doc document,and maybe cause arbitrary code excute. of course, we should alert OOo's user to update their software to defeat malicious attacker.
flr->mav: StgCompObjStream::Load is located in SOT.
The fix is integrated in fwkfinal8 cws.
MAV->QA: Please use the bugdoc of the internal bug 121097 for the testing.
next week,can i release this security advisory?
@mav: we have no build yet with fwkfinal8 cws integrated, also no official download link for it, latest is 2.0beta..
mav->mru: Please verify the issue. mav->airsupply: I can not decide whether the information should be published, so I add MBA to "CC list". mav->maxweber: The office version with the fix will be available after fwkfinal8 is integrated into the master. re-open issue and reassign to mru@openoffice.org
reassign to mru@openoffice.org
reset resolution to FIXED
Verified fix in CWS fwkfinal8.
*** Issue 47236 has been marked as a duplicate of this issue. ***
I think we also need a patch for OOo 1.1.4 source. Because OOo 2.0 still Not Yet final, and many people still using the OOo 1.XX for work. I hope the patch will be attached to this issue too, after pass the QA. Thanks
As announced on the releases list we have a respin of the OOo1.1.4 build and additionally a library patch is available for all users that already have 1.1.4.
I have been testing the new library under FC3 and 1.1.4 and the test document is not recognized and thus does not open. Is this the expected result?
The document attached to this issue is not a valid .doc document. So after the vulnerability is fixed the office should reject opening of the document.
Info to whom not follow the info at release list. http://download.openoffice.org/1.1.4/security_patch.html This patch is to be applied to the OOo in the installation directory. Not for people who had built OOo from themselves. CMIIW
*** Issue 46276 has been marked as a duplicate of this issue. ***
I have found an issue with the patch for this bug. I have several user accounts set up on my Windows 2000 machine. Each one can use the same OOo program files, but only after each one has been specially set-up according to some (not very user-friendly) instructions. As the administrator, I replaced the old version of sot645mi.dll with the new one (available via http://download.openoffice.org/1.1.4/security_patch.html). After doing so, OOo worked fine under the administrator account. But when I logged-in to a different (non-administrator) account, OOo would fail to load. The error message was: "The application failed to initialize properly (0xc0000022). Click on OK to terminate the application." So I returned to the administrator account, put the old version of sot645mi.dll back instead of the new one, went back to the non-administrator account, and tried OOo again. It worked fine. So the patch causes the problem. Perhaps it could be fixed by going through some process - like those 'not very user-friendly' instructions - for every user account. But I don't have time to investigate that now; I just thought I should get this reported ASAP. At the least, the instructions (at http://download.openoffice.org/1.1.4/security_patch.html) probably need updating.
mav->petef: Could you please check that the permissions that are set for the library file allow users to read and execute the library. Probably it can not be loaded for other users.
petef->mav: Yes you're right. That was the problem; only the administrator account had any permissions on sot645mi.dll. So I forced the file to inherit all permissions from its parent directory, and now the problem has gone. Thanks for your help. I will try to suggest to the right people that they add a reminder about this on the patch instructions webpage.
Checked fix in 680m97.