Be Careful of What You Embed: Demystifying

OLE Vulnerabilities
Yunpeng Tian†‡ , Feng Dong†‡ , Haoyi Liu† , Meng Xu§ , Zhiniang Peng†¶∗ , Zesen Ye¶ , Shenghui Li† ,
Xiapu Luo∥ , and Haoyu Wang†
† Huazhong University of Science and Technology∗∗ , § University of Waterloo
¶ Sangfor
Technologies Inc., ∥ The Hong Kong Polytechnic University
† {siontian, dongfeng, liuhaoyi, lishenghui, haoyuwang}@hust.edu.cn
§ [email protected], ¶ {jiushigujiu, whhhitc}@gmail.com, ∥ [email protected]

Abstract—Microsoft Office is a comprehensive suite of pro- first-party code and third-party code in processing the same
ductivity tools and Object Linking & Embedding (OLE) is a document. In fact, a multitude of exploits based on OLE
specification that standardizes the linking and embedding of a vulnerabilities have been disclosed over the past few years
diverse set of objects across different applications. OLE facilitates
data interchange and streamlines user experience when dealing with a vast majority leading to arbitrary code execution [1],
with composite documents (e.g., an embedded Excel sheet in a [2]. Unsurprisingly, such exploits have been harvested by
Word document). However, inherent security weaknesses within Advanced Persistent Threat (APT) groups for phishing and
the design of OLE present risks, as the design of OLE inherently single-click attacks [3].
blurs the trust boundary between first-party and third-party This paper is dedicated to the detection of vulnerabilities
code, which may lead to unintended library loading and parsing
vulnerabilities which could be exploited by malicious actors. in OLE objects—more specifically—embedded objects. To
Addressing this issue, this paper introduces OLExplore, a novel the best of our knowledge, this is the first academic work
tool designed for security assessment of Office OLE objects. With on analyzing OLE systematically for security weaknesses.
an in-depth examination of historical OLE vulnerabilities, we More importantly, we note that OLE could represent a typical
have identified three key categories of vulnerabilities and sub- architecture for large and complex software bundles with
jected them to dynamic analysis and verification. Our evaluation
of various Windows operating system versions has led to the extensible functionalities (e.g., Office or super-apps [4] such
discovery of 26 confirmed vulnerabilities, with 17 assigned CVE as WeChat and Alipay)—a type of software we call super
numbers that all have remote code execution potential. software (or superware for short). Therefore, we hope the
paper can provide a train of thought on finding bugs in closed-
I. I NTRODUCTION source superware through a practical case study on OLE.
Object Linking and Embedding (OLE), developed by Mi- Superware is characterized by its architecture which com-
crosoft, is a proprietary technology that facilitates the inclusion prises of a core host application for foundational operations
of a diverse set of objects within the same document. OLE and a potentially unbounded list of dynamically loadable
enables the creation of compound documents that host an modules for additional functionalities. While extensible and
array of data types, allowing an amalgamation of text, audio, agile, this architecture poses some alarming features that make
graphics, spreadsheets, and various other application elements superware vulnerable:
into a single cohesive unit. For instance, an Excel worksheet 1) Dynamic modules might be sourced from third-party
embedded in a Word document allows users to seamlessly providers, and yet, they are loaded into the same memory
edit the embedded data through an in-place activation within space shared with the host application (first-party) and other
the process group of the Word application itself instead of loadable modules.
launching the Excel application. 2) User input controls which dynamic module(s) to load. For
Despite its widespread usage, the design of OLE inherently example, a spreadsheet object in a Word document dictates
harbors vulnerabilities as it blurs the trust boundary between the Excel-related modules to be loaded.
‡ Both authors contributed equally to this research. 3) User input may include foreign content that can be serialized
* is the corresponding author. and deserialized by an external module only. The host
∗∗ Hubei Key Laboratory of Distributed System Security, Hubei Engi- application, on the other hand, conducts minimal checking
neering Research Center on Big Data Security, School of Cyber Science and on the foreign content due to lack of semantics.
Engineering, Huazhong University of Science and Technology.
All these characteristics blur the trust boundary between first-
party and third-party code in superware, which enlarges the
attack surface and exacerbates consequences of an exploit.
At the same time, they make user input for superware more
powerful (and more complex) than it appears. Essentially, a
Network and Distributed System Security (NDSS) Symposium 2025
24-28 February 2025, San Diego, CA, USA Word document is more like an interpreted script than just
ISBN 979-8-9894372-8-3 static data from a language-theoretic security perspective [5].
https://dx.doi.org/10.14722/ndss.2025.230547
www.ndss-symposium.org
 Recent years have witnessed an explosion of vulnerability • A misaligned feature that enables the loading and initial-
finding tools themed by fuzzing [6], [7], [8], [9], [10], sym- ization of OLE components without GUI interactions. This
bolic execution [11], [12], [13], and concolic execution [14], avoids the need for reverse engineering and simulating GUI
[15], [16], [12]; including tools tailored to the Windows interactions for each OLE component.
platform on which many programs are proprietary [17], [18], • A micro-snapshot fuzzer that can efficiently fuzz each OLE
[19], [20], [21], [22], [23], [24], [25]. However, the closed- component without reverse engineering the underlying input
source nature of superware like OLE rules out most tools that format required by each OLE component.
require source code (e.g., whitebox fuzzing). • A bug oracle that scrutinizes the module loading process
Greybox fuzzing, which does not strictly require source and memory operations, vigilantly searching for indications
code, is not very effective in the OLE case either. For of vulnerabilities. The spectrum of monitored vulnerabilities
example, WinAFL [24], paired with DynamoRio [26], has is meticulously curated, informed by the OLE attack surface
been successful in fuzzing Windows binaries. However, it en- and a compendium of historical CVE records.
counters significant difficulties in handling complex software • A vulnerability analyzer that assesses the severity of iden-
like Office, for at least two reasons: 1) For formats that are tified vulnerabilities reported by the bug oracle. We use
highly structured, blob mutation is often less effective, and a disguised RTF as the carrier for malicious attacks and
most random inputs fail at the sanity checking phase; and bypass the Protected View Mode [31] by a separate crash-
2) DynamoRio’s support on applications with graphical user inducing bug. This is a weaponization technique that has
interfaces is limited. not been previously disclosed to the public.
Extracting entry points via reverse engineering is possible While the design principle of OLE XPLORE is universal, as
but impractical facing hundreds or potentially thousands of detailed discussions in Section VI will show, porting it to other
OLEs available on the Windows system. Furthermore, each superware (e.g., Alipay or WeChat) still requires manual and
OLE is unique in its data processing logic. Effective fuzzing of even reverse engineering efforts, including:
an OLE module requires an extensive reverse engineering on • Identifying a feature that triggers the loading and execution
its input format—another scalability blocker. As a result, prior of loadable modules without GUI.
fuzzing effort on Office has largely focused on file mutation • Identifying the input-consuming function used for chunk-
and generation [27], [28], [29] for the host application and by-chunk input processing (for micro-snapshot fuzzing).
less on the loadable OLE modules. The bug oracle developed in OLE XPLORE can be reused
Zooming out with an abstraction, the reasons why OLE- across different superwares, as the principles of scrutinizing
related vulnerabilities are hard to find with conventional tools the module loading process and memory operations, and
might also apply to other superware. In particular: vigilantly searching for indications of vulnerabilities, are
1) The potentially unbounded list of loadable module candi- commonly applicable in these large software systems. This
dates implies that static analysis techniques are inherently facilitates some level of automation, reducing the need for
prone to incompleteness in code discovery. extensive manual customization.
2) Naive fuzzing via random mutation of the entire user input Summary. OLE XPLORE makes the following contributions:
(e.g., an entire .docx file) is futile while structured or type- • We conducted an exhaustive survey on all publicly disclosed
aware fuzzing [25] requires detailed specifications of input OLE-related vulnerabilities and delved into the fundamental
format which are complex and hard to reverse engineer. causes of these flaws. Building on the outcomes of our
3) Loadable modules can be difficult to isolate for execution investigation, we identified current attack surfaces for OLE
(e.g., fuzzing with harness [30]), as running a loadable mod- and employed three vulnerability patterns to evaluate the
ule typically requires an integrated environment, including exploitability of OLE (Section III).
the host application and potentially other modules. 1
• We developed OLE XPLORE , a pioneering tool for system-
4) Other complications of superware, such as the closed- atic vulnerability detection in OLE components. Novel tech-
source nature and scarcity of internal documentation further niques proposed in OLE XPLORE include 1) GUI-interaction
amplify the difficulty of conducting thorough analyses. bypassing, 2) micro-snapshot fuzzing, and 3) a vulnerability
The significance of these challenges is exemplified by Office weaponization technique to bypass Office Protected View
and OLE. Hence, investigating security weaknesses via the Mode. We have privately disclosed the weaponization tech-
lens of OLE serves as a case study for how to find vulnera- nique to Microsoft and this paper marks the first public
bilities practically and systematically in superware. disclosure of these exploits (Section IV).
Overview of OLE XPLORE. OLE XPLORE is our attempt to • We systematically analyzed all registered COM components
find OLE-related vulnerabilities systematically. OLE XPLORE (a superset of OLE components) in popular Windows plat-
consists of five components: forms, identified 257 OLE components, and reported 26
• A high-level input layout that loosely maps regions in bugs. Out of those, 17 vulnerabilities have been assigned
user input to their handlers (e.g., the host application or
dynamically loaded modules). Obtaining this layout requires 1 We open source OLE XPLORE at https://github.com/WinSysSec/OLExplore
a modest degree of reverse engineering on Office. to facilitate the research in this area.

2
 A
In-process OLE is an OLE component that executes in the
same process as the host application. In-process OLE can be
B
OLE Component
COM Components Interfaces
initialized through ole32!OleLoad().
C
Separated-process OLE is an OLE component that executes
COM Component
D in a separate and standalone process. Separated-process OLE
are instantiated by ole32!OleRun().
Within OLE, objects are primarily categorized into two
IUnkown types: embedded objects and linked objects. Embedded objects
IOleObject are self-contained objects with all related information stored
OLE Components
IPersistStorage
Interfaces in the host document. For instance, users can use the “Insert
OLE components are COM components that expose
specific interfaces: Object” feature to embed a Word document (with all of its
lPersistStorage, OIeObject ......
content) directly into an Excel worksheet [32]. With this,
users can view and edit the Word document without opening
Fig. 1: OLE components are special COM components the Word application. Conversely, a linked object references
an object located in a different file or application. The OLE
CVE numbers, each with the potential of Remote Code object in the host document simply maintains a link rather
Execution (Section V). than enclosing the complete data. As a result, updates to the
We hope OLE XPLORE can be inspirational for finding original object are reflected in the linked object accordingly.
vulnerabilities in other superware and we endeavor to enhance This paper focuses on in-process embedded objects which
the understanding and discovery of potential security gaps in draw most of the security concerns (Appendix A).
complex software built upon dynamic library integration.
B. How OLE Works
II. BACKGROUND
In this section, we present background information about
OLE and illustrate OLE vulnerabilities with a real-world case.
doc
Step 1
A. Basics of OLE
OLE object extracted
document containing CLSID extracted
from doc (e.g. OLE of
This paper focuses on OLE 2.0, the currently in-use version. OLE object
a button)
from OLE object

At its core, OLE 2.0 is built on the Component Object Model

(COM) and structured storage, and OLE objects are essentially
COM objects that can be embedded or linked to existing
documents. Figure 1 shows the relationship between OLE and DLL

COM. The vision for OLE, and more fundamentally COM, Step 2
OLE
Component initialized
is to enable software developers to create more streamlined CLSID extracted
from OLE object
Office Application (e.g.
Word)
by Office with CLSID
(e.g. DLL handling the
and focused applications. Should developers opt to extend button )

services beyond core functionalities, such add-ons could be

implemented as separate modules which can be loaded into
memory only when required.
DLL
1) COM interfaces: As COM components, all OLE com- Step 3
OLE Component
ponents expose the IUnknown interface, which facilitates its OLE object extracted
from doc (e.g. OLE of
Office Application (e.g. deserialize OLE object
Word) from structured storage
clients in discovering other interface pointers, including those a button) (e.g. DLL handling the
button )
offering specific OLE functionalities such as IOleObject,
IOleLink, and IViewObject2. Fig. 2: Loading process of OLE objects with Office
2) Structured storage: All OLE components implement the
IPersistStorage interface for state persistence and option- As shown in Figure 2, loading an OLE object within
ally IPersistStream. IPersistStorage defines standard Microsoft Office involves a series of interactions between
methods for persisting object states to external storage in a way various entities, out of which three are especially relevant here.
that is agnostic to any specific storage backend. The counter- Step 1: Retrieve the CLSID from the document. In this
part, i.e., the host application that processes documents with phase, the host application extracts a class identifier (CLSID)
OLE objects embedded, must hence provide the IStorage from the document to determine which OLE module needs
interface to enable object data storage and retrieval. The format to be dynamically loaded and initialized. CLSIDs can be
and semantics of persisted data, however, is completely oblivi- embedded in a wide range of document formats, including:
ous to the host application. As different OLE components offer • Office binary formats (e.g., .doc, .xls, .ppt, .pps, etc.)
different implementations for IPersistStorage, the format • Office OpenXML formats (e.g., .docx, .xlsx, .pptx, etc.)
of data persisted in the storage also varies significantly. • RTF format (.rtf)
Furthermore, based on how an OLE object is hosted at The mechanisms for locating the embedded CLSIDs differ
runtime, OLE can be further categorized into two types: by file format. Taking the OpenXML format as an example,

3
the embedded CLSIDs reside in a form named OLESSFormat Structured storage addresses the problem of storing hetero-
stored within the root directory entry, which can be inspected geneous data objects within a single file in a way that is
and extracted using the OffVis tool [33]. transparent to the code (e.g., both the host application and
Step 2: Invoke CoCreateInstance to load the mod- OLE DLLs) that operates on these data objects.
ule. Creating an OLE object in the current execution con- More specifically, structured storage introduces an abstrac-
text requires initializing the OLE module first via the tion named “stream”, realized through the IStream interface,
CoCreateInstance function. This process involves loading and resembles traditional files which provide read and write
the DLL associated with the CLSID into the current process. methods. Enclosing streams are an abstraction named “stor-
The Registry holds a mapping between CLSID to its corre- age”, described by the IStorage interface, and is analogous
sponding DLL under the key HKEY_CLASSES_ROOT\CLSID, to directories in a filesystem. Naturally, a storage can contain
which ensures that the system can accurately identify and load both streams and more storages.
the requested DLL to unblock subsequent operations. After A compound document amalgamates a diverse set of data
the DLL is loaded, CoCreateInstance not only ensures types such as text, graphics, spreadsheets, audio, and video, all
the module is in memory but also triggers the execution of of which are embedded within the document as independent
initialization code. Then, a designated entry function within and self-contained objects. To persist multiple objects into a
the loaded DLL is invoked to complete the setup process. single file, one can open an IStorage representing the file’s
Step 3: Invoke IPersistStorage::Load to deserialize content and save each object in a separate IStream. Figure 3
the OLE object. The IPersistStorage interface includes shows a sketch of the scheme of storing OLE objects in a
several methods, among which Save and Load are the most compound document file. While the host application is re-
critical, as they are responsible for serializing and deserial- sponsible for managing the root-level IStorage, the specifics
izing the persistent states of an object, respectively. Once of how to read and write an IStream are delegated to each
the DLL for an OLE object is ready, the DLL invokes the OLE DLL which is typically encoded in the implementation
IPersistStorage::Load method to deserialize an OLE of the IPersistStream interface. Given the varied imple-
object from the structured storage. The Load function takes an mentations of IPersistStream by different OLE DLLs, the
IStorage *pStg argument—a pointer to the actual location data formats vary significantly, and fuzz testing these formats
of the OLE storage within the document—supplied by the host generally requires manual reverse engineering of the inner
application. Since any data embedded in the document can be structure of each IStream to build a harness.
subject to attackers’ control, corrupted OLE storage serves
as the primary way to carry out exploits (such as memory III. OLE ATTACK V ECTORS
corruption and logical errors). In this section, we categorize OLE vulnerabilities based on
a comprehensive review of all known OLE-related CVEs. In
C. OLE Structured Storage particular, we surveyed 21 OLE-related CVEs and discovered
that they can be classified into three types. Combined, these
Compound File OLE-related CVEs account for 43.23% of CVEs targeting
Office (see Appendix A for more details).
DIFAT Array Directory Entry Array

FAT Array Root Directory Entry A. Type-1: Loading a COM Component Not Intended for OLE
Directory Entry Array Storage Directory Entry Type-1 CVEs account for 3 out of the 21 surveyed CVEs.
( Root Storage )
In Office, a CLSID serves as an index for the OLE com-
Mini FAT Array Stream Directory Entry ponent that a user wishes to initialize. Upon recognizing
a CLSID in the input document, the host application calls
CoCreateInstance to load the corresponding DLL and
Storage Root Storage trigger certain initialization functions. During this process,
CLSID Storage 1 memory is allocated, and the corresponding objects are in-
stantiated.
Stream A Storage 1
However, not all components associated with a CLSID are
Stream B Storage 2 OLE components. With thousands of CLSIDs existing in the
system, only a subset corresponds to actual OLE components.
...
This means that some COM components not intended for use
Stream Stream 1 in Office might still be loaded as OLE components. While
Flag Stream 2
Office already performs a series of complicated checks before
(linked/embedded object within)
loading a COM component to ensure it is intended for OLE,
User-defined data ... our evaluation shows that existing checks are inadequate. Fur-
thermore, if an unintended COM component fails to initialize
Fig. 3: A sketch of the format of a compound document with its memory appropriately and fails to report exceptions, it can
OLE objects embedded expose vulnerabilities such as uninitialized read.

4
 Attacks based on LoadLibrary. The following out-
1 CoCreateInstance ( lines the DLL search order for LoadLibrary and
2 rclsid =
,→ {CDDBCC7C-BE18-4A58-9CBF-D62A012272CE}, LoadLibraryEx, two commonly used functions for dynamic
3 pUnkOuter = NULL, DLL loading:
4 dwClsContext = CLSCTX_INPROC_SERVER | 1) The directory from which the application loaded
,→ CLSCTX_INPROC_HANDLER, 2) The system directory
5 riid =
,→ {00000000-0000-0000-C000-000000000046},
3) The 16-bit system directory
6 ppv = lpTargetPpv 4) The Windows directory
7 ) 5) The current working directory
6) The directories listed in the PATH environment variable
Fig. 4: In CVE-2015-1770, a COM instance is created by Attacks based on SearchPath. There are comparable risks
calling CoCreateInstance. when programs use the SearchPath API to locate and dy-
namically load a DLL from a path returned by SearchPath.
In summary, a Type-1 vulnerability can be triggered by 1) The following exemplifies the default search order of the
placing a non-OLE CLSID in the input document, 2) utilizing SearchPath API:
the content succeeding objdata within the RTF trigger, as • An OLE component attempts to load xxx.dll from the
delineated in Section IV-B, to populate the storage for objects current directory.
of this particular CLSID type, and 3) loading the document • An Office application, such as Word, not only searches for
which might automatically trigger CoCreateInstance to run xxx.dll in the current directory but also loads the DLL
to load and initialize the fictitious “OLE” component. into the Word process. An attacker could exploit this step
CVE-2015-1770 is a typical example of Type-1 vulnera- by inserting a malicious DLL containing a command to run
bility. The root cause of this CVE stems from the improper arbitrary code, thereby accomplishing the attack.
initialization of the COM component OSF.DLL. Despite hav- The Windows operating system exhibits a design vulnera-
ing a CLSID, OSF.DLL is actually not architecturally intended bility during the initialization of OLE components, wherein
to function as a loadable OLE component. More specifically, the loaded DLLs are not authenticated, stemming from a
CoCreateInstance on this component (identified by the specific process analyzed from an attacker’s perspective. An
rclsid argument as shown in Figure 4) crashes unexpectedly OLE object is a subset of COM objects, which are collections
with page-heap enabled. The crash can be traced back to the of objects associated with CLSIDs and registered within the
interface pointer lpTargetPpv, which is obtained during the operating system.
incorrect process of loading OSF.DLL as an OLE component. In certain instances, even if a DLL possesses an associated
Reverse engineering reveals that the pointer lpTargetPpv CLSID in the registry, it may not be a legitimate COM com-
is a 184-byte object created and partially initialized ponent. Despite this, CoCreateInstance continues to load
by two subroutines: PpvPartOneInitialization such DLLs with CLSIDs into the process, without considering
and PpvPartTwoInitialization. At offset 0x54, whether the DLL is genuinely related to OLE. Our primary
it contains a pointer (lpTargetPpv->pUnkObj) concern herein lies with DLL preloading attacks. Given the
to another 116-byte object, allocated and partially significant variation in component installation across different
initialized by PpvOffset54UnkObjAllocAndInit and Windows versions, some, such as Windows Server, do not
PpvOffset54UnkObjInit. A field at offset 0x58 within come with certain system functional components pre-installed.
this new object remains uninitialized, causing a crash under As a result, on these variants, even if a CLSID exists, the
PageHeap when accessed. corresponding DLL may not, leading to path searching for the
B. Type-2: DLL Preloading Attacks DLL. At this juncture, should an attacker provide a malicious
DLL in the anticipated path, it would be loaded, and the
Type-2 CVEs account for 11 out of the 21 surveyed CVEs. malicious behavior executed. This reality constitutes a design
When the CoCreateInstance function is called, if there is a flaw during the initialization of OLE objects in Windows.
DLL associated with the specified CLSID, the LoadLibrary
function will be invoked. If the DLL is requested while the C. Type-3: OLE Data Parsing Error in IPersistStorage
Registry does not hold a complete path for the DLL, Windows Type-3 CVEs account for 7 out of the 21 surveyed CVEs.
searches for the required library according to a predefined Data parsing is always a hotspot of vulnerabilities. As the
sequence of directories (i.e., DLL search order). An attacker input data is inherently untrusted and maliciously crafted data
who gains control over any one of these directories can force can cause both memory errors and logic bugs. An analysis
the program to load a malicious DLL, thus supplanting the of disclosed CVEs reveals that a majority of vulnerabilities
legitimate DLL that should have been loaded. This is typically related to OLE are closely related to the implementation of
known as DLL preloading attack, and represents a pervasive IPersistStorage::Load, which is responsible for loading
security issue for all platforms that support dynamic library objects stored within the storage section in the input document.
loading. Exploiting this vulnerability, an attacker can execute Typically, data in the storage section is in binary format.
arbitrary code in the host application’s privileges [34]. Moreover, the storage format for each OLE component varies

5
and the format is within total control of the associated OLE
itself. Due to its proprietary and intricate nature, binary storage 1 2

might accidentally conceal security exploits (i.e., security

through obscurity). Attackers can exploit specially crafted RTF
binary storage to trigger specific vulnerabilities and execute
attacks. Consequently, systems must enforce stringent data Spam email with .docx .docx documents
attachment drops RTF file
validation and security checks when handling storage data
from untrusted sources to mitigate threats.
It is noteworthy that storage data originates from the 3 4
IStorage parameter of function IPersistStorage. Since
code executing the IPersistStorage interface resides
HTA
within OLE components, how IStorage is handled depends
on the OLE object itself. Storage data is embedded within RTF file exploits
HTA file retrieves Loki
document files, meaning that this parameter can be influenced CVE-2017-11882 and
drops an HTA file
by external factors. However, an attacker may tamper with the
storage data contained in the OLE objects within a document.
When Office suites act as OLE containers processing docu- Fig. 5: A real-world exploitation.
ments containing OLE objects, they load the corresponding containers like Office or WordPad primarily read the CLSID
OLE components and invoke the Load() method of the to initialize an OLE component. Subsequently, storage data is
OLE component’s IPersistStorage interface to parse the extracted from the OLE object embedded within the document
storage data and initialize the object’s initial state. During this and transmitted to the OLE component for subsequent pro-
initialization, the data source remains unverified, thus in a cessing. This delineates the fundamental difference between
potentially untrustworthy state, harboring latent security risks. Type-1 and Type-3 vulnerabilities.
CVE-2017-11882 [35] is a notorious vulnerability related
to OLE. The underlying mechanics of this vulnerability are IV. OLE XPLORE : S YSTEMATIC B UG F INDING FOR OLE
not only straightforward but also robust, enabling exploitation Figure 6 outlines the workflow of OLE XPLORE. The pri-
without user interaction or detection. Several APT groups mary objective of this tool is to facilitate the efficient and
have added this vulnerability into their arsenal, extensively accurate detection of OLE-related vulnerabilities. Our system
utilizing it in spear-phishing and watering hole attacks [36]. functions in the following main steps:
This vulnerability resides within the Equation Editor module Phase 1: Analyzing OLE components. Initially, OLE X -
EQNEDT32.exe, which was originally developed by Design PLORE identifies all CLSIDs present on the system It then
Science Inc., compiled in 2000, and later maintained by enumerates the interfaces and properties exposed by each
Microsoft. Regrettably, Microsoft did not prioritize security COM component to filter and identify OLE components,
for this module, resulting in the flaw going undetected for acquiring their pertinent information.
17 years. When inserting or editing equations in Office Phase 2: Constructing an OLE runtime. OLE XPLORE uses
documents, the host application invokes the EQNEDT32.exe a GUI-free RTF-based input template to trigger various OLE
process via RPC to handle equation parsing and editing. components. Upon encountering this trigger, Office will pro-
Although Office versions post-2007 replaced EQNEDT32.exe ceed to load the corresponding DLLs, thereby bypassing the
with a built-in equation editor, all versions of Microsoft Office need for GUI interaction and fostering the construction of an
(including Office 365) still support formulas initially created environment conducive to the instantiation of OLE objects
with EQNEDT32.exe for backward compatibility. within the system.
The vulnerability manifests during the processing of Equa- Phase 3: Fuzz OLE-specific storage segment. During this
tion Native data streams, often containing MathType formulas phase, for recognized formats, OLE XPLORE utilizes ActiveX
provided by the document. When parsing the font name, the to generate the corresponding storage. In the case of unrecog-
length of the name within the stream lacks proper validation, nized formats, OLE XPLORE employs micro-snapshot fuzzing,
leading to a stack overflow. An attacker could exploit this by a technique that enables efficient fuzz testing of each OLE
crafting data to overwrite the function return address, hijacking component independently, thus obviating the need for reverse
the control flow of the application. Within the described engineering the specific input format each OLE component
overflow, after the return address has been overwritten, the necessitates.
contents of the string are transformed in the _strupr function Phase 4: Behavior Detection. Utilizing the established test-
whereby, following subtraction of 0x20 from the code, the ing framework, batch tests are conducted and abnormal events
return address is changed to the address of WinExec, thereby such as DLL loading behavior as well as memory corruption
achieving the invocation of WinExec. Figure 5 outlines a crash are monitored and logged using Process Monitor [37].
typical case of exploitation. Phase 5: Vulnerability Analysis. The analysis stage involves
Although both the CLSID and storage data can be supplied dissecting crash-captured dump files and validating vulnerabil-
by an attacker, there is a distinction in how they are used. OLE ity exploitability through constructed proof-of-concept (PoC)

6
 OLEXPLORE: Auto Detection Framework

Registry CLSID CExposedStream::Read Hook No Exception PoC

Enum
IOleObject
Interface
Load DLL Conceal format disguising
ActiveX control
Type1/3
remote shared
Crash directory
Delivery
Mutation compressed archive
RTF PoC Synthesis
Bypass Denial-of-Service
COM
Components OLE Data RTF Triger Office Sliced Input Type2 DLL load

➊ Analyzing OLE ➋ Constructing OLE Runtime ➌ Micro-snapshot Fuzz ➍ Behavior Detection ➎ Vulnerability Analysis

Fig. 6: Overview of OLE XPLORE

exploits. We employed a novel and not yet fully disclosed

method of vulnerability weaponization to assess the severity 1 {\rtf1
2 {\object\objemb{\*\objclass None}
of the vulnerabilities discovered. 3 {\*\oleclsid\
4 '7b00000000-0000-0000-0000-000000000000\'7d}
A. Collecting OLE Components
5 {\*\objdata
OLE XPLORE collects registered COM components from ,→ 01050000010000000100000000000000000000000
Windows registry key HKEY_CLASSES_ROOT\CLSID by 6 0000000000000000000000000000
crawling unique CLSID identifiers and subsequently retrieve 7 000000000000000000000}}}
the filesystem location(s) of the associated DLL file by reading
the InprocServer32 and LocalServer32 sub-keys. Fig. 7: An example of an RTF document that triggers the
As introduced in Section II-A, OLE components are a subset loading of an OLE object without requiring user interaction
of COM components. Specifically, a COM component may be
classified as an OLE if it implements the IOleObject inter- It is not feasible to manually run the GUI interactions for all
face. To ascertain whether a given COM component is an OLE OLE components found by OLE XPLORE, which is at the scale
component, one can systematically instantiate objects using of hundreds of not thousands.
the list of collected CLSIDs and then enumerate each COM To avoid GUI interactions in automated OLE component
component’s exposed interfaces and properties to determine initialization, OLE XPLORE exploits a “feature-not-bug” in the
the implementation of the IOleObject interface. current Office implementation. As reported by Steven Vittitoe
The COM interfaces are declared using Microsoft Inter- in 2015 [40], the opening of the RTF document shown in
face Definition Language (MIDL). PowerShell provides a Figure 7 results in the loading of OLE objects without user
Get-Member cmdlet [38] to list the interfaces and properties interaction. This issue was reported to Microsoft in 2016 [41],
of a component. Upon confirming that the COM component but Microsoft did not recognize it as a vulnerability. In
offers the IOleObject interface, OLE XPLORE utilizes Ole- contrast, when an OLE-embedded .docx file is opened, Office
ViewDotNet [39] to decompile the interface from the binary issues a warning prior to the activation of the object. For in-
file and export the declaration. stance, Office 2016 emits a warning when opening a .docx file
containing an OLE object. However, when the identical .docx
B. Constructing an OLE Runtime Environment
file is saved in RTF format and later opened with Office 2016,
After collecting all OLE components available in the sys- no prompt appears for the embedded OLE object. This RTF
tem, OLE XPLORE needs to construct a runtime environment template serves as a highly customizable base case because
for each OLE component. To identify Type-1 and Type-2 it provides a way to load and initialize an OLE component
vulnerabilities (i.e., those can manifest upon invoking the without manual interaction. We use the RTF loading trick to
CoCreateInstance function), it is imperative to ask the host avoid graphical interactions and reduce performance overhead.
application to instantiate each OLE object, during which the Using an AutoIT script requires waiting for Office to fully
host application will invoke the CoCreateInstance function. initialize, including various UI windows. With PageHeap, this
Unfortunately, the conventional way of loading an OLE UI initialization becomes very slow. In contrast, RTF files
component requires non-trivial GUI interactions (1) such as bypass the UI constraints and can trigger OLE parsing without
clicking on the Insert tab, (2) clicking on Object, (3) needing full initialization.
browsing to the OLE file, and (4) clicking OK to confirm2 . We produced RTFs for every OLE component found in the
2 See this Microsoft Office help manual (https://support.microsoft.com/en-
system. The structure of the framework is straightforward; it
us/office/embed-or-link-to-a-file-in-word-8d1a0ffd-956d-4368-887c- merely requires the creation of an RTF document with an
b374237b8d3a) for details on loading an OLE object. embedded CLSID that resides in the system registry. This

7
approach circumvents the necessity to reverse-engineer the In OLE XPLORE, we develop a new technique, micro-
GUI interfaces and the initialization functions within the OLE snapshot fuzzing (see details in Section IV-D), to achieve
component. It simulates user interactions such as opening and better mutation efficiency than the plain blob mutation without
closing the document, as well as actions akin to clicking or reverse engineering effort on the OLE DLLs. Micro-snapshot
double-clicking on the OLE object. This simulation facilitates fuzzing, as the name suggests, is inspired by snapshot fuzzing
the loading of the OLE object by Office, alongside the as- which has been proven effective in stateful systems such as
sociated DLLs, thus triggering the OLE-specific initialization network protocols [46] and operating system kernels [47]. In
functions required for assembling and establishing the OLE fuzzing stateful systems, the fuzzer takes a snapshot whenever
runtime environment. an input event (e.g., one network message or one syscall)
discovers new coverage. The snapshot inherently encompasses
C. Testing An OLE Component by Mutating Storage Data all previous events that lead the system to the current state,
and allows the state to be further advanced into different
Testing the IPersistStorage interface requires storage possibilities when resumed and fed with different new events.
data. However, gathering a relevant corpus presents consider-
able challenges due to the lack of previous research or public D. Micro-snapshot Fuzzing
effort on this matter. In OLE XPLORE, for OLE components
Micro-snapshot fuzzing in OLE XPLORE divides the input
with matching ActiveX plugins, we utilize ActiveX to directly
blob (which is of an unknown format) into chunks where
generate storage data. For other OLE components with un-
each chunk corresponds to an event in snapshot fuzzing.
known and customized storage formats, we employ micro-
This is achieved with the following observation on how OLE
snapshot fuzzing to automatically probe an input format.
components process input from storage.
1) ActiveX-based input generation: To build an initial cor-
• Input reading only occurs via one standard interface:
pus for known storage formats, we developed 74 kinds of
ActiveX controls (e.g., the CheckBox Control with CLSID: CExposedStream::Read(
8BD21D40-EC42-11CE-9E0D-00AA006002F3 is related to – stream_to_read,
the module FM20.DLL). ActiveX controls, which are built on – receiving_buffer,
a foundation of many lower-level objects and interfaces in – number_of_bytes_to_read,
OLE [42], are a type of OLE object that can be embedded – number_of_bytes_actually_read)
within documents such as Word or Excel files to provide (abbreviated as S::Read subsequently).
interactive functionality. • Input is processed chunk-by-chunk, and each chunk is
These ActiveX controls exhibit a variety of attributes, such relatively small in size (compared with the size of the
as Font and Caption, which are persistently stored within input stream)
a designated storage structure. Office provides a suite of • Input chunks are read sequentially and the OLE never
developer tools designed for the rapid creation of various re-reads a chunk.
ActiveX controls. By specifying the creation of controls such With these observations, we note that one chunk of input
as “Text Box” or “Button” classes, we ensured that these stream is akin to one message in a network protocol or
controls contain unique storage formats related to their OLE one syscall to the kernel. If one chunk of input yields new
components. Once generated, the ActiveX controls are encap- coverage, we can take a snapshot of the current process and
sulated within .docx documents. By decompressing these save it to the seed pool; in future fuzzing rounds, if this seed is
documents, we can retrieve the corresponding binary files. selected as base of mutation, the snapshot will be restored first
We generated batches of controls for different classes and and we focus on mutating the next chunk to further advance
randomly assigned properties to them in order to extract the the state. However, different from snapshot fuzzing which
storage data. This method allowed us to create a diverse and actually snapshot the system state (e.g., a VM snapshot in
comprehensive dataset of storage formats, which is essential kernel fuzzing), the snapshot in OLE XPLORE is simply an
for thorough testing and analysis of OLE object vulnerabilities. accumulation of input chunks that lead the execution of an
2) Micro-snapshot fuzzing: For OLE components that take OLE component into its current state. This is feasible because
unknown formats of storage and do not have ActiveX control OLE components do not involve multi-threading in processing
support, a naive solution would be to treat the entire input the inputs, hence, a deterministic sequence of events will lead
stream as a blob and apply random mutations on the blob (e.g., to a deterministic state.
basic techniques in AFL++ [8]). However, for formats that are And yet, one question remains: how to break the input
highly structured, blob mutation is often less effective, and stream into chunks? Reverse engineering the format of the
most random inputs fail at the sanity-checking phase. The ideal input stream naturally reveals the chunks but is not scalable. In
solution would be to reverse engineer the input formats and OLE XPLORE, the chunk boundaries are decided by the OLE
use grammar-based input generation or mutation to generate code logic and are passively collected by OLE XPLORE.
near-correct inputs [43] [44] [45]. However, this is not feasible To be more specific, every time S::Read is invoked,
facing hundreds if not thousands of OLE components that are OLE XPLORE identifies an input chunk by the amount of bytes
close-sourced with little to no public documentation. read. The second parameter of S::Read is a buffer pointer

8
designated for storing the data that is read; the third parameter tours [48] (which monitors and instruments API calls on Win-
dictates the volume of data to be read; and the final parameter dows platforms). The fuzzer monitors the DLL execution until
is an integer pointer that yields the actual number of bytes the next read is encountered. If new coverage is discovered
that have been read. For example, S::Read(_, _, 20, _) between the last read and the upcoming read, a snapshot is
marks a 20-byte chunk; while S::Read(_, _, 36, _) taken. The next mutation will start from a snapshot. In other
marks a 36-byte chunk. words, a snapshot is a seed (in fuzzing terms) in the seed pool.
Snapshots are taken right before the invocation of S::Read Effectively, a snapshot encompasses all chunks (in raw
if new coverage is discovered between the last S::Read bytes) that are previously read via CExposedStream::Read
and the upcoming S::Read. To illustrate the micro-snapshot by the OLE component. Therefore, replaying these chunks
fuzzing process in OLE XPLORE, essentially replays a prefix of the execution path in the DLL
1) select seed s as mutation base from seed pool, s is essen- (modulo concurrency) and fuzzing continues based on this
tially a snapshot of sequence [S::Read(_, _, 8, _), prefix. It is worth noting that while concurrency is heavily
S::Read(_, _, 16, _), S::Read(_, _, 12, _)] used in Office, parsing the storage for a single OLE object is,
2) after resuming s, the next chunk is marked by in fact, entirely sequential in our tested modules. Therefore,
S::Read(_, _, 20, _), so OLE XPLORE will gener- micro-snapshot fuzzing in OLE XPLORE is designed with the
ate and mutate 20-byte chunks (e1 , e2 , . . ., ek ) and feed implicit assumption that input chunks are read and processed
to the resumed snapshot. sequentially. Each chunk of raw bytes is either generated
3) for each new event ei , OLE XPLORE will monitor its or mutated randomly due to the lack of type or structural
execution until the execution hits the next Read. If new information.
coverage is discovered, OLE XPLORE will save s++ei as To measure and track coverage of code executing during
a new seed in the seed pool. fuzzing, the dynamically loaded DLL is instrumented with
Furthermore, OLE XPLORE follows a systematic exploration TinyInst [49]–a binary rewriter–when loaded. TinyInst recog-
of the input stream which is inductive in nature. More specif- nizes basic blocks in the instruction sequence, and we hook
ically: the first instruction of every basic block for coverage tracking.
Taking CVE-2017-11882—a vulnerability discovered
• Base case: probe for one-chunk snapshots (by mutating
within the IPersistStorage::Load function—as a
the chunk marked by the first S::Read).
case study, our tool OLE XPLORE monitors the affected
• Induction case: for each k-chunk snapshot:
EQNEDT32.exe process. Within this vulnerable function, read
1) resume the snapshot operations are intercepted through hook functions specific
2) produce (with randomness) the (k + 1)-th chunk to S::Read. The crux of the vulnerability lies in handling
3) check whether the (k + 1)-th chunk yields new cover- Equation Native Stream Data within the document. The
age, if so, save it as (k + 1)-chunk snapshot program reads two structures in two phases: EQNOLEFILEHDR
and MTEFData (Equation Native Stream Data consists of
OLE Storage Content
EQNOLEFILEHDR and MTEFData). In processing MTEFData,
IPersistStorage::Load()
it invokes a subroutine to iteratively read the constituent
Read some bytes c) Hook record sub-structures, with field values dictating the function’s
Mutation
ole32!CExposedStream Module execution path.
::Read Initially, 8 bytes of data are read—which corresponds to
Validate b)

Read some bytes

Coverage-oriented
mutation of read bytes
the first 8 bytes of the Contents data block onto the stack
a) Mutation
via S::Read. Subsequently, the program validates the read
Validate
data to ensure a match against specific data patterns, such
Read some bytes
as 0x12344321 and 0x08. Upon successful validation, the
Mutation Feedback remainder of the Contents data block is read; otherwise, the
Validate Explore deeper path process is terminated. Importantly, the data retrieval is not
through:
performed in a single operation but in batches, coupled with
...... READ COUNT
validation steps. A batch only proceeds with additional reads
READ LENGTH
if its data passes validation until all data is processed.
Early return / Load complete EIP

E. Behavior Detection
a) Repeated reading and checking during OLE storage retrieval.
b) Terminate reading if byte check fails.
c) Retrieving storage for the OLE component ultimately entails calling ole32!CExposedStream::Read. When the CoCreateInstance function is invoked in the
Fig. 8: Illustration of micro-snapshot fuzzing instantiation process of an OLE object, the system may load
additional DLLs. To capture unintended DLL loading events,
Implementation details — Figure 8 demonstrates OL- we utilized the Process Monitor [37]—a widely applied API
E XPLORE’s micro-snapshot fuzzing workflow for the mod- behavior monitoring software on the Windows platform.
ule under testing. In the testing process, the fuzzer tracks Through monitoring the CreateFile API, it is possible
CExposedStream::Read (i.e., raw bytes read) using De- to detect whether any DLL file is being created or opened.

9
Should there be activity involving a DLL file at such time, code execution for malevolent purposes while the remaining
OLE XPLORE performs a scan of its function call stack in ones can lead to at least DoS attacks. After being meticulously
search of the LoadLibraryEx API. The purpose behind crafted, these vulnerabilities could be exploited with just one
searching for this API lies in the fact that the presence of click, allowing malicious code or DLLs to execute impercep-
LoadLibraryEx within the call stack of the DLL signifies tibly, posing a significant threat. The complete exploitation
that the DLL has been dynamically loaded by the process. process comprises three sequential stages: 1) disguising the
By employing the following filtering strategies, all DLL RTF document as an alternate file format, 2) delivering a
loading activities are meticulously captured and displayed. malicious DLL in a stealthy manner, and 3) bypassing the
For DLLs that do not exist within the system, our approach Protected View Mode [31] to allow OLE content to be loaded
involves monitoring instances where search results include by Office applications.
the phrase not found. In exploitation scenarios analyzed, it We use the Word application (i.e., Winword.exe) with Pro-
has been observed that counterfeit DLL files can be loaded tected View Mode to conduct our tests. Protected View Mode
successfully without requiring any export functions. Notably, feature is the well-known yellow bar with an “Enable Editing”
these incidents of successful DLL loading precede any internal button in MS Office. In Protected View mode, features that
errors that may occur within the process thereafter. For DLLs may pose security or privacy risks are disabled. This includes
that are present within the system, OLE XPLORE examines ActiveX controls, Object Linking and Embedding, macros, and
them to identify externally accessible export functions. The loading of remote resources. Protected View Mode only is en-
export table enumerates every function the DLL offers to abled when Word, Excel or PowerPoint opens documents with
other executables—these serve as the DLL’s entry points; only the Mark-of-the-Web (MOTW) [52]. We provide a detailed
functions in this export table are available to other executable description of the process of weaponizing vulnerabilities in
files. All other functions not listed remain encapsulated within Appendix B.
the DLL, inaccessible from outside. To validate the security
measures in place, OLE XPLORE creates a facsimile DLL, V. E VALUATION
replicating both the file name and exported function names In this section, we evaluate OLE XPLORE by analyzing
from the original. It then places this mock-DLL into a di- all registered COM and OLE components within Windows
rectory of higher priority to test whether it supersedes the 10, Windows Server 2019, Windows Server 2022, Windows
legitimate DLL in the loading sequence. Server 2023, and Windows 11 environments. The operating
By enabling PageHeap [50], a debugging tool designed to systems were configured to their default settings, and we
detect heap-related memory errors, the system can identify installed several commonly used applications (e.g., Visual Stu-
more detailed memory issues, including Type-1 and Type- dio, Microsoft Exchange). The evaluations were performed on
3 vulnerabilities. In the event of a crash, memory context a desktop system equipped with an Intel i9-13900H processor
information and function call stack details are automatically and 32GB of memory. Our assessment addressed the following
dumped and logged within the system for subsequent analysis. research questions:
Leveraging the WinDbg [51] debugger on the Windows plat- • RQ1: How effective are the most important components of
form, we delved into the analysis of dump files produced by OLE XPLORE (i.e., OLE identification and storage fuzzing)?
crashes. We employed WinDbg to scrutinize the crash dump • RQ2: How effective is OLE XPLORE on detecting vulnera-
files, to further study the root cause of vulnerabilities and bilities within OLE components specific to Office?
identify points of exploitation. To validate the effectiveness of • RQ3: How precise is OLE XPLORE in detecting unsafe OLE
these analyses, we conducted manual tests using previously components?
generated RTF documents, verifying potential vulnerabilities
in practice. Such a verification process aids in constructing A. RQ1: Evaluation of OLExplore’s Components
PoC for the vulnerabilities, thereby enhancing corresponding 1) Identifying OLE components from COM components:
security measures. OLE XPLORE, operating under the Windows 10 environment,
enumerated and analyzed a total of 7,361 COM components.
F. Vulnerability Analysis We focus on COM components developed by Microsoft first as
To assess the severity of these identified vulnerabilities, non-Microsoft ones are less likely to be exploited by attackers
OLE XPLORE includes the process of weaponization. This due to the lack of universality and stability. Microsoft COM
enables a comprehensive understanding of the potential im- components derived from the Windows Software Development
plications of each vulnerability and informs the development Kit (SDK) were also incorporated into the screening scope
of mitigation strategies. In OLE XPLORE, the weaponization by OLE XPLORE, making them suitable for analyzing the
techniques for these vulnerabilities are innovative, featuring machines with development environments.
concealment methods that have not been disclosed, despite the On Windows Server 2022 version 10.0.20348.1487, OLE X -
fact that we have responsibly disclosed these vulnerabilities PLORE extracted 7,274 CLSIDs, whereas 7,369 were identified
and the methods of weaponizing them to Microsoft. on Windows 11, indicating small variations in the total count
Post-construction, it is confirmed that 18 vulnerabilities of COM components across different versions of the Windows
detected by OLE XPLORE are capable of facilitating remote operating systems. Among the numerous COM components,

10
 TABLE I: List of vulnerabilities discovered by OLExplore
Module Vuln. Type Impact Confirmed Version Status
Windows Runtime Type-1 Remote Code Execution Windows 10 in 2021 CVE-2022-21878
Type-1 Remote Code Execution Windows 10 in 2021 CVE-2022-21888
Type-1 Remote Code Execution Windows 10 in 2021 CVE-2022-21971
Type-1 Denial of Service Windows 10 & Windows Server 2022 Confirmed
Type-1 Denial of Service Windows 10 & Windows Server 2022 Confirmed
Type-1 Remote Code Execution Windows 10 in 2021 CVE-2022-21992
Type-1 Remote Code Execution Windows 10 in 2021 CVE-2022-21974
Type-1 Remote Code Execution Windows 11 & Windows Server in 2023 CVE-2023-29366
Type-1 Remote Code Execution Windows 11 & Windows Server in 2023 CVE-2023-29367
Type-1 Remote Code Execution Windows 11 & Windows Server in 2023 CVE-2023-35313
Type-1 Remote Code Execution Windows 11 & Windows Server in 2023 CVE-2023-35323
Type-1 Remote Code Execution Windows 11 & Windows Server in 2023 CVE-2023-36704
Visual Studio Type-1 Remote Code Execution Visual Studio in 2023 CVE-2023-28296
Windows Geolocation Service Type-2 Remote Code Execution Windows Server 2019 & 2022 CVE-2023-35343
Tablet Windows UI App. Core Type-2 Remote Code Execution Windows 11 21H2 & 22H2 CVE-2023-36898
Windows UI App. Core Type-2 Remote Code Execution Windows Server 2019 & 2022 CVE-2023-36393
Windows Runtime Type-2 Remote Code Execution Windows 11 23H2 & 22H2 CVE-2024-21435
Microsoft Exchange Server Type-2 Remote Code Execution Microsoft Exchange Server 2019 CVE-2024-26198
Windows Runtime Type-2 Remote Code Execution Windows Server 2019 & 2022 Confirmed
Windows Inking COM Type-3 Remote Code Execution Almost all versions of Windows CVE-2022-23290
Windows Runtime Type-3 Denial of Service Windows 10 & Windows Server 2022 Confirmed
Type-3 Denial of Service Windows 10 & Windows Server 2022 Confirmed
Type-3 Denial of Service Windows 10 & Windows Server 2022 Confirmed
Type-3 Denial of Service Windows 10 & Windows Server 2022 Confirmed
Type-3 Denial of Service Windows 10 & Windows Server 2022 Confirmed
Type-3 Denial of Service Windows Server 2022 Confirmed

OLE XPLORE has identified 257 existing OLE components the loading process and have 7 checksum fields. Due to the
in the system by enumerating and filtering interfaces. In presence of the feedback component, whenever a check is
comparison to Windows 10, the quantity of OLE components passed, new code coverage is revealed and hence, the current
existing in Windows 11 did not exhibit any significant change chunk and all previous chunks are saved as a snapshot. This
For comparison purposes, we conducted tests using snapshot bootstraps the input mutation with a focus on either
Dranzer [53], an outdated tool but still the best match we can passing the next check or testing other code logic after these
find, on systems with similar configurations. Dranzer found checks. This example shows that compared with blackbox
only 5,839 COM components and failed to recognize any fuzzing (i.e., no feedback on the usefulness of input chunk),
OLE components within its purview. The scope of Dranzer’s coverage-guided micro-snapshot fuzzing can significantly in-
testing was largely confined to parameter testing multiple crease the chances of discovering vulnerabilities that require
COM components loaded within Internet Explorer, aimed at passing multiple validation checks.
detecting potential crash scenarios. However, given that Inter- 3) Effectiveness of micro-snapshot fuzzing in general:
net Explorer is no longer supported in versions of Windows We compare Type-3 bug detection with and without micro-
beyond 10 and 11, the relevance of these tests has significantly snapshot fuzzing. Among the 7 identified Type-3 bugs, 4
diminished. And yet, if we were to adapt Dranzer for Office, were found with micro-snapshot fuzzing in non-ActiveX
Dranzer is still unable to detect these vulnerabilities. This items, whereas none of these bugs could be found without
limitation arises because Dranzer’s tests focus exclusively on micro-snapshot fuzzing (i.e., by randomly mutating the entire
the loading of ActiveX controls. Although Office does include “structured storage”). As showcased in Section V-A2, the
ActiveX capabilities, due to Microsoft’s security policies, combined use of snapshotting and coverage-guided feedback
ActiveX parsing is disabled by default. Consequently, when allows for a more effective fuzzing process. Snapshotting saves
it reaches the CoCreateInstance stage, it will not proceed the execution context, making it easier to resume operations,
with further parsing of ActiveX components. while feedback provides real-time information that guides the
2) Effectiveness of coverage and feedback in micro- mutation process, enhancing the likelihood of passing sanity
snapshot fuzzing: The feedback component plays a crucial checks and uncovering complex bugs.
role in conjunction with snapshot fuzzing. Without feedback 4) Performance of micro-snapshot fuzzing: Over a 2500-
and instrumentation, bypassing progressive checks via random minute testing period on inkobj.dll, the total number of
mutation (as in WinAFL) is almost impossible. For example, basic blocks increased from 1239 with whole-storage random
MTEFData objects in EQNEDT32.exe are read 21 times during mutation (baseline) to 1639 with whole-storage mutation with

11
 a WapAuthProvider object is allocated and initialized,
Coverage occupying 0x78 bytes in memory. However, the object’s state
1750 1695
1639
is not fully initialized. Upon invocation of the destructor
1500 WapAuthProvider:: WapAuthProvider, the pointer at
1250 1239 offset 0x50 is released without being previously initialized.
Figure 10 displays the vulnerable code snippet exploitable for
1000
basic blocks

remote arbitrary code execution.

750
500
1 void
,→ WapAuthProvider::˜WapAuthProvider(__int64
250 Baseline: Fuzzing via whole-storage random mutation ,→ this) {
Fuzzing via whole-storage mutation with feedback 2 void *v2; // rcx
0 Micro-snapshot fuzzing with chunk-by-chunk mutation 3 void *v3; // rcx
0 500 1000 1500 2000 2500 4
minutes
5 *(_QWORD *)this =
,→ &WapAuthProvider::`vftable';
Fig. 9: Performance of micro-snapshot fuzzing 6 LocalFree(*(HLOCAL *)(this + 56));
7 v2 = *(void **)(this + 64);
feedback, and finally to 1695 with micro-snapshot fuzzing with 8 *(_QWORD *)(this + 56) = 0i64;
9 LocalFree(v2);
chunk-by-chunk mutation, as shown in Figure 9. 10 v3 = *(void **)(this + 80); // <--
Compared to using only feedback-based methods, the in- ,→ [0] uninitialized
clusion of micro-snapshot fuzzing does not show a significant 11 *(_QWORD *)(this + 64) = 0i64;
improvement in the total number of basic blocks covered. 12 LocalFree(v3); // <--
However, since snapshotting saves the execution context, there ,→ [1] free
is a noticeable increase in coverage during the early testing 13 *(_QWORD *)(this + 80) = 0i64;
14 }
phases. Higher coverage is crucial because it implies a more
thorough examination of the code, potentially leading to the Fig. 10: Simplified code snippet of CVE-2022-21971 Windows
discovery of edge cases and hidden bugs that might not be Runtime Remote Code Execution Vulnerability
detected with lower coverage. This demonstrates the superior
effectiveness of micro-snapshot fuzzing in exploring execution Type-2 vulnerability example: CVE-2023-35343.
paths and uncovering potential vulnerabilities. Throughout the course of our testing, we have uncovered
We measured an average of 107 and 112 executions per two significant security vulnerabilities. For instance, CVE-
second on inkobj.dll and inked.dll, respectively, 2023-35343 serves as a prototypical case; it constitutes
where one execution spans from loading a snapshot to the a remote code execution vulnerability pertaining to the
end of IPersistStorage::Load. Without snapshotting, Windows Location Service, adversely affecting the standard
the rates were 375 and 472 IPersistStorage::Load configurations of Windows Server 2019 and 2022.
executions per second, respectively. Our root cause analysis found that the vulnerability
Although the execution rate is lower when using micro- occurs when the CoCreateInstance function calls the
snapshot fuzzing, the trade-off is justified by the increased GetFindMyDeviceEnabled method, leading to an attempt
coverage. The snapshotting approach allows for deeper explo- to load the library mdmcommon.dll with LoadLibraryW.
ration of the code, focusing on previously unexplored paths However, the mdmcommon.dll file does not exist within
and increasing the likelihood of finding critical vulnerabilities the Windows Server environment. An attacker can exploit
that might be missed by traditional fuzzing methods. Thus, this flaw by placing a malicious library file mdmcommon.dll
while micro-snapshot fuzzing incurs a performance overhead, in the current directory, potentially triggering a remote code
it substantially enhances code coverage and the effectiveness execution attack. A logical error has been uncovered, and the
of vulnerability discovery. discovered vulnerability could be readily exploited under the
B. RQ2: Vulnerability Finding Effectiveness condition that the attacker manages to place both a malicious
Table I presents the detailed information of confirmed document and a corresponding malicious DLL in the victim’s
vulnerabilities, with 17 of the vulnerabilities being assigned current working directory to carry out the attack(e.g., by
CVE IDs. For each verified CVE, we provide the module placing a document and a DLL in the same zip file).
where the vulnerability resides, the type of vulnerability, its Type-3 vulnerability example: CVE-2022-23290.
impact, the affected build versions, and the assigned CVE ID. While investigating the IPersistStorage interface,
18 vulnerabilities listed are capable of being exploited for we invoked the method in the interface named
remote code execution. We will offer a root-cause analysis for CSketchInk::IPersistStreamInit_Load and performed
each type of vulnerability in the following subsections. a memory allocation operation. However, this process
Type-1 vulnerability example: CVE-2022-21971. only achieved partial initialization. Upon analyzing the
Within the constructor CreateInstance, an instance of function InkObj!CSketchInk::FreeStrokeList, we

12
 C. RQ3: False Positives in OLE XPLORE
1 HeapAlloc(*(HANDLE *)Default, *((_DWORD
,→ *)Default + 2), 0x70); We conducted an in-depth investigation into the exposed
2 ... bugs and the details of vulnerability crashes. Our analysis
3 v6 = *(void **)(this+0x10); // indicates that the majority of false positives are attributable
,→ Uninitialized pointer to null pointer exceptions on Windows systems.
4 HeapFree(*(HANDLE *)Default, *((_DWORD
,→ *)Default + 2), v6); TABLE III: Null pointer and vulnerability counts
5
Version # Crash # NULL pointer # CVE
6 mov rdi, qword ptr [rax+10h]
7 ds:00000158`42fcbfa0=c0c0c0c0c0c0c0c0 Windows 10 12 7 5
Windows Server 2022 13 8 5
Fig. 11: Simplified code snippet of CVE-2022-23290 Windows
Inking COM Remote Code Execution Vulnerability As demonstrated in Table III, on Windows 10 version
10.0.19041.1237, Type-1 and Type-3 vulnerabilities yielded
identified an issue with an uninitialized pointer. To observe
a total of 12 crash dump files. Out of these, 5 were con-
this behavior more closely, we enabled full PageHeap
firmed as CVEs, while the remaining 7 were identified as
and conducted a trace in WinDbg. Figure 11 illustrates
null pointer issues upon further examination. Similarly, on
the vulnerability segment after simplifying the logic at
Windows Server 2022 version 10.0.20348.1487, the count of
InkObj!CSketchInk::FreeStrokeList +0x3d and the
null pointer problems stands at 8. The rationale for classifying
corresponding assembly code during single-step execution.
these bugs as false positives rather than CVEs is rooted in their
It is evident that accessing the allocated memory results
exploitability, or lack thereof, under modern Windows and
in abnormal values (c0c0c0c0c0c0c0c0), which likely
Office mitigation mechanisms; such issues are substantially
indicates a memory corruption issue.
less likely to be leveraged for security attacks.
TABLE II: Bug statistics by OLE XPLORE and others
VI. D ISCUSSIONS
Tool Crashes Bugs CVEs
WinAFL 1 1 0 A. Generality of OLE XPLORE and Future Work
W INNIE 0 0 0 OLE is a typical superware architecture where third-party
OLExplore 40 26 17
modules are dynamically loaded into the same memory space
shared by the main application and other modules. External
During the 24-hour testing period, OLExplore triggered 40
inputs are processed by external modules solely with the main
crashes, of which 26 were confirmed as bugs. In contrast,
application performing minimal checks. This paradigm applies
WinAFL only triggered a single crash, while WINNIE did
beyond OLE to other popular software packages as well, such
not trigger any crashes at all. These vulnerabilities are chal-
as WeChat and Alipay.
lenging to detect through conventional data mutation fuzzing
Porting OLExplore to other superware. Migrating the
because constructing the data without knowing to maintain
collection and analysis of OLE components to certain Office-
equal lengths in certain parts is problematic. Furthermore, byte
like superware (e.g., WPS Office) does not require exces-
misalignment often prevents the data from passing verification
sive manual work since most mechanisms can be directly
checks. This difficulty in crafting suitable test cases is why
ported, as these types of software directly support OLE.
WinAFL and WINNIE were unable to achieve similar results.
However, to migrate micro-snapshot fuzzing to other soft-
Table II shows the comparison results of three tools.
ware, it is necessary to identify input-reading functions like
CExposedStream::Read (e.g., the DecodeWxam function in
WeChat that processes proprietary formats like WXAM [54]).
Responsible Disclosure. Upon identifying vulnerabilities, This still requires some manual work in reverse engineering
we promptly reported them to the Microsoft Security Response to confirm that inputs are processed chunk-by-chunk and
Center (MSRC) with PoC exploits. In October 2021, we to choose the appropriate instrumentation mechanism, all of
submitted the first batch of vulnerabilities affecting Windows which require manual effort. Once these aspects are verified,
10. These issues were progressively addressed, with patches the fuzzing architecture can be migrated. To find Type-1/2
released by early 2022. In February 2023, we identified and vulnerabilities, manual effort is needed to identify the dynamic
reported a second batch of vulnerabilities affecting Windows module loading mechanism, especially key functions like
11 and Windows Server, and these were patched throughout CoCreateInstance. The bug oracle of OLExplore can be
the latter half of 2023. Later in 2023, we conducted a compre- reused.
hensive screening across all scenarios, identifying additional Reusing Attack Surface Among Large and Complex
vulnerabilities, which were reported and subsequently patched Software Systems. It is well known that vulnerabilities in
by Microsoft, with the final patch released in March 2024. dynamically loadable modules offer significant exploit oppor-
Throughout this process, we maintained continuous commu- tunities. In fact, attack vectors discussed in Section III are also
nication with MSRC to ensure timely resolution and patch applicable to other software systems, some of which have been
release for all reported issues. well studied. For example: Type-1 vulnerabilities (dependency

13
confusion) are common issues in supply chain security [55]; GUI code. WinFuzz [19] introduces target-embedded snap-
Type-2 vulnerabilities (DLL-preloading) have been highlighted shotting, allowing applications to snapshot themselves without
in recent studies [56] particularly in applications such as source code or kernel modifications, enhancing precision in
Chrome and Adobe Reader; and Type-3 vulnerabilities, which fuzzing.
often involve parsing and handling of embedded objects,
are prevalent in Adobe Reader, as evidenced by CVE-2019- VIII. CONCLUSION
8014 [57] and CVE-2021-44711 [58]. In this paper, we introduce OLE XPLORE, a new tool
Extending OLExplore to Vulnerabilities in Linked Ob- crafted for systematic detection of vulnerabilities within OLE
jects. A significant security concern titled “Moniker Magic: components for Office applications. OLE XPLORE is based on
Running Scripts Directly in Microsoft Office” [59] highlighted an exhaustive analysis of historical vulnerabilities associated
vulnerabilities such as CVE-2017-0199, which exploit the with OLE components, from which we summarized three
URL Moniker feature to load remote .hta files. These vul- distinct vulnerability patterns. OLE XPLORE conducts static
nerabilities arise from flawed design choices in the Office file analysis on all COM entities available on the platform to cull
loading mechanisms and require IE10 or IE11 to be present. a subset of OLE components, which are then subjected to
The exploit can occur without user interaction, although a dynamic analysis leveraging the trio of vulnerability traits for
dialog box appears during the process. FireEye later disclosed comprehensive security evaluation. In our empirical studies,
details of a captured sample exploiting CVE-2017-0199 [60]. OLE XPLORE scrutinized the attack surface of 257 OLE ob-
Despite patches that introduced blacklist mechanisms for un- jects, uncovering 26 vulnerabilities, out of which 17 have been
safe Monikers, subsequent vulnerabilities indicate that many assigned CVE numbers with remote code execution potential.
problematic Monikers remain unidentified.
To address these linked object vulnerabilities, OLExplore ACKNOWLEDGMENT
can be extended to analyze and detect such issues. OLExplore This work was partly supported by the National Key R&D
includes a component for collecting OLE components. By Program of China (2021YFB2701000), the Key R&D Program
adding features such as scanning for StdOleLink identifiers, of Hubei Province (2023BAB017, 2023BAB079), the National
it can quickly identify and gather all linked objects on the NSF of China (grants No.62302181, 62072046), the Knowl-
system. In future work, it is necessary to investigate the edge Innovation Program of Wuhan-Basic Research, Huawei
vulnerabilities of the identified linked objects, categorize them Research Fund, and HUSTCSE-FiberHome Joint Research
based on their root causes, and incorporate the corresponding Center for Network Security.
bug oracles into the OLExplore components. By enhancing
OLExplore’s capabilities to scrutinize both embedded and R EFERENCES
linked objects, it can provide a more comprehensive security [1] NCC Group, “Understanding Microsoft Word OLE Exploit Primitives:
analysis of Office documents. Exploiting CVE-2015-1642 Microsoft Office CTaskSymbol Use-After-
Free Vulnerability,” https://research.nccgroup.com/wp-content/uploads
VII. R ELATED W ORK /2020/12/Understanding-Microsoft-Word-OLE-Exploit-Primitives-Exp
loiting-CVE-2015-1642.pdf, 2015.
COM Security Enhancements. Dewey et al. [61] found [2] McAfee, “An Inside Look into Microsoft Rich Text Format and OLE
that COM has many vulnerabilities that attackers can exploit Exploits,” https://www.mcafee.com/blogs/other-blogs/mcafee-labs/an-i
nside-look-into-microsoft-rich-text-format-and-ole-exploits/, 2020.
to compromise systems. Attackers can bypass security policies [3] Q. Li and Q. Jin, “Needle in A Haystack: Catch Multiple Zero-days
of popular applications, which allow the use of many flawed Using Sandbox,” https://images.seebug.org/archive/Catch Multiple Zer
controls. To solve this, they created COMBLOCK, a reference o-Days Using Sandbox-EN.pdf, 2019.
[4] S. Salehi, I. Miremadi, M. Ghasempour Nejati, and H. Ghafouri,
monitor that ensures all COM operations follow a global “Fostering the Adoption and Use of Super App Technology,” IEEE
policy. Transactions on Engineering Management, 2023.
Detection of Vulnerabilities in COM Objects. Gu et [5] F. Momot, S. Bratus, S. M. Hallberg, and M. L. Patterson, “The Seven
Turrets of Babel: A Taxonomy of LangSec Errors and How to Expunge
al. [62] introduced COMRACE, a tool that detects data race Them,” in 2016 IEEE Cybersecurity Development (SecDev), 2016, pp.
vulnerabilities in COM objects. It uses static binary analysis 45–52.
to identify insecure methods in COM binaries and validates [6] M. Zalewski, “Afl,” https://lcamtuf.coredump.cx/afl, 2017.
[7] Google, “ClusterFuzz,” https://github.com/google/oss-fuzz/blob/master/
these findings with synthesized PoCs, effectively identifying docs/clusterfuzz.md, 2018.
and mitigating data race vulnerabilities. [8] A. Fioraldi, D. Maier, H. Eißfeldt, and M. Heuse, “AFL++: Combining
Type Confusion Vulnerabilities in COM. Zhang et al. [63] incremental steps of fuzzing research,” in 14th USENIX Workshop on
Offensive Technologies (WOOT 20), 2020.
presented COMFUSION, the first tool to find union type [9] Y. Li, S. Ji, C. Lyu, Y. Chen, J. Chen, Q. Gu, C. Wu, and R. Beyah, “V-
confusion vulnerabilities in Windows COM. Before this, no Fuzz: Vulnerability Prediction-Assisted Evolutionary Fuzzing for Binary
tools could recover union types in binaries. COMFUSION Programs,” IEEE Transactions on Cybernetics, vol. 52, no. 5, pp. 3745–
3756, 2022.
bridges this gap, improving COM application security by [10] Google, “Honggfuzz,” https://github.com/google/honggfuzz, 2010.
detecting and fixing these vulnerabilities. [11] P. Godefroid, M. Y. Levin, and D. Molnar, “SAGE: Whitebox Fuzzing
Fuzzing Techniques for Windows. WINNIE [17] improves for Security Testing: SAGE has had a remarkable impact at Microsoft.”
Queue, vol. 10, no. 1, p. 20–27, jan 2012. [Online]. Available:
Windows fuzzing by directly invoking target functions and https://doi.org/10.1145/2090147.2094081
using an efficient fork implementation, avoiding unnecessary [12] The KLEE Team, “Klee,” https://klee.github.io, 2015.

14
[13] Y. Shoshitaishvili, R. Wang, C. Salls, N. Stephens, M. Polino, [33] ——, “OffVis,” https://download.microsoft.com/download/1/2/7/127ba5
A. Dutcher, J. Grosen, S. Feng, C. Hauser, C. Kruegel, and G. Vigna, 9a-4fe1-4acd-ba47-513ceef85a85/offvis.zip, 2011.
“SoK: (State of) The Art of War: Offensive Techniques in Binary [34] ——, “Privileges,” https://learn.microsoft.com/en-us/windows/win32/se
Analysis,” in IEEE Symposium on Security and Privacy, 2016. cauthz/privileges, 2021.
[14] I. Yun, S. Lee, M. Xu, Y. Jang, and T. Kim, “QSYM : A Practical [35] “CVE-2017-11882,” https://cve.mitre.org/cgi-bin/cvename.cgi?name=
Concolic Execution Engine Tailored for Hybrid Fuzzing,” in 27th CVE-2017-11882, 2017.
USENIX Security Symposium (USENIX Security 18). Baltimore, MD: [36] FireEye, “New Targeted Attack in the Middle East by APT34, a
USENIX Association, Aug. 2018, pp. 745–761. [Online]. Available: Suspected Iranian Threat Group, Using CVE-2017-11882 Exploit,”
https://www.usenix.org/conference/usenixsecurity18/presentation/yun https://www.mandiant.com/resources/blog/targeted-attack-in-middl
[15] K. Weiss and J. Schütte, “Annotary: A Concolic Execution System for e-east-by-apt34, 2017.
Developing Secure Smart Contracts,” in Computer Security – ESORICS [37] Microsoft, “Process Monitor,” https://learn.microsoft.com/en-us/sysint
2019, K. Sako, S. Schneider, and P. Y. A. Ryan, Eds. Cham: Springer ernals/downloads/procmon, 2023.
International Publishing, 2019, pp. 747–766. [38] ——, “Get-Member,” https://learn.microsoft.com/en-us/powershell/m
[16] X. Song, Z. Wu, and Y. Wang, “Directer: A Parallel and odule/microsoft.powershell.utility/get-member?view=powershell-7.4,
Directed Fuzzing based on Concolic Execution,” in Proceedings 2023.
of the 7th International Conference on Software and Information [39] J. Forshaw, “OleViewDotnet,” https://github.com/tyranid/oleviewdotnet,
Engineering, ser. ICSIE ’18. New York, NY, USA: Association 2014.
for Computing Machinery, 2018, p. 87–92. [Online]. Available: [40] S. Vittitoe, “Issue 514: Microsoft Office / COM Object DLL Planting
https://doi.org/10.1145/3220267.3220272 with els.dll,” https://bugs.chromium.org/p/project-zero/issues/detail?id
[17] J. Jung, S. Tong, H. Hu, J. Lim, Y. Jin, and T. Kim, “Winnie: =514, 2015.
Fuzzing windows applications with harness synthesis and fast cloning,” [41] W. Dormann, “Attacking COM via Word RTF,” https://insights.sei.cmu
in Proceedings of the 2021 Network and Distributed System Security .edu/library/attacking-com-via-word-rtf/, 2021.
Symposium (NDSS 2021), 2021.
[42] Microsoft, “ActiveX Controls Architecture,” https://learn.microsoft.co
[18] C.-K. Luk, R. Cohn, R. Muth, H. Patil, A. Klauser, G. Lowney, m/en-us/windows/win32/com/activex-controls-architecture, 2019.
S. Wallace, V. J. Reddi, and K. Hazelwood, “Pin: building customized
[43] J. Wang, B. Chen, L. Wei, and Y. Liu, “Superion: Grammar-Aware
program analysis tools with dynamic instrumentation,” Acm sigplan
Greybox Fuzzing,” in 2019 IEEE/ACM 41st International Conference
notices, vol. 40, no. 6, pp. 190–200, 2005.
on Software Engineering (ICSE), 2019, pp. 724–735.
[19] L. Stone, R. Ranjan, S. Nagy, and M. Hicks, “No linux, no
[44] A. Fioraldi, D. C. D’Elia, and E. Coppa, “WEIZZ: automatic grey-box
problem: Fast and correct windows binary fuzzing via target-embedded
fuzzing for structured binary formats,” in Proceedings of the 29th
snapshotting,” in 32nd USENIX Security Symposium (USENIX Security
ACM SIGSOFT International Symposium on Software Testing and
23). Anaheim, CA: USENIX Association, Aug. 2023, pp. 4913–4929.
Analysis, ser. ISSTA 2020. New York, NY, USA: Association
[Online]. Available: https://www.usenix.org/conference/usenixsecurity
for Computing Machinery, 2020, p. 1–13. [Online]. Available:
23/presentation/stone
https://doi.org/10.1145/3395363.3397372
[20] Google Project Zero, “Jackalope,” https://github.com/googleprojectzero
/Jackalope, 2020. [45] T. Blazytko, C. Aschermann, M. Schlögel, A. Abbasi, S. Schumilo,
S. Wörner, and T. Holz, “GRIMOIRE: Synthesizing Structure while
[21] J. Pan, G. Yan, and X. Fan, “Digtool: A Virtualization-Based
Fuzzing,” in 28th USENIX Security Symposium (USENIX Security 19).
Framework for Detecting Kernel Vulnerabilities,” in 26th USENIX
Santa Clara, CA: USENIX Association, Aug. 2019, pp. 1985–2002.
Security Symposium (USENIX Security 17). Vancouver, BC: USENIX
[Online]. Available: https://www.usenix.org/conference/usenixsecurity
Association, Aug. 2017, pp. 149–165. [Online]. Available: https:
19/presentation/blazytko
//www.usenix.org/conference/usenixsecurity17/technical-sessions/pres
entation/pan [46] S. Schumilo, C. Aschermann, A. Abbasi, S. Wör-ner, and T. Holz, “Nyx:
[22] J. E. Forrester and B. P. Miller, “An Empirical Study of the Robustness Greybox Hypervisor Fuzzing using Fast Snapshots and Affine Types,”
of Windows NT Applications Using Random Testing,” in Proceedings of in 30th USENIX Security Symposium (USENIX Security 21). USENIX
the 4th Conference on USENIX Windows Systems Symposium - Volume Association, Aug. 2021, pp. 2597–2614. [Online]. Available: https:
4, ser. WSS’00. USA: USENIX Association, 2000, p. 6. //www.usenix.org/conference/usenixsecurity21/presentation/schumilo
[23] Y. Choi, H. Kim, and D. Lee, “An Empirical Study for Security of [47] S. Schumilo, C. Aschermann, R. Gawlik, S. Schinzel, and T. Holz,
Windows DLL Files Using Automated API Fuzz Testing,” in 2008 “kAFL: Hardware-Assisted Feedback Fuzzing for OS Kernels,” in 26th
10th International Conference on Advanced Communication Technology, USENIX Security Symposium (USENIX Security 17). Vancouver, BC:
vol. 2, 2008, pp. 1473–1475. USENIX Association, Aug. 2017, pp. 167–182. [Online]. Available:
[24] Google Project Zero, “WinAFL,” https://github.com/googleprojectzero https://www.usenix.org/conference/usenixsecurity17/technical-sessions/
/winafl, 2016. presentation/schumilo
[25] J. Choi, K. Kim, D. Lee, and S. K. Cha, “NtFuzz: Enabling Type-Aware [48] Microsoft, “Detours,” https://github.com/microsoft/Detours, 2018.
Kernel Fuzzing on Windows with Static Binary Analysis,” in 2021 IEEE [49] Google Project Zero, “TinyInst,” https://github.com/googleprojectzero
Symposium on Security and Privacy (SP), 2021, pp. 677–693. /TinyInst.
[26] M. Heuse, “AFL-DynamoRIO,” https://github.com/vanhauser-thc/afl-d [50] Microsoft, “GFlags and PageHeap - Windows drivers,” https://learn.mi
ynamorio, 2018. crosoft.com/en-us/windows-hardware/drivers/debugger/gflags-and-pag
[27] Q. Jin, “How I Found 16 Microsoft Office Excel Vulnerabilities in 6 eheap, 2022.
Months,” https://conference.hitb.org/hitbsecconf2021ams/materials/D2T [51] ——, “WinDbg,” http://www.windbg.org, 2023.
1%20-%20How%20I%20Found%2016%20Microsoft%20Office%20Ex [52] Outflank, “Mark-of-the-Web from a Red Team’s Perspective,” https:
cel%20Vulnerabilities%20in%206%20Months%20-%20Quan%20Jin.p //www.outflank.nl/blog/2020/03/30/mark-of-the-web-from-a-red-teams
df, 2021. -perspective/, 2017.
[28] M. Debasish, “OpenXMolar,” https://github.com/debasishm89/OpenX [53] D. Plakosh and W. Dormann, “Dranzer,” https://github.com/CERTCC/
Molar, 2017. dranzer, 2009.
[29] Check Point, “FUZZING THE OFFICE ECOSYSTEM,” https://resear [54] Signal Labs, “Fuzzing WeChat’s Wxam Parser,” https://signal-labs.co
ch.checkpoint.com/2021/fuzzing-the-office-ecosystem/, 2021. m/fuzzing-wechats-wxam-parser/, 2022.
[30] LLVM Project, “LibFuzzer,” https://llvm.org/docs/LibFuzzer.html, 2003. [55] S. Neupane, G. Holmes, E. Wyss, D. Davidson, and L. D. Carli,
[31] Y. C. Koh, “Understanding the Microsoft Office 2013 Protected-View “Beyond Typosquatting: An In-depth Look at Package Confusion,” in
Sandbox,” https://labs.withsecure.com/content/dam/labs/docs/UNDERS 32nd USENIX Security Symposium (USENIX Security 23). Anaheim,
TANDING-THE-MICROSOFT-OFFICE-2013-PROTECTED-VIEW-S CA: USENIX Association, Aug. 2023, pp. 3439–3456. [Online].
ANDBOX-WP3.pdf, 2015. Available: https://www.usenix.org/conference/usenixsecurity23/present
[32] Microsoft, “Insert an object in your Excel spreadsheet - Microsoft ation/neupane
Support,” https://support.microsoft.com/en-us/office/insert-an-objec [56] C. Yu, Y. Xiao, J. Lu, Y. Li, Y. Li, L. Li, Y. Dong, J. Wang, J. Shi, D. Bo,
t-in-your-excel-spreadsheet-e73867b2-2988-4116-8d85-f5769ea435ba, and W. Huo, “File Hijacking Vulnerability: The Elephant in the Room,”
2023. Proceedings 2024 Network and Distributed System Security Symposium,

15
 2024. [Online]. Available: https://api.semanticscholar.org/CorpusID: they continue to pose a significant risk at present. Among
267621808 the remaining vulnerabilities, 27.03% are no longer applicable
[57] “CVE-2019-8014,” https://cve.mitre.org/cgi-bin/cvename.cgi?name=CV
E-2019-8014, 2023. because the vulnerable applications have reached the end of
[58] “CVE-2021-44711,” https://cve.mitre.org/cgi-bin/cvename.cgi?name= life. Additionally, 13.51% of the vulnerabilities are challenging
CVE-2021-44711, 2023. to exploit and are unlikely to be used in practical scenarios, as
[59] H. Li and B. Sun, “Moniker Magic: Running Scripts Directly in Mi-
crosoft Office,” https://leo00000.github.io/pdf/Moniker Magic final.pdf, such vulnerabilities have neither been disclosed nor captured
2017. being exploited in the wild over the past five years.
[60] FireEye, “CVE-2017-0199: In the Wild Attacks Leveraging HTA Han-
• RTF Control Word and Open XML Tag Parsing Problems.
dler,” https://www.mandiant.com/resources/blog/cve-2017-0199-hta-h
andler, 2017. These two types are grouped together due to their as-
[61] D. Dewey and P. Traynor, “No Loitering: Exploiting Lingering Vulner- sociation with specific markers or identifiers within their
abilities in Default COM Objects,” in NDSS, 2011.
[62] F. Gu, Q. Guo, L. Li, Z. Peng, W. Lin, X. Yang, and X. Gong,
respective formats. Both require memory corruption that
“COMRace: Detecting Data Race Vulnerabilities in COM Objects,” necessitates precise memory control like heap feng shui
in 31st USENIX Security Symposium (USENIX Security 22). Boston, for exploitation. However, the absence of good primi-
MA: USENIX Association, Aug. 2022, pp. 3019–3036. [Online].
Available: https://www.usenix.org/conference/usenixsecurity22/present
tives for memory manipulation typically makes exploita-
ation/gu-fangming tion more challenging. Despite contemporary mitigation
[63] Y. Zhang, X. Zhu, D. He, M. Xue, S. Ji, M. S. Haghighi, S. Wen, techniques, such vulnerabilities persist. For example, CVE-
and Z. Peng, “Detecting Union Type Confusion in Component Object
Model,” in Proceedings of the 32nd USENIX Conference on Security
2023-21716 [67] demonstrates a Microsoft Word remote
Symposium, ser. SEC ’23. USA: USENIX Association, 2023. code execution vulnerability. Yet, as evidenced by the lack of
[64] houjingyi, “office-exploit-case-study,” https://github.com/houjingyi233/ detected memory corruption exploits over the past five years,
office-exploit-case-study, 2018.
[65] Offsec, “Exploit Database,” https://www.exploit-db.com/, 2024.
these vulnerabilities are now significantly more difficult to
[66] Google Project Zero, “project-zero,” https://bugs.chromium.org/p/projec exploit than before.
t-zero/issues/list, 2024. • EPS File Parsing Problems. EPS, once supported by Office
[67] “CVE-2023-21716,” https://cve.mitre.org/cgi-bin/cvename.cgi?name=
CVE-2023-21716, 2023.
as an image format featuring PostScript program code
[68] Microsoft, “Description of the security update for Office 2016: April which is amenable to memory manipulations, hence was
11, 2017,” https://support.microsoft.com/en-us/topic/description-of-the more exploitable. This attack vector, however, is no longer
-security-update-for-office-2016-april-11-2017-c4cec448-05d9-1ae2-3
7b0-869ec9a0aa71, 2017.
present; since April 2017, Office has disabled the insertion
[69] ——, “Data Execution Prevention,” https://learn.microsoft.com/en-us/ of EPS files into documents [68].
windows/win32/memory/data-execution-prevention, 2023. • Other Resource File Parsing Problems. In addition to EPS,
[70] Pax, “ASLR,” https://pax.grsecurity.net/docs/aslr.txt, 2023.
[71] Microsoft, “Blocking Flash, Shockwave, Silverlight controls from acti-
Office still supports the insertion of various resource files,
vating in Office Applications for Security,” https://techcommunity.micr including 3D models, among others. A substantial number
osoft.com/t5/security-compliance-and-identity/blocking-flash-shockwa of vulnerabilities remain active in this area. Historically,
ve-silverlight-controls-from-activating-in/ba-p/191729, 2018.
[72] H. Li and B. Sun, “Attacking Interoperability: An OLE Edition,” https:
such issues always proved similar, with updates (e.g., June
//www.blackhat.com/docs/us-15/materials/us-15-Li-AttackingInteropera 1st, 2023) temporarily disabling the functionality to insert
bility-An-OLE-Edition.pdf, 2015. SketchUp graphics (.skp files) into Office. However, these
[73] UINT 42, “In-Depth Analysis of July 2023 Exploit Chain Featuring
CVE-2023-36884 and CVE-2023-36584,” https://unit42.paloaltonetwo
types of vulnerabilities are very scattered and small in
rks.com/new-cve-2023-36584-discovered-in-attack-chain-used-by-rus number and are not included in the statistics.
sian-apt/, 2023. • Moniker Problems. Moniker is an intrinsic feature of the
[74] A. Sotirov, “Heap Feng Shui in Javascript,” https://www.blackhat.com
/presentations/bh-europe-07/Sotirov/Whitepaper/bh-eu-07-sotirov-WP.
Office suite, designed to facilitate linkage to various lo-
pdf, 2007.
[75] Parvez, “Spraying the heap in seconds using ActiveX controls in
Microsoft Office,” https://www.greyhathacker.net/?p=911, 2015.
[76] McAfee, “Microsoft Kills Potential Remote Code Execution Vulnerabil-
ity in Office (CVE-2017-8630),” https://www.mcafee.com/blogs/other-b Embedded IE 0day Embedded OLE object
(Subset of Moniker) Parsing Problem
logs/mcafee-labs/microsoft-kills-potential-remote-code-execution-vul
18.92% 43.24%
nerability-in-office-cve-2017-8630/, 2017.

A PPENDIX EPS File

Parsing Problem End of life
A. Summary of Known Office Vulnerabilities 8.11% 27.03%

Our work on OLE vulnerability detection is motivated by an Still dangerous

59.46%
exhaustive analysis of all historical vulnerabilities associated Open XML Tag Hard to exploit
with Office products. The data comes from publicly disclosed Parsing Problem 13.51%
5.4%
research [64], [3] and databases [65], [66]. These vulnerabili-
ties can roughly be categorized into 7 types based on their root RTF Control Word
Parsing Problem
cause and Figure 12 illustrates their respective proportions in 8.11%
past occurrences. Other Office Logic
Vulnerabilities Moniker
Notably, Embedded OLE Object Parsing Problems are pre- 8.11% 8.11%
dominant, accounting for 43.24% of the vulnerabilities, and Fig. 12: CVEs Categorization

16
 CVE-2018-0798 attack surface which can be exploited for Office, and OLE
CVE-2018-0802
CVE-2018-4878
CVE-2018-5002
type vulnerabilities cannot be easily overlooked due to their
CVE-2014-1761
CVE-2014-4114
CVE-2016-4117
CVE-2016-7193
CVE-2018-8174
CVE-2018-8373 CVE-2020-0674 CVE-2022-30190
relatively high proportion. Therefore, it is essential to conduct
CVE-2014-6352 CVE-2016-7855 CVE-2018-15982 CVE-2020-0968 CVE-2022-41128
security checks on OLE objects.
2015 2017 2019 2021 2023
B. Weaponization Vulnerabilities
2014 2016 2018 2020 2022
Disguising Document. It is essential to study the activation
CVE-2015-1642 CVE-2017-0199 No CVE Found CVE-2021-40444 CVE-2023-36884
CVE-2015-2424
CVE-2015-2545
CVE-2017-0261
CVE-2017-0262
mechanisms for OLE within Winword.exe since attackers
CVE-2015-5119 CVE-2017-8570
CVE-2015-5122 CVE-2017-8759
often use various document formats to launch attacks. In
CVE-2017-11292
CVE-2017-11826 the context of OLE activation, a distinct difference in user
CVE-2017-11882
interaction requirements can be observed.
Fig. 13: Exploited vulnerabilities in the last 10 years. • For documents with the .doc extension, a user must
explicitly click the OLE object to activate it.
cal or remote objects. Inherently, it does not constitute a • Documents saved in the .docx format prompt a warning
vulnerability. Rather, the vulnerability emerges from the message upon an OLE object’s attempted activation.
execution policy within Office applications pertaining to • However, RTF documents (.rtf ) facilitate a more seamless
files fetched from remote links. For instance, opening a user experience, where a single click not only opens the
remotely loaded Excel file would typically pose no issue. document but also loads involved OLE components with-
However, when the files involved are of types such as out eliciting any warning notifications or necessitating a
HTA files and scripts, executing them directly can lead to secondary click for OLE activation.
security breaches due to improper handling by the execution
Given these characteristics, attackers exhibit a preference for
policy [59]. Microsoft subsequently disabled some CLSIDs
utilizing RTF files as the medium of choice for their malicious
in their fix. Vulnerabilities such as CVE-2017-0199, CVE-
endeavors. Consequently, for the purpose of conducting our
2017-8570, and CVE-2017-8579 are related to this issue.
experimental attack analysis, we have opted to select the RTF
• Office Embedded IE 0-day Vulnerabilities. Derived from
file format as the carrier for our test attack. However, due to
moniker vulnerabilities these utilize the StdOleLink func-
the limited popularity of RTF, such attack activities can easily
tion to load HTML content, which is then processed by
attract attention, leading attackers to disguise their format.
the IE parsing module. Exploits like CVE-2018-8174/8373
Examples in the wild include: 1) changing .rtf to .doc, i.e., by
and CVE-2020-0674/CVE-2021-40444 highlight attackers
modifying the file extension, or 2) converting .rtf into .docx:
exploiting IE’s VBScript and JavaScript 0-day vulnerabil-
i.e., by embedding an RTF within a .docx file, as seen in the
ities. As of August 2019, VBScript was disabled by default,
PoC for CVE-2023-36884 [73].
and JavaScript followed in January 2023. The lifecycle of Heap Feng Shui. In the context of Type-1 and Type-3
these vulnerabilities has also ended and is no longer a focal vulnerabilities, heap feng shui [74] is crucial. Our objective
point of research. is to ensure that the heap spraying is properly aligned with
• Embedded OLE Object Parsing Problems. CVE-2017-11882 controlled data at a known address, such as the canoni-
serves as a classic example involving a vulnerability with cal 0x0a0a0a0a, thereby circumventing mitigation strate-
the Equation Editor. eqnedt32.exe lacked mitigation mea- gies such as ASLR. Recent techniques leverage the use of
sures (DEP [69] & ASLR [70]) and was removed in the ActiveX [75] and OLE objects [1] for heap spraying [76].
public update of January 2018. Flash represented a subset This can be achieved through the utilization of Microsoft
of embedded OLE objects, categorized separately due to its Common Controls COM objects, including Toolbar objects
significant impact. Numerous security vulnerabilities have or other OLE controls, exemplified by TabStrip objects
been identified, leading Office Monthly Channel to block (as demonstrated in malware samples like CVE-2013-3906)
Flash execution starting in June 2018 [71]. This category and bitmap images. Heap memory allocation is facilitated by
includes not only memory corruption vulnerabilities but also embedding a specific number of these objects into documents.
logic flaws. Black Hat USA 2015 referenced these issues Stealthy DLL Delivery. However, for Type-2 vulnera-
during ”Attacking Interoperability: An OLE Edition” [72]. bilities, the exploitation methods are notably more diverse
DLL preloading vulnerabilities could lead to loading DLL and innovative. We have chosen the following two methods
files from the current working directory. Our study will place for carrying malicious files to conceal their presence for
emphasis on this class of vulnerabilities. imperceptible attacks:
Figure 13 shows the exploited vulnerabilities in the last • In a local archive scenario: An attacker might compress
10 years, from which we can observe a trend: the number a malicious DLL file along with the document. When
of exploitable vulnerabilities in the wild has decreased. One the victim decompresses it, the malicious document and
reason is that Office vulnerabilities are becoming harder to DLL file are both loaded. With Windows’ default settings,
find and exploit due to Microsoft’s patches. Additionally, hidden files are not displayed in File Explorer, allowing
many of these vulnerabilities have reached the end of their attackers to exploit this feature to conceal the malicious
lifecycle. Attackers urgently need to find a new potential DLL file from users’ notice.

17
 • In remote shared directories: When a user opens a Unlike with OLE, when the IE11 browser prepares
malicious document in a remote shared directory, the to load an ActiveX control, it first verifies an
malicious DLL file is also loaded from the shared direc- “allowlist” within the Registry key under the path name
tory. Attackers can modify protocols or control the shared HKLM\Software\Microsoft\Windows\CurrentVersion\
directory to further disguise the malicious DLL file, Ext\PreApproved. The associated DLL is only loaded into
making it undetectable to users. Since the shared directory the IE process if the ActiveX control’s CLSID is present on
is under the attacker’s control, protocol modifications can this list. This mechanism indicates that the loading process
also render the malicious DLL files invisible to users. for ActiveX controls in IE is selective, avoiding the loading
In the context of Type-2 DLL Preloading Attacks, successful of unvetted components. This highlights a clear disparity
exploitation requires the co-location of a malicious document between Windows’ method of addressing the security of OLE
and a corresponding malevolent DLL in the same directory. objects and IE’s handling of ActiveX controls. The latter
The Winword.exe process acknowledges two distinct types offers a more secure and filtered mechanism to prevent the
of Current Working Directory (CWD): execution of unaudited code. In summary, using third-party
1) Where the document is located: This directory serves as code without adequate verification constitutes an insecure
the CWD for instances of Winword.exe that are initiated design practice. Conducting security tests on these types of
through explorer.exe. Positioning a malevolent DLL data is highly effective, and employing sandboxing techniques
in this directory proves to be an effective strategy for to completely isolate them until they have been thoroughly
exploitation. validated by the system or deemed trustworthy by users is
2) C:\Users\name\Documents: An internal timer within advisable.
Office applications alters the execution context after a time
span of 10 seconds. Subsequently, Winword.exe modi-
fies the current directory to C:\Users\name\Documents,
which represents the default local file location according
to Office settings. Post the directory transition, attempts at
exploitation will no longer succeed.
Bypassing the Protected View Mode. Irrespective of the
vulnerability type, whether it be Type-1 and Type-3 memory
vulnerabilities or Type-2 logic vulnerabilities, a common chal-
lenge persists: to exploit these vulnerabilities, it is imperative
for an OLE object to be loaded by Office. However, the
Protected View Mode hinders the loading of OLE objects.
Herein, we introduce an innovative technique to circumvent
the Protected View Mode—exploiting the AutoRecover feature
intrinsic to Office components. The built-in save functionality
of Office components is designed to prevent user data loss;
Office will still open any previously unintentionally closed
documents alongside any new document that is opened after
an abnormal termination. However, the Protected View Mode
only offers protection during the first opening of a document.
Thus, a program crash could be beneficial to us. The crash
terminates the running process, and the next time a new pro-
cess starts, it will not enter Protected Mode. The vulnerability
we uncovered, when combined with a DoS flaw, can easily
circumvent the Protected View Mode to enable the execution
of malicious functions. In fact, there are numerous DoS
vulnerabilities in Office (including our findings in Table I),
but Microsoft states that DoS-type vulnerabilities do not meet
the criteria for security update services and will not receive
security updates.
C. Software Fault Isolation as Defense
Common mitigations include implementing stringent
checks, such as allowlisting and sandbox isolation [31] in
Office. However, such mitigations have not been strictly im-
plemented for OLE. We can observe a more robust approach
from Internet Explorer’s handling of ActiveX controls.

18