Bugzilla Bug 88863

OpenOffice DOC document Heap Overflow
[Security Advisory]

Advisory:[AD_LAB-05001] OpenOffice DOC document Heap Overflow
Class: Design Error
DATE:30/3/2005
CVEID:CAN-2005-0941
Vulnerable:
    <=OpenOffice OpenOffice 1.1.4
    -OpenOffice OpenOffice 2.0dev
    
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.
        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

openoffice please advise.

For the binary there are already new files

ftp://ftp.stardiv.de/pub/OpenOffice.org/contrib/rc/1.1.4secpatch/

Going to add this asap

Still looking for a patch for the source based versions, though

OO bug here:

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

Patch is here:

http://cvs.gnome.org/viewcvs/*checkout*/ooo-build/patches/OOO_1_1/crash-objstream.diff?rev=1.1.2.1

openoffice-bin-1.1.4-r1 has the fix, marked ~x86 ~amd64 atm

suka any eta on the non-bin version? And what about the ximianized version?

Commited a bunch of revision bumps, which contain the necessary fix:

openoffice-1.1.4-r1

openoffice-ximian-1.3.6-r1

openoffice-ximian-1.3.7-r1

openoffice-ximian-1.3.9-r1

All are marked unstable on all archs at the moment. Going to mark them stable on x86 tomorow, if everything goes smoothly. For other archs their respective maintainers should comment.

Thx for the swift reaction Andreas.

Arches please test and mark stable. Target keywords are:

openoffice-1.1.4-r1: x86 ppc sparc

openoffice-bin-1.1.4-r1: x86 amd64

openoffice-ximian-1.3.6-r1: ~x86 ppc

openoffice-ximian-1.3.7-r1: x86 ~ppc sparc

openoffice-ximian-1.3.9-r1:x86 ~ppc ~sparc

Stable on ppc.

I've got the -bin covered on x86, but I dont have enough free hd space to build
the others... suka, can you mark them? I guess you've already tested them?

openoffice-1.1.4-r1 and openoffice-ximian-1.3.9-r1 are now stable on x86, just
took some time to build... Crash with the manipulated work document from the
OOo-bug does not work anymore, so I think this counts as fixed.

One thing more that I want to point out: We still have a openoffice-bin-1.1.1
which is marked stable on ppc, don't know how to deal with this, it should be
vulenerable too, but I don't think a fix exists yet.

Also we have the openoffice-bin-2.0-pre in the tree which is also vulnerable
but this is hard masked anyway? Is this sufficient?

About the unfixed ppc: we'll issue a temporary GLSA that says ppc is still
affected.

About the hardmasked vulnerable version: yes, hardmasking is sufficient. Maybe
add to the masking comment that there are stability *and* security issues with
that version.

Candidate: CAN-2005-1044
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1044
Reference: BUGTRAQ:20050412 OpenOffice DOC document Heap Overflow
Reference: URL:http://www.securityfocus.com/archive/1/395516
Reference: CONFIRM:http://www.openoffice.org/issues/show_bug.cgi?id=46388

The StgCompObjStream::Load function in OpenOffice.org OpenOffice 1.1.4
and earlier allocates memory based on 16 bit length values, but
process memory using 32 bit values, which allows remote attackers to
cause a denial of service and possibly execute arbitrary code via a
DOC document with certain length values, which leads to a heap-based
buffer overflow.

Oops. That was a dupe.

@Koon: openoffice-bin-2.0-pre will get a new release soon, which has the fix,
so no need to add a message, I think.

Other than that mainly sparc updates are missing now...

you might want to remove the vulnerable -ximian ebuilds ? To force ppl to
installed the patches ones.. x86 out

hparker already marked it stable for amd64

@Olivier: Already did that some hours ago for 1.3.9 and 1.3.6, 1.3.7 is still
there until 1.3.7-r1 is stable on sparc

Sparc: please mark stable openoffice-1.1.4-r1 and openoffice-ximian-1.3.7-r1.

Can you relax a bit? Do you know how long this takes to compile?
Here:

     Wed Apr 13 20:24:23 2005 >>> app-office/openoffice-ximian-1.3.9-r1
       merge time: 1 day, 4 hours, 25 minutes and 11 seconds.

WE KNOW, WE ARE WORKING ON IT, WE DON'T WANT TO MAKE UNNECESSARY NOISE IN THE BUGS. OK?

openoffice-ximian-1.3.9-r1 stable on sparc.
openoffice-1.1.4-r1 breaks on moz stuff - given that our virtual has been pointing to -ximian for quite some time, and we prefer -ximian in general (it's even on the package CDs instead of regular OO) feel free to ditch it entirely for us.
We may look into getting it in shape back for sparc, but given long compile times and -ximian being superior in general i don't forsee this happening soon.

@Gustavo: Shouldn't the mozilla stuff be already disabled for sparc? Looks like
in the ebuild to me.

All vulnerable versions of openoffice and openoffice-ximian are now removed
from the tree

Ready for a temporary GLSA stating that ppc openoffice-bin users should switch
to openoffice (non-bin) and sparc openoffice users should switch to
openoffice-ximian.

GLSA 200504-13

Will stay open until ppc has a fixed version for -bin.

As just has been pointed out (I actually forgot about that one...)
openoffice-ximian-bin-1.1.53 should also be vulnerable to this.  So either we
put this in package.mask or wait for a new release, which should be quite soon.
Actually I've openoffice-ximian-bin-1.3.9 ready here locally, just waiting for
an update by Novell which also carries the security fix.

I would say wait for the new release, and we'll update the GLSA.
openoffice-ximian-bin is in ~ anyway...

Just to point out: openoffice-bin-1.9.95 is now in the tree and includes the
fix

openoffice-ximian-bin now also has a newer version which is safe

GLSA 200504-13 now updated.

Nothing more to do on this bug -> Closing.