Talos Vulnerability Report

TALOS-2019-0805

Aspose Aspose.Words for C++ EnumMetaInfo Code Execution Vulnerability

August 20, 2019
CVE Number

CVE-2019-5041

Summary

An exploitable Stack Based Buffer Overflow vulnerability exists in the EnumMetaInfo function of Aspose Aspose.Words for C++, version 18.11.0.0. A specially crafted doc file can cause a stack-based buffer overflow, resulting in remote code execution. An attacker needs to provide a malformed file to the victim to trigger this vulnerability.

Tested Versions

Aspose Aspose.Words for C++ 18.11.0.0

Product URLs

https://products.aspose.com/words

CVSSv3 Score

9.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

CWE

CWE-121: Stack-based Buffer Overflow

Details

This vulnerability is present in the Aspose.Words for C++ which is used for all kinds of operations related with DOC(X) files. Aspose.Words library is used by many companies, banks, government organizations as a part of different software products responsible for data processing/conversion.
There is a vulnerability in the function responsible for handling meta info in a document. A specially crafted DOC file can lead to a stack-based buffer overflow and remote code execution.
Let's investigate this vulnerability. After we attempt to create an instance of Aspose::Words::Document object, taking as a input malformed DOC file, we see the following state:

0:000> g
(5e14.b14): C++ EH exception - code e06d7363 (first chance)
(5e14.b14): Unknown exception - code c00001a5 (!!! second chance !!!)
eax=012fe9b0 ebx=012fea60 ecx=00000003 edx=00000000 esi=74a11538 edi=132ba7c0
eip=7650c632 esp=012fe9b0 ebp=012fea08 iopl=0         nv up ei pl nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000212
KERNELBASE!RaiseException+0x62:
7650c632 8b4c2454        mov     ecx,dword ptr [esp+54h] ss:002b:012fea04=4be86816
0:000> !exchain
012feb8c: Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::Forms2::ClsidCacheIndex>::values+6c3331 (11263ca1)
012fec10: Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::Forms2::ClsidCacheIndex>::values+5fd8df (1119e24f)
012feca8: 8c5d4df7
Invalid exception stack at 00000001
0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


DUMP_CLASS: 2
DUMP_QUALIFIER: 0
FAULTING_IP: 
+0
8c5d4df7 ??              ???

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 8c5d4df7
   ExceptionCode: c00001a5
  ExceptionFlags: 00000001
NumberParameters: 1
   Parameter[0]: 00000003

FAULTING_THREAD:  00000b14
DEFAULT_BUCKET_ID:  APPLICATION_FAULT_AVRF
PROCESS_NAME:  example.exe
ERROR_CODE: (NTSTATUS) 0xc00001a5 - An invalid exception handler routine has been detected.
EXCEPTION_CODE: (NTSTATUS) 0xc00001a5 - An invalid exception handler routine has been detected.
EXCEPTION_CODE_STR:  c00001a5
EXCEPTION_PARAMETER1:  00000003

As we can see, the raised exception has a code 0xc00001a5, that is to say An invalid exception handler routine has been detected.. That state is also confirmed by the !exchain command, which shows that the SEH chain has been corrupted.
It can be a consequence of the stack-based buffer overflow which appeared before the exception was raised. Using the TTD functionality of windbgx, we can move backward to that moment before the SEH handler has been corrupted, landing inside the System::String::String constructor:

aspose_cpp_vc141.dll        ImageBase 0xB0E0000
Aspose.Words.Cpp_vc150.dll  ImageBase 0x16450000

Line 1  icu_59::UnicodeString *__thiscall sub_B938590(icu_59::UnicodeString *outString, struct_a2 *inString, char a3)
Line 2  {
Line 3    icu_59::UnicodeString *result; // eax@2
Line 4    int v4; // eax@8
Line 5    void *v5; // ST04_4@17
Line 6    void *v6; // eax@17
Line 7    int v7; // [esp+4h] [ebp-8h]@16
Line 8    struct_a2 *_outString; // [esp+8h] [ebp-4h]@1
Line 9 
Line 10   _outString = (struct_a2 *)outString;
Line 11   if ( (struct_a2 *)outString == inString )
Line 12     return outString;
Line 13   if ( icu_59::UnicodeString::isBogus((icu_59::UnicodeString *)inString) )
Line 14   {
Line 15     sub_B93A390(_outString);
Line 16     result = (icu_59::UnicodeString *)_outString;
Line 17   }
Line 18   else
Line 19   {
Line 20     sub_B939EA0(_outString);
Line 21     if ( icu_59::UnicodeString::isEmpty((icu_59::UnicodeString *)inString) )
Line 22     {
Line 23       icu_59::UnicodeString::setToEmpty((icu_59::UnicodeString *)_outString);
Line 24       result = (icu_59::UnicodeString *)_outString;
Line 25     }
Line 26     else
Line 27     {
Line 28       _outString->word4 = inString->word4;
Line 29       switch ( inString->word4 & 0x1F )
Line 30       {
Line 31         case 0:
Line 32           goto LABEL_16;
Line 33         case 2:
Line 34           v4 = icu_59::UnicodeString::getShortLength(_outString);
Line 35           memcpy(&_outString->strBeg, &inString->strBeg, 2 * v4);

The stack-based buffer overflow takes place exactly during the memcpy operation at line 35. The memcpy call is made with the following parameters:

0:000> dd esp L3
010feaf8  010feb72 010fec02 00000180

We can see that 0x180 bytes will be copied to the "buffer" pointed by 010feb72. Stepping back from the String constructor, we can see how much space has been "allocated" for dstString:

Line 1  void __thiscall sub_10812530(struct_v6 *this, char a2, _DWORD *a3, void *a4, int a5, int a6)
Line 2  {
Line 3   PBYTE srcString;
Line 4   BYTE  dstString[0x44]
Line 5    (...)
Line 6    v12 = *v10->ppfunc0;
Line 7    if ( v12 == sub_FD78FE0 )
Line 8    {
Line 9      v13 = v10->end - v10->current;
Line 10     bugyIndex = v13 / 12;
Line 11   }
Line 12   else
Line 13   {
Line 14     bugyIndex = ((int (__thiscall *)(struct_v11 *))v12)(v10);
Line 15   }
Line 16   v15 = (struct_v15 *)_this->pstruct_v718;
Line 17   strIndex = (struct_v9 *)bugyIndex;
Line 18   v16 = !v15 || _this->byte14 == 1 && !*_this->pdword1C;
Line 19   if ( v16 )
Line 20   {
Line 21     System::Detail::SmartPtrCounter::ThrowNullReferenceException(v13);
Line 22     v15 = (struct_v15 *)_this->pstruct_v718;
Line 23   }
Line 24   objStrCollection = v15->dword18;
Line 25   v18 = !objStrCollection || v15->byte14 == 1 && !*v15->pdword1C;
Line 26   if ( v18 )
Line 27   {
Line 28     System::Detail::SmartPtrCounter::ThrowNullReferenceException(objStrCollection);
Line 29     objStrCollection = v15->dword18;
Line 30   }
Line 31   System::Collections::Specialized::StringCollection::idx_get(objStrCollection, &srcString, strIndex);
Line 32
Line 33   v78 = operator new(0x60u);
Line 34   System::String::String((System::String *)&dstString, (const struct System::String *)&srcString);

At line 4 we see the dstString definition and its size, 0x44 bytes. Now it's clear why the buffer overflow happens.
Let's try to find out how and where srcString has been initialized. In line 31, the pointer to srcString is passed to the System::Collections::Specialized::StringCollection::idx_get method, where it will be initialized by an element from StringCollection. In our case strIndex has value 0xd2. Let's step into System::Collections::Specialized::StringCollection::idx_get:

.text:0B129F00 ; System::String *__thiscall System::Collections::Specialized::StringCollection::idx_get(int thisStrCollection, System::String *outString, int index)
.text:0B129F00                 public public: class System::String __thiscall System::Collections::Specialized::StringCollection::idx_get(int)const
.text:0B129F00 public: class System::String __thiscall System::Collections::Specialized::StringCollection::idx_get(int)const proc near
.text:0B129F00                                         ; DATA XREF: .rdata:off_D7534E8o
.text:0B129F00
.text:0B129F00 outString       = dword ptr  4
.text:0B129F00 index           = dword ptr  8
.text:0B129F00
.text:0B129F00                 mov     edx, [esp+index]
.text:0B129F04                 mov     eax, [ecx+8] ; objStrCollection ( 213ca7e0 )
.text:0B129F07                 mov     ecx, [esp+outString]
.text:0B129F0B                 shl     edx, 4
.text:0B129F0E                 add     edx, [esp+index]
.text:0B129F12                 lea     eax, [eax+edx*4]
.text:0B129F15                 push    eax             ; struct System::String *
.text:0B129F16                 call    System::String::String(System::String const &)
.text:0B129F1B                 mov     eax, [esp+outString]
.text:0B129F1F                 retn    8
.text:0B129F1F public: class System::String __thiscall System::Collections::Specialized::StringCollection::idx_get(int)const endp

We can see that the calculated address of an element is later passed to the String constructor. First, let's examine a memory pointed by calculated element. Having EIP at address 0B129F16:

0:000> dd eax
213cdfa8  c0c0c0c0 c0c0c0c0 c0c0c0c0 c0c0c0c0
213cdfb8  c0c0c0c0 c0c0c0c0 c0c0c0c0 c0c0c0c0
213cdfc8  c0c0c0c0 c0c0c0c0 c0c0c0c0 c0c0c0c0
213cdfd8  c0c0c0c0 c0c0c0c0 c0c0c0c0 c0c0c0c0
213cdfe8  c0c0c0c0 c0c0c0c0 c0c0c0c0 c0c0c0c0
213cdff8  c0c0c0c0 d0c0c0c0 ???????? ????????
213ce008  ???????? ???????? ???????? ????????
213ce018  ???????? ???????? ???????? ????????

The memory area is uninitialized (actually it is initialized, but by the heap allocator), and the outString/srcString object is initialized/constructed based on these values.
Let's examine allocation size and capacity of objStrCollection:

0:000> !heap -p -a 213ca7e0
    address 213ca7e0 found in
    _DPH_HEAP_ROOT @ 15cd1000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                212d2e38:         213ca7d0             382f -         213ca000             5000
          unknown!fillpattern
    7763ab40 verifier!AVrfDebugPageHeapAllocate+0x00000240
    7751adab ntdll!RtlDebugAllocateHeap+0x00000039
    774c223d ntdll!RtlpAllocateHeap+0x0004f4cd
    774723b0 ntdll!RtlpAllocateHeapInternal+0x00000460
    77471f3e ntdll!RtlAllocateHeap+0x0000003e
    76270d76 ucrtbase!_malloc_base+0x00000026
    1a93dc9c aspose_cpp_vc141!System::Data::SqlClient::SqlConnectionStringBuilder::set_UserID+0x007277fc
    19f4743b aspose_cpp_vc141!std::vector<System::String,std::allocator<System::String> >::_Emplace_reallocate<System::String const &>+0x000000db
    19f48855 aspose_cpp_vc141!System::Collections::Specialized::StringCollection::Add+0x00000025
    1713fef1 Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::RW::Doc::NFibValue>::values+0x00098781
    1713fb3d Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::RW::Doc::NFibValue>::values+0x000983cd
    1713eb0f Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::RW::Doc::NFibValue>::values+0x0009739f
    1713e92f Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::RW::Doc::NFibValue>::values+0x000971bf
    16fe3b39 Aspose_Words_Cpp_vc150!Aspose::Words::Themes::ThemeFonts::GetSharedMembers+0x00235989
    170bd373 Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::RW::Doc::NFibValue>::values+0x00015c03
    170bbd09 Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::RW::Doc::NFibValue>::values+0x00014599
    170b3ce1 Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::RW::Doc::NFibValue>::values+0x0000c571
    170df391 Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::RW::Doc::NFibValue>::values+0x00037c21
    170b3114 Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::RW::Doc::NFibValue>::values+0x0000b9a4
    16565cfc Aspose_Words_Cpp_vc150!Aspose::Words::IncorrectPasswordException::IncorrectPasswordException+0x0002553c
    1651d786 Aspose_Words_Cpp_vc150!Aspose::Words::Document::StopTrackRevisions+0x00000bd6
    1651d046 Aspose_Words_Cpp_vc150!Aspose::Words::Document::StopTrackRevisions+0x00000496
    165177d2 Aspose_Words_Cpp_vc150!Aspose::Words::Document::Document+0x00000562

So, there is space for:

0:000> ?382f / 0x44
Evaluate expression: 211 = 000000d3

0xd3 elements.

This means that we are still "in bounds" of the objStrCollection container, but that last element is not initialized.
Elements are added to that container by the function sub_1096FD60, via a call to the System::Collections::Specialized::StringCollection::Add method. The container is filled with data (strings) coming from a structure being located in the file around offset 0xB6D0.
The stack-based buffer overflow occurs because the application reaches to an element not being initialized in the container, which makes the iteration over this collection to depend on a different value than real container size. We discover the answer inside the function sub_108D9E60:

Line 1  int __usercall sub_108D9E60@<eax>(int cbData@<edx>, char *cbPlc@<ecx>, char a3, int a4, void *a5, char a6, int a7, void *a8, ...)
Line 2  {
Line 3 
Line 4 
Line 5    va_start(va, a8);
Line 6    v25 = cbData;
Line 7    v29 = cbPlc;
Line 8    v36 = 2;
Line 9    if ( cbPlc )
Line 10   {
Line 11     index_limit = (signed int)(cbPlc - 4) / (cbData + 4);
Line 12     if ( *sub_108D9D90() )
Line 13     {
Line 14       System::String::String(&v32, L"\nReading PLCF {0}, tableSize:{1}, structureSize:{2}, structureCount:{3}.", 72);
Line 15       v26 = 0;
Line 16       v27 = 0;
Line 17       LOBYTE(v36) = 4;
Line 18       v8 = System::String::ToU16Str(&v32, &v35);
Line 19       LOBYTE(v36) = 5;
Line 20       System::Details::FormatBuilder::FormatBuilder(&v33, v8, &v26);
Line 21       sub_FD17610(&v35);
Line 22       LOBYTE(v36) = 8;
Line 23       (...)
Line 24     }
Line 25     v29 = &v22;
Line 26     v22 = 0;
Line 27     sub_FD23BD0(&v22, &a6);
Line 28     LOBYTE(v36) = 9;
Line 29     sub_FD09890(&v19, (int)&a3, (int)&v19);
Line 30     LOBYTE(v36) = 2;
Line 31     sub_108DA100(index_limit,v19, v20, v21, v22, v23, v24);     

It turns out that the value which controls the amount of iterations over objStrCollection is controlled by the index_limit variable. Its value is calculated based on cbPlc and cbData at line 11. More information about PLC structure we can find in documentation.
In our case, the value of an equation from the line 11 is equal to:

cbPLC  = 0x92C
cbData = 4

so index_limit = 0x125.

That clearly explains why the uninitialized element is read from a collection, which consequently leads to a stack-based buffer overflow and can be turned by the attacker into remote code execution.

Crash Information

0:000> g
(5e14.b14): C++ EH exception - code e06d7363 (first chance)
(5e14.b14): Unknown exception - code c00001a5 (!!! second chance !!!)
eax=012fe9b0 ebx=012fea60 ecx=00000003 edx=00000000 esi=74a11538 edi=132ba7c0
eip=7650c632 esp=012fe9b0 ebp=012fea08 iopl=0         nv up ei pl nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000212
KERNELBASE!RaiseException+0x62:
7650c632 8b4c2454        mov     ecx,dword ptr [esp+54h] ss:002b:012fea04=4be86816
0:000> !exchain
012feb8c: Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::Forms2::ClsidCacheIndex>::values+6c3331 (11263ca1)
012fec10: Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::Forms2::ClsidCacheIndex>::values+5fd8df (1119e24f)
012feca8: 8c5d4df7
Invalid exception stack at 00000001
0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


DUMP_CLASS: 2

DUMP_QUALIFIER: 0

FAULTING_IP: 
+0
8c5d4df7 ??              ???

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 8c5d4df7
   ExceptionCode: c00001a5
  ExceptionFlags: 00000001
NumberParameters: 1
   Parameter[0]: 00000003

FAULTING_THREAD:  00000b14

DEFAULT_BUCKET_ID:  APPLICATION_FAULT_AVRF

PROCESS_NAME:  example.exe

ERROR_CODE: (NTSTATUS) 0xc00001a5 - An invalid exception handler routine has been detected.

EXCEPTION_CODE: (NTSTATUS) 0xc00001a5 - An invalid exception handler routine has been detected.

EXCEPTION_CODE_STR:  c00001a5

EXCEPTION_PARAMETER1:  00000003

WATSON_BKT_PROCSTAMP:  5c88e1ec

WATSON_BKT_MODULE:  unknown

WATSON_BKT_MODVER:  0.0.0.0

WATSON_BKT_MODOFFSET:  8c5d4df7

WATSON_BKT_MODSTAMP:  bbbbbbb4

BUILD_VERSION_STRING:  10.0.17763.292 (WinBuild.160101.0800)

MODLIST_WITH_TSCHKSUM_HASH:  d5c32da0028a8f7a01fafb40db1372df6bf768dc

MODLIST_SHA1_HASH:  682c802ad752a726fb62875068b4f24dc2fdcd30

NTGLOBALFLAG:  2000000

PROCESS_BAM_CURRENT_THROTTLED: 0

PROCESS_BAM_PREVIOUS_THROTTLED: 0

APPLICATION_VERIFIER_FLAGS:  0

PRODUCT_TYPE:  1

SUITE_MASK:  272

DUMP_TYPE:  fe

APPLICATION_VERIFIER_LOADED: 1

ANALYSIS_SESSION_HOST:  DESKTOP-E4N8506

ANALYSIS_SESSION_TIME:  04-05-2019 17:00:36.0743

ANALYSIS_VERSION: 10.0.15063.468 x86fre

LAST_CONTROL_TRANSFER:  from 74a14796 to 7650c632

THREAD_ATTRIBUTES: 
THREAD_SHA1_HASH_MOD_FUNC:  fdbfbc97b0e3c3ec709c42a80da154a7b4d11bb7

THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  792c646ec899ce2a2a720d6b99d1ed09091822d3

OS_LOCALE:  ENU

PROBLEM_CLASSES: 

    ID:     [0n299]
    Type:   [APPLICATION_FAULT]
    Class:  Primary
    Scope:  DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
            BUCKET_ID
    Name:   Add
    Data:   Omit
    PID:    [Unspecified]
    TID:    [Unspecified]
    Frame:  [0]

    ID:     [0n92]
    Type:   [AVRF]
    Class:  Addendum
    Scope:  DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
            BUCKET_ID
    Name:   Add
    Data:   Omit
    PID:    [0x5e14]
    TID:    [0xb14]
    Frame:  [0] : KERNELBASE!RaiseException

BUGCHECK_STR:  APPLICATION_FAULT_AVRF

PRIMARY_PROBLEM_CLASS:  APPLICATION_FAULT

STACK_TEXT:  
012fe9b0 7650c632 KERNELBASE!RaiseException+0x62
012fea10 74a14796 VCRUNTIME140!_CxxThrowException+0x66
012fea54 10fc0960 Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::Forms2::ClsidCacheIndex>::values+0x41fff0
012feba0 10812213 Aspose_Words_Cpp_vc150!Aspose::Words::Themes::ThemeFonts::GetSharedMembers+0x234063
012fec24 10812719 Aspose_Words_Cpp_vc150!Aspose::Words::Themes::ThemeFonts::GetSharedMembers+0x234569
012fed14 7751b0b9 ntdll!RtlDebugAllocateHeap+0x347
012fedd0 774c223d ntdll!RtlpAllocateHeap+0x4f4cd
012fede8 77639802 verifier!AVrfpDphPlaceOnDelayFree+0x272
012ff040 0aa72fec unknown!unknown+0x0
012ff05c 0fe58d71 Aspose_Words_Cpp_vc150!Aspose::Words::MailMerging::MailMerge::set_MailMergeCallback+0xded1
012ff110 1090fb17 Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::RW::Doc::NFibValue>::values+0x383a7


STACK_COMMAND:  .ecxr ; kb ; dps 12fe9b0 ; kb

THREAD_SHA1_HASH_MOD:  5ddaf0fd9571830d6b3721a417ce38b031c369be

FOLLOWUP_IP: 
Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::Forms2::ClsidCacheIndex>::values+41fff0
10fc0960 cc              int     3

FAULT_INSTR_CODE:  cccccccc

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::Forms2::ClsidCacheIndex>::values+41fff0

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Aspose_Words_Cpp_vc150

IMAGE_NAME:  Aspose.Words.Cpp_vc150.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  5be4febd

BUCKET_ID:  APPLICATION_FAULT_AVRF_Aspose_Words_Cpp_vc150!EnumMetaInfo_enum_Aspose::Words::Forms2::ClsidCacheIndex_::values+41fff0

FAILURE_EXCEPTION_CODE:  c00001a5

FAILURE_IMAGE_NAME:  Aspose.Words.Cpp_vc150.dll

BUCKET_ID_IMAGE_STR:  Aspose.Words.Cpp_vc150.dll

FAILURE_MODULE_NAME:  Aspose_Words_Cpp_vc150

BUCKET_ID_MODULE_STR:  Aspose_Words_Cpp_vc150

FAILURE_FUNCTION_NAME:  EnumMetaInfo_enum_Aspose::Words::Forms2::ClsidCacheIndex_::values

BUCKET_ID_FUNCTION_STR:  EnumMetaInfo_enum_Aspose::Words::Forms2::ClsidCacheIndex_::values

BUCKET_ID_OFFSET:  41fff0

BUCKET_ID_MODTIMEDATESTAMP:  5be4febd

BUCKET_ID_MODCHECKSUM:  396b5e7

BUCKET_ID_MODVER_STR:  18.11.0.0

BUCKET_ID_PREFIX_STR:  APPLICATION_FAULT_AVRF_

FAILURE_PROBLEM_CLASS:  APPLICATION_FAULT

FAILURE_SYMBOL_NAME:  Aspose.Words.Cpp_vc150.dll!EnumMetaInfo_enum_Aspose::Words::Forms2::ClsidCacheIndex_::values

FAILURE_BUCKET_ID:  APPLICATION_FAULT_AVRF_c00001a5_Aspose.Words.Cpp_vc150.dll!EnumMetaInfo_enum_Aspose::Words::Forms2::ClsidCacheIndex_::values

TARGET_TIME:  2019-04-05T15:00:45.000Z

OSBUILD:  17763

OSSERVICEPACK:  292

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

OSPLATFORM_TYPE:  x86

OSNAME:  Windows 10

OSEDITION:  Windows 10 WinNt SingleUserTS

USER_LCID:  0

OSBUILD_TIMESTAMP:  unknown_date

BUILDDATESTAMP_STR:  160101.0800

BUILDLAB_STR:  WinBuild

BUILDOSVER_STR:  10.0.17763.292

ANALYSIS_SESSION_ELAPSED_TIME:  2308

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:application_fault_avrf_c00001a5_aspose.words.cpp_vc150.dll!enummetainfo_enum_aspose::words::forms2::clsidcacheindex_::values

FAILURE_ID_HASH:  {5441d6c3-6cb2-8c68-f8ec-1d26da9e3029}

Followup:     MachineOwner
---------

0:000> kb
 # ChildEBP RetAddr  Args to Child              
00 012fea08 74a14796 e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x62
01 012fea4c 10fc0960 012fea60 132ba7c0 8c5d4adb VCRUNTIME140!_CxxThrowException+0x66 [f:\dd\vctools\crt\vcruntime\src\eh\throw.cpp @ 129] 
WARNING: Stack unwind information not available. Following frames may be wrong.
02 012feb98 10812213 10812100 00000000 00000004 Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::Forms2::ClsidCacheIndex>::values+0x41fff0
03 012fec1c 10812719 0c1e4878 005f1802 00000f89 Aspose_Words_Cpp_vc150!Aspose::Words::Themes::ThemeFonts::GetSharedMembers+0x234063
04 012fed0c 7751b0b9 774c223d 0000003c 95fabe91 Aspose_Words_Cpp_vc150!Aspose::Words::Themes::ThemeFonts::GetSharedMembers+0x234569
05 012fedc8 774c223d 00000038 95fabe69 05cc0000 ntdll!RtlDebugAllocateHeap+0x347
06 012fede0 77639802 05cc1000 05cc16cc 012fee08 ntdll!RtlpAllocateHeap+0x4f4cd
07 012ff038 0aa72fec 0c1e4878 005000e2 0063006c verifier!AVrfpDphPlaceOnDelayFree+0x272
08 012ff054 0fe58d71 0fe58d97 d3d0bc99 012ff138 0xaa72fec
09 012ff108 1090fb17 012ff130 77471f3e 012ff1f0 Aspose_Words_Cpp_vc150!Aspose::Words::MailMerging::MailMerge::set_MailMergeCallback+0xded1
0a 00000000 00000000 00000000 00000000 00000000 Aspose_Words_Cpp_vc150!EnumMetaInfo<enum Aspose::Words::RW::Doc::NFibValue>::values+0x383a7


Image name: Aspose.Words.Cpp_vc150.dll
Browse all global symbols  functions  data
Timestamp:        Fri Nov  9 04:27:57 2018 (5BE4FEBD)
CheckSum:         0396B5E7
ImageSize:        039AB000
File version:     18.11.0.0
Product version:  18.11.0.0
File flags:       0 (Mask 3F)
File OS:          40004 NT Win32
File type:        2.0 Dll
File date:        00000000.00000000
Translations:     0409.04b0
CompanyName:      Aspose Pty Ltd
ProductName:      Aspose.Words for C++
OriginalFilename: Aspose.Words.Cpp_vc150.dll
ProductVersion:   18.11
FileVersion:      18.11
FileDescription:  Aspose.Words for C++
LegalCopyright:   Copyright 2003-2018 Aspose Pty Ltd
Comments:         Aspose.Words for C++

Timeline

2019-04-17 - Vendor Disclosure
2019-08-20 - Public Disclosure
2019-08-24 - Vendor acknowledged & advised issues under review
2019-08-30 - Vendor patched

Credit

Discovered by Marcin 'Icewall' Noga of Cisco Talos.