Issue 46388

Summary: OpenOffice DOC document Heap Overflow
Product: Writer Reporter: airsupply <airsupply>
Component: codeAssignee: michael.ruess
Status: CLOSED FIXED QA Contact: issues@sw <issues>
Severity: Trivial    
Priority: P3 CC: flibby05, issues, Mathias_Bauer, mikhail.voytenko, petef109, pplwong, stefan.baltzer, stx123, utomo.prawiro
Version: OOo 1.1.4Keywords: oooqa
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
test under linux with OOo.1.1.4 and 1.1.2 none

Description airsupply 2005-03-31 12:12:49 UTC
OpenOffice DOC document Heap Overflow
[Security Advisory]

Advisory:[AD_LAB-05001] OpenOffice DOC document Heap Overflow
Class: Design Error

    <=OpenOffice OpenOffice 1.1.4

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

	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;
	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
							// will goto free step,maybe cause write pointer.
			aUserName = String( p, gsl_getSystemTextEncoding() );
			nCbFormat = ReadClipboardFormat( *this );
        delete [] p; //free step,heap overflow cause write pointer.
	return BOOL( GetError() == SVSTREAM_OK );
	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.

    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.


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 

Trusted {Solution} Provider
Comment 1 airsupply 2005-03-31 12:21:04 UTC
Created attachment 24466 [details]
test under linux with OOo.1.1.4 and 1.1.2
Comment 2 michael.ruess 2005-04-01 09:38:09 UTC
MRU->FLR: are the information here of any worth to you?
Comment 3 michael.ruess 2005-04-01 09:38:38 UTC
Set appropriate target.
Comment 4 flibby05 2005-04-01 17:25:10 UTC
set to NEW to move issue out of oooqa-queue considering also that milestone was
set to OOolater
Comment 5 flibby05 2005-04-01 17:26:23 UTC
can you provide info if this issue also exists with development builds of 2.0?
thanks, Max
Comment 6 airsupply 2005-04-02 04:08:51 UTC
this issue also exists with development builds of 2.0 too,i have tested OOo_1.9.87.
Comment 7 flibby05 2005-04-02 06:42:34 UTC
FLR: please have a look. thanks, Max, volunteer
Comment 8 flr 2005-04-04 09:37:40 UTC
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?
Comment 9 airsupply 2005-04-05 04:26:07 UTC
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
Comment 10 flr 2005-04-05 09:23:39 UTC
flr->mav: StgCompObjStream::Load is located in SOT.
Comment 11 mikhail.voytenko 2005-04-05 13:02:52 UTC
The fix is integrated in fwkfinal8 cws.
Comment 12 mikhail.voytenko 2005-04-05 14:38:21 UTC
MAV->QA: Please use the bugdoc of the internal bug 121097 for the testing.
Comment 13 airsupply 2005-04-07 03:50:48 UTC
next week,can  i  release this security advisory?
Comment 14 flibby05 2005-04-07 08:52:57 UTC
@mav: we have no build yet with fwkfinal8 cws integrated, also no official
download link for it, latest is 2.0beta..
Comment 15 mikhail.voytenko 2005-04-07 14:25:15 UTC
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
Comment 16 mikhail.voytenko 2005-04-07 14:25:21 UTC
reassign to
Comment 17 mikhail.voytenko 2005-04-07 14:25:28 UTC
reset resolution to FIXED
Comment 18 michael.ruess 2005-04-12 14:01:59 UTC
Verified fix in CWS fwkfinal8.
Comment 19 caolanm 2005-04-12 16:03:19 UTC
*** Issue 47236 has been marked as a duplicate of this issue. ***
Comment 20 utomo99 2005-04-14 07:11:06 UTC
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. 
Comment 21 Mathias_Bauer 2005-04-14 08:53:18 UTC
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.
Comment 22 grsingleton 2005-04-14 15:45:36 UTC
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?
Comment 23 mikhail.voytenko 2005-04-15 10:04:51 UTC
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.
Comment 24 utomo99 2005-04-16 03:47:56 UTC
Info to whom not follow the info at release list.

This patch is to be applied to the OOo in the installation directory. Not for 
people who had built OOo from themselves. CMIIW
Comment 25 flibby05 2005-04-21 14:39:24 UTC
*** Issue 46276 has been marked as a duplicate of this issue. ***
Comment 26 petef 2005-04-22 17:27:44 UTC
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 

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 probably need updating.

Comment 27 mikhail.voytenko 2005-04-25 10:30:41 UTC
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.
Comment 28 petef 2005-04-26 21:41:40 UTC
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.
Comment 29 michael.ruess 2005-04-27 10:21:45 UTC
Checked fix in 680m97.