Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 88863 - app-office/openoffice{-bin|ximian} DOC document Heap Overflow (CAN-2005-0941)
Summary: app-office/openoffice{-bin|ximian} DOC document Heap Overflow (CAN-2005-0941)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Gentoo Security
URL: http://www.securityfocus.com/archive/...
Whiteboard: A2 [glsa] jaervosz
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-12 08:01 UTC by Sune Kloppenborg Jeppesen (RETIRED)
Modified: 2005-05-15 22:06 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-12 08:01:50 UTC
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
Comment 1 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-12 08:02:23 UTC
openoffice please advise.
Comment 2 Andreas Proschofsky (RETIRED) gentoo-dev 2005-04-12 08:54:49 UTC
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
Comment 3 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-12 09:50:24 UTC
OO bug here:

http://www.openoffice.org/issues/show_bug.cgi?id=46388
Comment 4 Andreas Proschofsky (RETIRED) gentoo-dev 2005-04-12 10:07:44 UTC
Patch is here:

http://cvs.gnome.org/viewcvs/*checkout*/ooo-build/patches/OOO_1_1/crash-objstream.diff?rev=1.1.2.1
Comment 5 Andreas Proschofsky (RETIRED) gentoo-dev 2005-04-12 10:19:28 UTC
openoffice-bin-1.1.4-r1 has the fix, marked ~x86 ~amd64 atm
Comment 6 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-12 11:07:51 UTC
suka any eta on the non-bin version? And what about the ximianized version?
Comment 7 Andreas Proschofsky (RETIRED) gentoo-dev 2005-04-12 11:13:50 UTC
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.
Comment 8 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-12 11:28:24 UTC
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




Comment 9 Michael Hanselmann (hansmi) (RETIRED) gentoo-dev 2005-04-12 13:19:55 UTC
Stable on ppc.
Comment 10 Olivier Crete (RETIRED) gentoo-dev 2005-04-12 17:08:14 UTC
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?
Comment 11 Andreas Proschofsky (RETIRED) gentoo-dev 2005-04-13 01:47:28 UTC
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?
Comment 12 Thierry Carrez (RETIRED) gentoo-dev 2005-04-13 02:07:59 UTC
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.
Comment 13 Thierry Carrez (RETIRED) gentoo-dev 2005-04-13 02:15:50 UTC
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.
Comment 14 Thierry Carrez (RETIRED) gentoo-dev 2005-04-13 02:16:54 UTC
Oops. That was a dupe.
Comment 15 Andreas Proschofsky (RETIRED) gentoo-dev 2005-04-13 07:54:18 UTC
@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...
Comment 16 Olivier Crete (RETIRED) gentoo-dev 2005-04-13 08:53:44 UTC
you might want to remove the vulnerable -ximian ebuilds ? To force ppl to installed the patches ones.. x86 out
Comment 17 Simon Stelling (RETIRED) gentoo-dev 2005-04-13 09:38:26 UTC
hparker already marked it stable for amd64
Comment 18 Andreas Proschofsky (RETIRED) gentoo-dev 2005-04-13 15:17:48 UTC
@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
Comment 19 Thierry Carrez (RETIRED) gentoo-dev 2005-04-14 01:00:28 UTC
Sparc: please mark stable openoffice-1.1.4-r1 and openoffice-ximian-1.3.7-r1.
Comment 20 Gustavo Zacarias (RETIRED) gentoo-dev 2005-04-14 05:51:27 UTC
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?
Comment 21 Gustavo Zacarias (RETIRED) gentoo-dev 2005-04-14 17:59:13 UTC
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.
Comment 22 Andreas Proschofsky (RETIRED) gentoo-dev 2005-04-14 23:34:47 UTC
@Gustavo: Shouldn't the mozilla stuff be already disabled for sparc? Looks like in the ebuild to me.
Comment 23 Andreas Proschofsky (RETIRED) gentoo-dev 2005-04-14 23:59:05 UTC
All vulnerable versions of openoffice and openoffice-ximian are now removed from the tree
Comment 24 Thierry Carrez (RETIRED) gentoo-dev 2005-04-15 00:51:40 UTC
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.
Comment 25 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-15 10:29:13 UTC
GLSA 200504-13

Will stay open until ppc has a fixed version for -bin.
Comment 26 Andreas Proschofsky (RETIRED) gentoo-dev 2005-04-15 14:37:27 UTC
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.
Comment 27 Thierry Carrez (RETIRED) gentoo-dev 2005-04-16 04:01:19 UTC
I would say wait for the new release, and we'll update the GLSA. openoffice-ximian-bin is in ~ anyway...
Comment 28 Andreas Proschofsky (RETIRED) gentoo-dev 2005-04-23 12:38:34 UTC
Just to point out: openoffice-bin-1.9.95 is now in the tree and includes the fix
Comment 29 Andreas Proschofsky (RETIRED) gentoo-dev 2005-05-07 12:15:30 UTC
openoffice-ximian-bin now also has a newer version which is safe
Comment 30 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-08 00:23:14 UTC
GLSA 200504-13 now updated.
Comment 31 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-15 22:06:35 UTC
Nothing more to do on this bug -> Closing.