Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=819
Simple fuzzing found an integer overflow in the dec2tnef library. This allocation from Attachment::setDataFromAttachment() doesn't verify that the attacker controlled value doesn't wrap:
.text:000227B8 8D 42 01 lea eax, [edx+1]
.text:000227BB 89 85 68 FF FF+ mov [ebp+var_98], eax
.text:000227C1 8B 83 CC FF FF+ mov eax, ds:(_ZSt7nothrow_ptr - 42CFCh)[ebx]
.text:000227C7 89 44 24 04 mov [esp+4], eax
.text:000227CB 8B 85 68 FF FF+ mov eax, [ebp+var_98]
.text:000227D1 C1 E0 02 shl eax, 2
.text:000227D4 89 04 24 mov [esp], eax
.text:000227D7 89 95 5C FF FF+ mov [ebp+src], edx
.text:000227DD 89 8D 58 FF FF+ mov [ebp+var_A8], ecx
.text:000227E3 E8 54 22 FE FF call __ZnajRKSt9nothrow_t ; operator new[](uint,std::nothrow_t const&)
That's (count + 1) * 4, without any checking that will succeed. The attached testcase reaches this code on Symantec Scan Engine, I'm not sure which other products use this code.
(gdb) bt
#1 0x07e88816 in Attachment::setDataFromAttachment(Item&) () from definitions/Decomposer/libdec2tnef.so
#2 0x07e88abc in Attachment::setAttribute(Item&) () from definitions/Decomposer/libdec2tnef.so
#3 0x07e8a1b4 in TNEFObject::getAttachments(_IO_FILE*, MList&) () from definitions/Decomposer/libdec2tnef.so
#4 0x07e6c1d6 in CTNEFArchive::Open(char const*) () from definitions/Decomposer/libdec2tnef.so
#5 0x07e6ae5f in CTNEFEngine::OpenArchive(CTNEFArchive*, bool*) () from definitions/Decomposer/libdec2tnef.so
#6 0x07e6b8c0 in CTNEFEngine::Process(IDecomposerEx*, IDecContainerObjectEx*, IDecEventSink*, unsigned short*, char*, bool*, bool*) () from definitions/Decomposer/libdec2tnef.so
#7 0x063d07b5 in CDecomposer::DecProcess(IDecObject*, IDecEventSink*, IDecIOCB*, unsigned short*, char*) ()
#8 0x063d13cb in CDecomposer::Process(IDecObject*, IDecEventSink*, IDecIOCB*, unsigned short*, char*) ()
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40035.zip
