Microsoft Office 2007 – ‘OGL.dll’ DpOutputSpanStretch::OutputSpan Out of Bounds Write (MS15-080)

• Exploit Database
• 108 阅读

• 作者： Google Security Research
  日期： 2015-08-21
• 类别：

  • dos
  平台：

  • windows
• 来源：https://www.exploit-db.com/exploits/37911/
• 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69

  Source: https://code.google.com/p/google-security-research/issues/detail?id=420&can=1   The following crash was observed in Microsoft Office 2007 with Microsoft Office File Validation Add-In disabled and Application Verifier enabled for testing and reproduction. This bug also reproduced in Office 2010 running on Windows 7 x86.   The crash is caused by a 1 bit delta from the original file at offset 0x4A45. OffViz identified this offset as OLESSRoot.DirectoryEntries[100].OLESSDirectoryEntry[20].sidLeft with an original value of 0x00000000 and a fuzzed value of 0x00008000.   Attached files:   Fuzzed minimized PoC: 1863274449_min.doc Fuzzed non-minimized PoC: 1863274449_crash.doc Original non-fuzzed file: 1863274449_orig.doc DLL Versions:   OGL.dll: 12.0.6719.5000 wwlib.dll: 12.0.6720.5000 GDI32.dll: 5.2.3790.5563   eax=ffff0002 ebx=12b85fd8 ecx=fffff975 edx=fffc0008 esi=ffff8000 edi=12b81f50 eip=3bd186a1 esp=00129f68 ebp=00129f98 iopl=0 nv up ei ng nz na po cy cs=001bss=0023ds=0023es=0023fs=003bgs=0000 efl=00010283   3bd1869c 8bd0mov edx,eax 3bd1869e c1e202shl edx,2 OGL!DpOutputSpanStretch<1>::OutputSpan+0x13e: 3bd186a1 890c1amov dword ptr [edx+ebx],ecx ds:0023:12b45fe0=????????   0:000> kb L8 ChildEBP RetAddrArgs to Child 00129f98 3be70c01 0000014c 000001d9 00000267 OGL!DpOutputSpanStretch<1>::OutputSpan+0x13e 00129fcc 3be6f93d 0000014c 000001d9 00000267 OGL!EpAntialiasedFiller::OutputSpan+0x2f 00129ff0 3be70ba0 0000014c 000001d9 00000267 OGL!DpClipRegion::OutputSpan+0x84 0012a010 3be6e30c 0000014c 0012aa38 00000533 OGL!EpAntialiasedFiller::GenerateOutputAndClearCoverage+0x62 0012a038 3be7052c 00000533 000001e6 00000798 OGL!EpAntialiasedFiller::FillEdgesAlternate+0x102 0012a050 3be6f8a0 7fffffff 0012a0ac 00000000 OGL!RasterizeEdges+0xa7 0012ab08 3bd43c10 0012abc0 0012ab3c 3be70d78 OGL!RasterizePath+0x2ce 0012acf4 3be4cd7e 1292eda8 0012ae10 122f2f98 OGL!DpDriver::DrawImage+0x230   In this crash ebx is pointing to valid memory allocated from OGL!DpOutputSpanStretch<1>::InitializeClass with a size of 24. However, the edx value appears to have a sign extension issue leading to an out of bounds write. When eax was moved to edx at 0x3bd1869c eax already appeared to have sign extended value (0xffff0002). Eax is being updated in a loop in this function starting at 0x3bdb94d5. The value originally comes from [edi+9ch]. This will be set to 0xffff0002 on the crashing iteration. The offset at [edi+9ch] is updated at 0x3be18b37 and 0x3be18b49. Tracing back from these writes just a bit further we can step through the crux of the issue during the first loop iteration:   eax=800182ae ebx=000100d7 ecx=8004845a edx=00008005 esi=80008100 edi=128a1f50 eip=3bdb946a esp=00129f68 ebp=00129f98 iopl=0 ov up ei ng nz ac pe nc cs=001bss=0023ds=0023es=0023fs=003bgs=0000 efl=00000a96 OGL!DpOutputSpanStretch<1>::OutputSpan+0x65: 3bdb946a c1f910sar ecx,10h 0:000> p eax=800182ae ebx=000100d7 ecx=ffff8004 edx=00008005 esi=80008100 edi=128a1f50 eip=3bdb946d esp=00129f68 ebp=00129f98 iopl=0 nv up ei ng nz na po cy cs=001bss=0023ds=0023es=0023fs=003bgs=0000 efl=00000283 OGL!DpOutputSpanStretch<1>::OutputSpan+0x68: 3bdb946d c1fe10sar esi,10h 0:000> p eax=800182ae ebx=000100d7 ecx=ffff8004 edx=00008005 esi=ffff8000 edi=128a1f50 eip=3bdb9470 esp=00129f68 ebp=00129f98 iopl=0 nv up ei ng nz na pe cy cs=001bss=0023ds=0023es=0023fs=003bgs=0000 efl=00000287 OGL!DpOutputSpanStretch<1>::OutputSpan+0x6b: 3bdb9470 81faffffff7fcmp edx,7FFFFFFFh   The sar instruction applied to ecx and esi will sign extend the values in these registers. If this is allowed to happen there must be a check to ensure that the resulting values are still in range to the allocated heap buffer.   To get your debugger to the correct spot given the attached PoC realize that there are two DpOutputSpanStretch object created before the crash. The first one is of no consequence. The OutputSpan function is also called twice on this new object before entering the crashing state. I suggest using a conditional breakpoint to get to the correct spot:   bp 3bdb946d ".if (@esi & 0x<code>ffffffff) = 0x</code>80008100 {} .else{gc}"   This crash is writing to a memory address out-of-bound to the allocated buffer, therefore this is an exploitable vulnerability.   Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37911.zip