[NEWS] OpenOffice document Heap Overflow

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html 

- - - - - - - - -



  OpenOffice document Heap Overflow
------------------------------------------------------------------------


SUMMARY

 <http://www.openoffice.org/> OpenOffice.org is "an office productivity 
suite, including word processing, spreadsheets, presentations, drawings, 
data charting, formula editing, and file conversion facilities".

A vulnerability in OpenOffice's DOC document header processing allows 
attackers to cause a heap-based buffer overflow.

DETAILS

Vulnerable Systems:
 * OpenOffice version 1.1.4 and prior
 * OpenOffice version 2.0dev

There is a vulnerability in the StgCompObjStream::Load() function, when 
reading a DOC document information of format, a memory is allocated by DOC 
to provide length.

DOC provides a 32 bits integer, and will use the low 16 bits of this 
number to allocate the memory, but when reading the doc information, it 
still use the 32 bits number for length, which may cause an heap overflow, 
and when the free happens, will cause pointer to be written, and may cause 
arbitrary code execute.

Vulnerable code:
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, it will allocate a 0x18 length memory, 
Read( p, nLen1) will still use 0x10000018 as length, and then the read 
will fail, but read length is bigger than allocated memory,and overwrite 
the next chunk.
When goto delete [] p;,write pointer happened. we had triggered this 
problem successful.

Proof of concept:
A proof of concept document file can be found at:  
<http://www.openoffice.org/issues/show_bug.cgi?id=46276> 
http://www.openoffice.org/issues/show_bug.cgi?id=46276 (Attachement named: 
vul3.doc)

CVE Information:
 <http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0941> 
CAN-2005-0941


ADDITIONAL INFORMATION

The information has been provided by  <mailto:[email protected]> adlab.



======================================== 


This bulletin is sent to members of the SecuriTeam mailing list. 
To unsubscribe from the list, send mail with an empty subject line and body to: [email protected] 
In order to subscribe to the mailing list, simply forward this email to: [email protected] 


==================== 
==================== 

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