bugtraq - Re: Flaw in OpenOffice.org 2.1: OpenOffice 2.1 is vulnerable to MS Word 0 day vulnerability!!!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20061215211147.19A6B3006D@evolution.bress.net>
Date: Fri, 15 Dec 2006 16:11:47 -0500
From: Josh Bressers <josh@...ss.net>
To: gplit@...lit.com
Cc: bugtraq@...urityfocus.com
Subject: Re: Flaw in OpenOffice.org 2.1: OpenOffice 2.1 is vulnerable to MS Word 0 day vulnerability!!!

> try yourself with OpenOffice.org 2.1:
> http://www.milw0rm.com/sploits/12122006-djtest.doc

This looks like it's an integer overflow that's then crashing on when
memset tries to write lots of zeros onto the heap.

Breakpoint 2, WW8PLCF::GeneratePLCF (this=0xb12a36e8, pSt=0xabae6cc8,
nPN=0, ncpN=587202560)
    at /usr/src/debug/OOD680_m5/sw/source/filter/ww8/ww8scan.cxx:2299
2299        nIMax = ncpN;
Current language:  auto; currently c++
(gdb) list
2294
2295    void WW8PLCF::GeneratePLCF( SvStream* pSt, long nPN, long ncpN )
2296    {
2297        ASSERT(!this, "Not a bug, but I (cmc) want to see this .doc as
an example");
2298        ASSERT( nIMax < (long)ncpN, "Pcl.Fkp: Warum ist PLCF zu gross
?" );

2299        nIMax = ncpN;
2300        long nSiz = 6 * nIMax + 4;
2301        pPLCF_PosArray = new INT32[ ( nSiz + 3 ) / 4 ]; // Pointer auf
Pos-Array
2302        memset( pPLCF_PosArray, 0, (size_t)nSiz );

(gdb) print ncpN
$1 = 587202560
(gdb) print nSiz
$2 = -771751932
(gdb) print *pPLCF_PosArray
$3 = 0

The memset at line 2302 tries to write 3523215364 zeros onto the heap at
the location of pPLCF_PosArray.

I don't see this exploitable beyond a DoS given the codepath here.  If
someone else could take a look and agree or disagree with me I would
appreciate it.

-- 
    JB