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.
