88863 2005-04-12 08:01 0000 app-office/openoffice{-bin|ximian} DOC document Heap Overflow (CAN-2005-0941) 2005-05-15 22:06:35 0000 1 1 1 Unclassified Gentoo Security Vulnerabilities unspecified All All RESOLVED FIXED http://www.securityfocus.com/archive/1/395516/2005-04-08/2005-04-14/0 A2 [glsa] jaervosz P2 enhancement --- 1 jaervosz@gentoo.org security@gentoo.org openoffice@gentoo.org jaervosz@gentoo.org 2005-04-12 08:01:50 0000 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 jaervosz@gentoo.org 2005-04-12 08:02:23 0000 openoffice please advise. suka@gentoo.org 2005-04-12 08:54:49 0000 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 jaervosz@gentoo.org 2005-04-12 09:50:24 0000 OO bug here: http://www.openoffice.org/issues/show_bug.cgi?id=46388 suka@gentoo.org 2005-04-12 10:07:44 0000 Patch is here: http://cvs.gnome.org/viewcvs/*checkout*/ooo-build/patches/OOO_1_1/crash-objstream.diff?rev=1.1.2.1 suka@gentoo.org 2005-04-12 10:19:28 0000 openoffice-bin-1.1.4-r1 has the fix, marked ~x86 ~amd64 atm jaervosz@gentoo.org 2005-04-12 11:07:51 0000 suka any eta on the non-bin version? And what about the ximianized version? suka@gentoo.org 2005-04-12 11:13:50 0000 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. jaervosz@gentoo.org 2005-04-12 11:28:24 0000 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 hansmi@gentoo.org 2005-04-12 13:19:55 0000 Stable on ppc. tester@gentoo.org 2005-04-12 17:08:14 0000 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? suka@gentoo.org 2005-04-13 01:47:28 0000 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? koon@gentoo.org 2005-04-13 02:07:59 0000 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. koon@gentoo.org 2005-04-13 02:15:50 0000 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. koon@gentoo.org 2005-04-13 02:16:54 0000 Oops. That was a dupe. suka@gentoo.org 2005-04-13 07:54:18 0000 @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... tester@gentoo.org 2005-04-13 08:53:44 0000 you might want to remove the vulnerable -ximian ebuilds ? To force ppl to installed the patches ones.. x86 out blubb@gentoo.org 2005-04-13 09:38:26 0000 hparker already marked it stable for amd64 suka@gentoo.org 2005-04-13 15:17:48 0000 @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 koon@gentoo.org 2005-04-14 01:00:28 0000 Sparc: please mark stable openoffice-1.1.4-r1 and openoffice-ximian-1.3.7-r1. gustavoz@gentoo.org 2005-04-14 05:51:27 0000 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? gustavoz@gentoo.org 2005-04-14 17:59:13 0000 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. suka@gentoo.org 2005-04-14 23:34:47 0000 @Gustavo: Shouldn't the mozilla stuff be already disabled for sparc? Looks like in the ebuild to me. suka@gentoo.org 2005-04-14 23:59:05 0000 All vulnerable versions of openoffice and openoffice-ximian are now removed from the tree koon@gentoo.org 2005-04-15 00:51:40 0000 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. jaervosz@gentoo.org 2005-04-15 10:29:13 0000 GLSA 200504-13 Will stay open until ppc has a fixed version for -bin. suka@gentoo.org 2005-04-15 14:37:27 0000 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. koon@gentoo.org 2005-04-16 04:01:19 0000 I would say wait for the new release, and we'll update the GLSA. openoffice-ximian-bin is in ~ anyway... suka@gentoo.org 2005-04-23 12:38:34 0000 Just to point out: openoffice-bin-1.9.95 is now in the tree and includes the fix suka@gentoo.org 2005-05-07 12:15:30 0000 openoffice-ximian-bin now also has a newer version which is safe jaervosz@gentoo.org 2005-05-08 00:23:14 0000 GLSA 200504-13 now updated. jaervosz@gentoo.org 2005-05-15 22:06:35 0000 Nothing more to do on this bug -> Closing.