Headline
CVE-2019-5041: TALOS-2019-0805 || Cisco Talos Intelligence Group
An exploitable Stack Based Buffer Overflow vulnerability exists in the EnumMetaInfo function of Aspose Aspose.Words library, 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.
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
Discovered by Marcin ‘Icewall’ Noga of Cisco Talos.