bugtraq - Re: 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>] [day] [month] [year] [list]

Message-ID: <20061216134327.10093.qmail@securityfocus.com>
Date: 16 Dec 2006 13:43:27 -0000
From: ox90x86@...mail.com
To: bugtraq@...urityfocus.com
Subject: Re: Re: Flaw in OpenOffice.org 2.1: OpenOffice 2.1 is vulnerable
 to MS Word 0 day vulnerability!!!

Do you happen to have a printout of the register states at the time of the crash.  Also, is ncpN user definable?? as you seemed to be correct in your calculation of 6*587202560+4=3523215364 and that amount of zero's being written.  But i guess you never know, if you will notice also maybe something else is going on here because at the look of this the buffer is always .75(in decimal) over, ex: if ncpN were userdefineable(as i havent tested yet) and lets say the value was just for shits 500, then the ultimate calculated value of the allocated pPLCF_PosArray == 500.75, same as if it were 600 it would ultimatly == 600.75.  why they did such weird buffer allocation im lost on though, (problem == either me sleep deprived or microsoft itself, you decide :-) ). The original had to do with i think an argument overflow from when the 5th argument was passed to sub_304536D3 from offset 0x274 in the original testcase. The value there is 0x23000000, from there that value was multiplied by
  4, and then subtracted by 1 at address 030193fd6 and then added to a pointer at 0x3019300b.  this is actually contrary to the post at http://research.eeye.com/html/alerts/zeroday/20061212.html where it was stated that the address was first subtracted and then multiplied if in fact the resulting return address is 0x8bfffffc or even remotely close to it would have meant that 0x23000000*4-1=0x8bffffff, but from the way they explained it 0x23000000-1*4=0x22fffffc... maybe im wrong or something....... If this is the case then exploitation would only mean changing the address at 0x274 to fit for the calculation and then be pointed at the address of shellcode stored where the "AAAA" is at in the document in memory. if this is the exact same flaw that is. But as again im just rambling and need register addresses if someone could give me some.  Thank you. WARNING: some info contained in this post could be wrong. Don't hold it against me :-)