File Hijacking Vulnerability: The Elephant

in the Room

Chendong Yu ∗ , Yang Xiao ∗ § , Jie Lu† , Yuekang Li‡ , Yeting Li∗ , Lian Li† ,
Yifan Dong∗ , Jian Wang∗ , Jingyi Shi∗ , Defang Bo∗ and Wei Huo∗
∗
Institute of Information Engineering, CAS, China
†
SKLP, Institute of Computing Technology, CAS, China
‡ University of New South Wales

{yuchendong, xiaoyang}@iie.ac.cn, {lujie}@ict.ac.cn, {yuekang.li}@unsw.edu.au, {liyeting}@iie.ac.cn,

{lianli}@ict.ac.cn, {yifan.dong}@foxmail.com, {wangjian, shijingyi, bodefang, huowei}@iie.ac.cn
Attacker (Bob) File Paths Git Client User (Alice)
Abstract—Files are a significant attack vector for security
boundary violation, yet a systematic understanding of the vulner- ❌ C:\Users\Alice\.git\ ❌
>_
abilities underlying these attacks is lacking. To bridge this gap, we
present a comprehensive analysis of File Hijacking Vulnerabilities ❌ C:\Users\.git\ ❌ git log

(FHVulns), a type of vulnerability that enables attackers to breach ✔️ C:\.git\ ✔️ 2 Invoke

security boundaries through the manipulation of file content or 1 Create & Modify 3 Search & Use
file paths. We provide an in-depth empirical study on 268 well- 💥 4 Exploit
documented FHVuln CVE records from January 2020 to October
2022. Our study reveals the origins and triggering mechanisms of
Fig. 1: A file hijacking vulnerability identified by J ERRY
FHVulns and highlights that existing detection techniques have
overlooked the majority of FHVulns. As a result, we anticipate (CVE-2022-24765).
a significant prevalence of zero-day FHVulns in software. security boundaries can be easily breached by File Hijacking
We developed a dynamic analysis tool, J ERRY, which effec- Vulnerabilities (FHVulns). FHVulns represents a type of secu-
tively detects FHVulns at runtime by simulating hijacking actions rity flaw where an attacker can breach the security boundaries
during program execution. We applied J ERRY to 438 popular by manipulating files, including file paths and contents, and
software programs from vendors including Microsoft, Google, they can result in severe security issues such as arbitrary code
Adobe, and Intel, and found 339 zero-day FHVulns. We reported execution [37], privilege escalation [38], and data loss [39].
all vulnerabilities identified by J ERRY to the corresponding
vendors, and as of now, 84 of them have been confirmed or fixed, Fig. 1 depicts an example of an FHVuln (CVE-2022-
with 51 CVE IDs granted and $83,400 bug bounties earned. 24765) in the official Git client, caused by improper handling
of file paths, leading to arbitrary command execution. This
I. I NTRODUCTION vulnerability has existed for 18 years since the inception of
the Git project and is exploitable in all mainstream operating
My understanding is that sort of thing is outside of our systems, including Windows, Linux and MacOS. To illustrate
security model.... Together, I fear we have a vulnerability the exploitation of this vulnerability, let us assume Bob is the
on our hands that we need to fix, a bigger vulnerability attacker and Alice is the victim. ❶ Bob creates the C:\.git\ di-
than I originally anticipated. 1 rectory where he can modify any contents within the directory.
— A Git maintainer commented on CVE-2022-24765 Note that Bob does not have the right to modify the following
Modern operating systems, such as Windows and MacOS, directories: C:\Users\Alice\ and C:\Users\. However, anyone
implement security boundaries to separate code and data of in the Authenticated Users group can create directories under
different trust levels. Those boundaries serve as a funda- the path C:\. ❷ Alice invokes the Git command, such as git log
mental protection mechanism to isolate sensitive data and in her home directory (C:\Users\Alice\). ❸ If no .git\ directory
high-privileged execution environments [23]. However, these exists in the invoking directory C:\Users\Alice\, the Git client
will recursively search for .git\ in its parent directories. In this
1 All the excerpts in this paper are from discussions among developers while case, the Git client will locate the C:\.git\ directory created by
fixing the vulnerabilities reported by us. Bob and consider it as the Git home directory. ❹ Bob can put
∗ Also with Key Laboratory of Network Assessment Technology, CAS.
∗ Also with Beijing Key Laboratory of Network Security and Protection githooks [42] in the directory C:\.git\, which will be executed
Technology.
by the Git client. As a result, Bob can trick Alice into executing
∗ Also with School of Cyber Security, UCAS, Beijing, China arbitrary commands.
§ Yang Xiao is the corresponding author.
There have been various studies on different aspects of
FHVulns. For example, research [59], [70], [76], [77] focused
on detecting files with weak permissions, which can result
Network and Distributed System Security (NDSS) Symposium 2024 in security boundary violations. More recently, a number
26 February - 1 March 2024, San Diego, CA, USA
ISBN 1-891562-93-2 of works aimed at detecting dangerous file operations that
https://dx.doi.org/10.14722/ndss.2024.23038 could potentially breach security boundaries, such as process
www.ndss-symposium.org creation [45], [49], dynamic library loading [44], file cre-
 Initial Threat Model can be triggered at any stage of the software lifecycle, with
Attacker Victim the majority of vulnerabilities being triggered during the stage
Exploit 💥 of software program startup. No existing technique addresses
Hijacking Usage every stage in the software lifecycle to detect FHVulns.

Empirical Study B. Detection Tool

RQ-1 RQ-2 & 3
Based on our observations from the study, we have identi-
Created by Programs Sensitive Operation
fied a significant prevalence of zero-day FHVulns in software,
Searched by Programs Lifecycle Stage as existing detection techniques have overlooked the majority
of these vulnerabilities. To address this gap, we have developed
a new FHVuln detection tool called J ERRY 2 . J ERRY monitors
Fig. 2: The threat model of file hijacking vulnerabilities and the target software throughout its entire software lifecycle
overview of our empirical study. (Observation 3), and records executed file operation traces at
each stage. Next, J ERRY analyzes recorded execution traces to
ation/deletion [6], [9], and temporary directory creation [72]. discover file paths created or searched by the target software,
Despite considerable efforts in this direction, eradicating which may be generated or manipulated by attackers. Thus,
FHVulns remains challenging for researchers and practitioners. J ERRY is able to simulate the hijacking of files from both
For instance, existing static permission-checking techniques origins (Observation 1). Finally, J ERRY reports a vulnerability
are unable to detect the vulnerability shown in Fig. 1 due to the if the target software performs dangerous file operations on
lack of awareness of program behaviors. Through our analysis the hijacked files (Observation 2).
of existing studies, we have found that there is still a lack of
systematic study and thorough understanding of FHVulns. To assess the effectiveness of J ERRY, we constructed a
benchmark comprising 51 known FHVulns. Our evaluation
revealed that J ERRY successfully detected 50 out of the 51
A. Empirical Study
vulnerabilities with no false positives, surpassing all the base-
Prior to conducting the empirical study, we present a lines by detecting at least 13 more vulnerabilities. Furthermore,
summary of the threat model for FHVulns. As illustrated we applied J ERRY to 438 popular programs from notable
in Fig. 2, there are two necessary conditions that must be vendors such as Microsoft, Google, Adobe, Intel, Dell, etc. We
met in order to exploit an FHVuln: ❶ the attacker must be identified 339 previously unknown FHVulns in 176 programs
able to hijack certain files or directories (Requirement 1); ❷ and earned $83,400 through the bug bounty programs. Notably,
the vulnerable software must interact with the hijacked files some of these vulnerabilities had persisted for a long time, as
or directories through sensitive operations (Requirement 2). evidenced by the 18-year-old vulnerability depicted in Fig. 1,
Based on the threat model, we performed the first empirical which was present from the outset of the Git project. These
study on FHVulns. The objective of this study was to gain findings underscore the prevalence of FHVulns and the need
insights into the origins and triggering mechanisms of FHVulns to address them, as they have been overlooked in the past.
by addressing the following research questions:
We conducted an in-depth analysis of the newly detected
• RQ1 What are the origins of the hijacked files? vulnerabilities and yielded two findings for RQ1 and RQ2:
• RQ2 What types of operations are dangerous vulnerability- ❶ (Finding 1) The software-tailored search strategy has not
triggering operations? received extensive attention. ❷ (Finding 2) Reading operations
• RQ3 When in the software lifecycle (installation, uninstal- result in a higher number of FHVulns, and pose a higher risk
lation, ...) are file hijacking vulnerabilities triggered? than we thought. These findings are derived from new types
of FHVulns and thus they are not observable from existing
We collected 268 CVE records [35] documenting FHVulns FHVulns. Furthermore, we conducted a detailed discussion on
from January 2020 to October 2022 to conduct the empir- FHVulns in both Windows and Unix-like systems, identified
ical study. During the study, we made three observations, the reasons behind their widespread occurrence, and discussed
corresponding to the research questions. ❶ (Observation 1) the responsibilities for mitigating them. Our findings provide
Hijacked files can originate from two sources: files created valuable insights for future research in improving detection
by the vulnerable program with weak permissions, allowing tools and developing effective defenses against FHVulns.
attackers to manipulate them, or files created by the attacker
and encountered by the vulnerable program through specific This paper makes the following contributions.
search strategies. The first origin accounts for 10.1% (27) of • We, for the first time, provided a clear definition of
the total vulnerabilities, while the majority of vulnerabilities FHVuln’s threat model. Using this threat model, we
(89.9%, 241) come from the second origin. Existing techniques conducted the first empirical study on FHVulns, revealing
primarily focus on detecting files with weak permissions, i.e., the origins and triggering mechanisms of FHVulns.
vulnerabilities with the first origin, while missing out on the • We developed a dynamic analysis tool, J ERRY, to detect
majority of FHVulns. ❷ (Observation 2) Not all accesses FHVulns and applied it to 438 popular programs and un-
to hijacked files can result in vulnerabilities. For example, covered 339 zero-day FHVulns. All vulnerabilities identi-
operations such as querying file sizes are generally safe. fied by J ERRY were reported to the vendors, resulting in
Through our study, we identified six types of operations that
can lead to vulnerabilities. None of the existing techniques 2 J ERRY is a mouse featured in the cartoon Tom & Jerry. According to
address all six types of operations. ❸ (Observation 3) FHVulns certain myths, elephants are afraid of mice.

2
 84 of them being confirmed or fixed, with 51 CVE IDs FHVulns. The 268 FHVulns were evenly distributed among
granted and $83,400 in bug bounties earned. three authors of this paper and each author examined his
• We conducted an in-depth analysis of the newly dis- assigned FHVulns to label their corresponding hijacked file ori-
covered FHVulns and made new findings that were not gins (RQ1), sensitive operations (RQ2), and triggering lifecy-
observable from existing FHVulns. Additionally, we pro- cles (RQ3). Subsequently, the authors performed a peer-review
vided insights on multiple topics which can enable future process where each labeled vulnerability was cross reviewed
research. by the other two authors. in which each author reviewed the
labeling of the vulnerabilities assigned to the other two authors.
This paper is coupled with a companion website: https: Whenever discrepancies arose in the labeling results, the three
//sites.google.com/view/iamjerry. We will release J ERRY to- authors held a collective discussion to reconcile the differing
gether with our study results through this website. viewpoints. In cases where a consensus could not be reached,
an additional author was recruited to join the discussion until a
II. E MPIRICAL S TUDY resolution was achieved. The labeling and analysis of the 268
FHVulns took approximately three months.
This does happen, and is something we historically have
tried to prevent in the installer.
B. RQ1: Origins of Hijacked Files
— A Google developer commented on CVE-2023-2939
In this section, we first present the data collection and Observation 1: Most (89.9%) hijacked files are due to
analysis process for our empirical study, then conduct a the five search strategies employed by the programs and
comprehensive investigation on 268 FHVulns to answer the the underlying operating systems, while the rest come
research questions (RQ1-RQ3) introduced in Section I. Finally, from files created by programs with weak permissions.
we provide more details about the threat model and impacts
of FHVulns, derived from the study.
One of the necessary triggering conditions (Requirement
A. Data Collection and Analysis 1) requires the existence of hijacked files. Therefore, the key
to understanding FHVulns lies in understanding the origins
In order to conduct a comprehensive study of FHVulns, it of hijacked files, specifically where these files come from.
was essential to gather a substantial dataset of such vulnerabil- While it has been previously studied that files created by
ities. To achieve this, we compiled a dataset by collecting all programs with weak permissions can be hijacked, this origin
documented FHVulns from the CVE (Common Vulnerabilities only accounts for a small portion of the studied vulnerabilities,
and Exposures) database [35] for the period of January 2020 specifically 10.1% (27) of the total.
to October 2022. During this period, a total of 52,719 CVEs
were recorded. To focus specifically on FHVulns in programs The majority of hijacked files (241, 89.9%) are a result of
running on Windows, Linux, and Mac operating systems 3 , different search strategies employed by the studied programs
we excluded vulnerabilities in Web and IoT devices, as well and their underlying operating systems. When the absolute file
as memory corruption vulnerabilities like buffer overflows and path is not provided, operating systems or programs typically
double frees. This filtering process resulted in a dataset of use different file search strategies to locate the target file.
23,032 vulnerabilities. Frequently, those search strategies could potentially return
directories with weak permissions, which allows attackers to
Next, we utilized an iterative process to systematically plant malicious files. In our investigation, we have identified 5
identify FHVulns using keyword-based searches. Initially, we search strategies that could potentially return directories with
queried the CVE database with the following keywords: access weak permissions.
control, hijack, and permission. Then, we manually examined
each resulting vulnerability to filter out unrelated vulnerabil- ❶ Path Search Order (9, 3.4%). Nine vulnerabilities were
ities that did not fit our threat model (Fig. 2), and extracted found to be due to path search order in the underlying system.
additional keywords. This two-step process was repeated until In the Windows system, when a command is executed, the
no new keywords were extracted. In the end, the following system first attempts to locate the invoked executable file in
additional keywords: uncontrolled, symbol, search, and install, the current working directory (CWD) before searching paths
were extracted and used in our query. defined in the PATH environment variable. This strategy poses
a security risk when the CWD has weak permissions. Take a
Finally, we excluded vulnerabilities that lacked sufficient vulnerability in Github Cli [19] for example. When executing
details. Specifically, we only considered vulnerabilities that the command gh, the CLI client will try to locate the executable
had information describing the hijacked files, the triggering file git.exe in CWD. Once CWD (e.g., C:\ProgramData) has
stage, and the triggering file operations. For example, we weak permissions, attackers can place a malicious executable
filtered out CVE-2021-0057 [20], while retaining CVE-2020- file git.exe in the directory.
36167 [17]. In total, we collected 268 CVEs with sufficient
details. ❷ Linux Paths on Windows (12, 4.5%). Cross-system
migration is a common practice in software development.
After the data collection phase, our study followed the In our study, we identified 12 vulnerabilities resulting from
same empirical research approach in [80] to investigate the 268 improper path adaptation during migration from Linux to
3 We focused on the mainstream operating systems because they provide full- Windows. Specifically, when Linux paths do not exist on the
fledged security boundaries and the relevant vulnerabilities are more likely to Windows system, the system searches from the C:\ directory.
be reproducible. As C:\ is writable by default, this allows attackers to easily

3
plant malicious files. Take CVE-2019-5443 [11] for example. C. RQ2: Sensitive operations
The program curl reads the default configuration file /usr/local
/ssl/openssl.cnf. On windows, this file does not exist, and the One of the necessary triggering conditions (Requirement
system searches for the configuration file C:\usr\local\ssl\ 2) requires the vulnerable program to operate on hijacked
openssl.cnf instead. Since the path C:\ has weak permissions, files. Nevertheless, not all operations are susceptible to such
an attacker can easily hijack the file and control the engine attacks. Operations such as querying information (e.g., file
configuration, leading to arbitrary code execution. size), closing files, or enumerating files in a directory are
generally safe. In our study, we identified and categorized
❸ Unquoted Paths (46, 17.1%). A total of 46 vul- six types of dangerous operations that can potentially lead
nerabilities have been identified to be caused by unquoted to exploitation: moving, creating, deleting, reading, process
paths. An unquoted path refers to a file path that is not creation, and image loading.
enclosed in quotation marks. When an unquoted path contains
spaces or special characters, the Windows system truncates Observation 2: There are six types of dangerous oper-
the path and searches for the file using the truncated path. ations on hijacked files subject to file hijacking attacks.
For instance, in CVE-2020-13884 [14], the Citrix Workspace Among the six types of operations, process creation and
program invokes the CreateProcess API to execute the file image loading are most frequently exploited (accounting
TrolleyExpress.exe with an unquoted path C:\ProgramData\ for 28.4% and 45.1% of total vulnerabilities, respec-
Citrix\Citrix Workspace 1911\TrolleyExpress.exe. As a result, tively). The other four types of dangerous operations
Windows system truncates the path with spaces and searches are moving (1.1%), reading (7.1%), creating (8.2%), and
for the file using the path C:\ProgramData\Citrix\Citrix.exe deleting (10.1%).
, effectively loading the file Citrix.exe instead of Trolley-
Express.exe. Since the path C:\ProgramData\Citrix has weak
permissions, attackers could hijack Citrix.exe, resulting in ❶ Moving (3, 1.1%), ❷ Creating (22, 8.2%), and ❸
privilege escalation. Deleting (27, 10.1%). These three types of operations are
dangerous when accessing symbolic links, as discussed in
❹ Symbolic Links (52, 19.4%). Improper handling of CVE-2022-39845. Such operations on hijacked symbolic links
symbolic links has been found to result in 51 vulnerabilities. can lead to data loss and destruction of file integrity.
A symbolic link (also known as a soft link or symlink) is
a type of file in a computer’s file system that serves as a ❹ Reading (19, 7.1%). Programs commonly read different
reference or pointer to another file or directory [54]. When settings from configuration files, which are subject to file
accessing a symbolic link, the operating system follows the hijacking attacks. For instance, attackers may tamper with a
link to locate the target file or directory. CVE-2022-39845 [39] database connection string in configuration files which can
is such an example which leads to arbitrary directory deletion. redirect subsequent queries to a malicious database. Alterna-
Specifically, the uninstaller of Samsung Kies [28] attempts tively, attackers can insert harmful file paths in the configura-
to delete a non-existent directory C:\ProgramData\Samsung tion file, tricking the program to execute malicious code.
\DeviceProfile\Cache. Since attackers can have write per- ❺ Process Creation (76, 28.4%). Process creation in-
mission to C:\ProgramData\Samsung, an attacker can create volves creating a new process to execute a file, which can
the symbolic link C:\ProgramData\Samsung\DeviceProfile\ lead to arbitrary code execution if the file can be hijacked. For
Cache targeting an arbitrary directory, e.g., C:\. Consequently, instance, during installation, programs may download installa-
the uninstaller will delete all files in C:\. tion files from internet first then launch the downloaded files
❺ Dynamically Loaded Libraries (122, 45.5%). There to initiate the installation process. Hijacking the downloaded
are 122 vulnerabilities that can be triggered by loading dy- files can trick the programs to execute arbitrary commands.
namic libraries, such as dynamic link library (DLL) files on ❻ Image Loading (121, 45.1%). Image loading refers to
Windows and shared object (SO) files on Linux. When a loading dynamically loaded libraries, i.e., DLL and SO files on
DLL is loaded in Windows, the system searches for the target Windows and Linux, respectively. Hijacked libraries can lead
DLL in the CWD, system directories, windows directories, and to arbitrary code execution.
directories declared in the PATH environment variable, in that
order. On the other hand, when an executable file in Linux
loads SO files, the system first searches for loaded files under D. RQ3: Software lifecycle
the directories declared in the DT RPATH and DT RUNPATH We divide the entire software lifecycle into six distinct
sections of the executable file. If the search fails, the system stages: installation, uninstallation, updating, repairing, starting
then searches directories declared in the environment variable up, and usage. Each stage performs different types of actions.
LD LIBRARY PATH and in the configuration file /etc/ld.so.
conf, as well as in default directories /lib (/lib64) and /usr/lib
(/usr/lib64). During the search process for dynamic libraries, Observation 3: While the majority (62.3%) of FHVulns
the operating system looks for these libraries in searched are exploited during the Starting up stage, FHVulns can
directories. However, if a directory with weak permissions is be triggered at any stage during the software lifecycle,
encountered during this search, it could potentially allow an i.e., Installation (17.2%), Uninstallation (4.5%), Updat-
attacker to hijack the dynamic libraries that are to be loaded. ing (1.9%), Repairing (3.7%) and Usage (10.4%).
DLL hijacking [21], [41] has recently gained significant at-
tention, and most of the existing vulnerabilities studied in our ❶ Installation (46, 17.2%). 46 vulnerabilities are triggered
research are caused by DLL hijacking. during software installation. The installation stage typically

4
involves actions such as checking system requirements, copy- greater impact of FHVulns on security. Based on the sensitive
ing files, setting up configurations, etc. For instance, the operations (Section II-C) of the victim program, the impact
installation process often copies files from the installation of FHVulns can be mainly categorized into two types: code
media (e.g., a downloaded package) to specified locations on execution (e.g process creation) and data corruption (e.g delet-
the hard drive. It is worth noting that the installation process ing). Furthermore, it was observed that the number of FHVulns
often requires high privileges, and file hijacking vulnerabilities was much higher in Windows compared to Unix-like systems.
in this stage are particularly dangerous: attackers can hijack The reasons for this discrepancy will be explored in detail in
files in the installation process to gain high privileges. Section VII-A.
❷ Uninstallation (12, 4.5%). 12 vulnerabilities occur at
the uninstallation stage, all involving symbolic links. When III. T HE M ETHODOLOGY OF J ERRY
uninstalling a software, the uninstallation process removes all A. Overview
files (e.g., executable files and configuration files) associated
with the software from the system. As discussed in CVE-2022- Fig. 3 overviews our detection tool J ERRY at a high
39845 [39], the uninstallation process may follow a hijacked level. The tool processes the input target program together
symbolic link to delete arbitrary directories, resulting in data with a corresponding configuration file, which specifies how
loss and system damage. to interact with the target program at different stages in its
lifecycle. Details of configuration files are described in the
❸ Updating (5, 1.9%) and ❹ Repairing (10, 3.7%). website of the tool [55]. The tool monitors execution of the
The two stages perform similar actions, such as replacing an target system at each lifecycle stage and reports all discovered
existing version of software with a newer or correct version. vulnerabilities from the target program, together with key
Five and ten vulnerabilities are triggered in the two stages, events triggering the vulnerabilities.
respectively.
As shown in Fig. 3, J ERRY employs a four-step iterative
❺ Starting Up (167, 62.3%). The majority of vulnerabili- process to detect FHVuln. The intuition behind is to trigger
ties (167) happen during the starting up stage. When starting up as many program behaviors (execution traces) as possible. ❶
a program, the program usual conducts a series of tasks to ini- The Event Trace Generator executes the target program at each
tialize execution environments, including locating executable stage and records executed file operation traces. ❷ The FHVuln
files, loading dynamic libraries, reading configuration settings, Detector examines each execution traces and a FHVuln will be
etc. All above tasks are subject to file hijacking attacks. reported if the trace performs dangerous operations on hijacked
❻ Usage (28, 10.4%). Compared to other stages, actions files. ❸ The Path Pool Maintainer collects files encountered
in the usage stage are program specific and they can change in the event trace and puts them into the path pool. In this
significantly for different software programs, depending on the step, J ERRY also checks if the file refers to a normal file or
functionality provided by the program. For instance, a text a directory. ❹ The Path Hijacker tries to hijack and create
editor may create, modify, and delete files as the user edits each file in the path pool. In this regard, the path hijacker acts
and saves documents. Similarly, an email client may create as an attacker with no administrator/root privilege to mimic
and delete files as it downloads and stores emails. the hijacking actions. Since new files were created by the
Path Hijacker, the Event Trace Generator is triggered again to
Although the number of file operations during the usage discover more execution traces. This iterative process repeats
stage is much larger than in the other stages, FHVulns are until a fixed point where no new file is encountered.
more frequently observed in the installation and starting up
stages instead. Algorithm 1 describes the entire workflow of J ERRY. In
the main function (lines 27 – 42), J ERRY first splits the
E. Threat Model and Impact usage stage into several sub-stages consisting of UI interaction
sequences(lines 28 –31). For each stage, the loop (lines 32 –
Most FHVulns can only be exploited locally, but there are a 41) performs the iterative process until the path pool does not
few FHVulns that can also be exploited remotely [16]. In our change, i.e., no new paths is found.
threat model, we assume that the attacker has authenticated
into the operating system with normal user privileges. As a B. Event Trace Generator
result, the attacker has permissions to create files or file paths
in some directories (e.g. C:\ProgramData in Windows and /tmp The event trace generator in J ERRY (lines 1 – 6 in
in Linux). As shown in Fig. 2, the attacker is able to control Algorithm 1) interacts with the target program to trigger as
(RQ1) certain files or file paths. Then, the victim process many different execution traces as possible. Observation 3
(program) will interact (RQ2) with the hijacked files or file indicates that FHVulns can be triggered at any stage of the
paths in software lifecycle (RQ3). By exploiting FHVuln, the software lifecycle. At distinct stages, the target programs
attacker can attain the privileges of another user (horizontal are interacted differently. Specifically, J ERRY leverages the
privilege escalation) [18] or even escalate privileges to become package manager to interact with the target program during the
a root/administrator (vertical privilege escalation) [13]. installation, uninstallation, updating, and repairing stages. For
the starting up and usage stages, J ERRY employs a customized
Out of the collected FHVulns, 86.6% were rated as critical user interface (UI) explorer to interact with the target program.
or high based on their Common Vulnerability Scoring Sys-
tem (CVSS) score [40], which indicates the severity of the All stages, except for the usage stage, do not require
vulnerability. In comparison, out of all 52,719 vulnerabilities, complex interactions with the target program. For instance, for
only 56.8% were rated as critical or high, highlighting the the installation stage, the package manager can automatically

5
 Jerry
4
Path Hijacker Path Pool

1 3
Event Trace Generator Path Pool Maintainer

Package Manger Yes Path Type

Check Path Type
Inputs (Un)Install/Repair/Update Exists Pair
Event Path Type
Trace No Inference
Configuration File UI Explorer
Outputs

Start Up/Use Vulnerability

Target Program 2
FHVuln Detector Report

Fig. 3: Overview of J ERRY.

Event Trace Generator FHVuln Detector Path Pool Maintainer Path Hijacker
Event Trace (Before Creating C:\.git\ as a directory) Iteration 1 Iteration 1 Iteration 1 Iteration 1
Process Info Path Info Operation Info
1 PID git log git.exe ... C:\Users\Alice\.git\ Not Exist No Permission Unknown ... IRP_MJ_CREATE

2 PID git log git.exe ... C:\Users\.git\ Not Exist No Permission Unknown ... IRP_MJ_CREATE

3 PID git log git.exe ... C:\.git\ Not Exist Has Permission Unknown ... IRP_MJ_CREATE Infer Type Create Dir

Event Trace (After Creating C:\.git\ as a directory) Iteration 2 Iteration 2 Iteration 2 Iteration 2
...
3 PID git log git.exe ... C:\.git\ Exist Has Permission Directory ... IRP_MJ_CREATE

4 PID git log git.exe ... C:\.git\config Not Exist Has Permission Unknown ... IRP_MJ_CREATE Infer Type Create File

Event Trace (After Creating C:\.git\config as a file) Iteration 3 Iteration 3 Iteration 3 Iteration 3
...
4 PID git log git.exe ... C:\.git\config Exist Has Permission File ... IRP_MJ_CREATE

5 PID git log git.exe ... C:\.git\config Exist Has Permission File ... IRP_MJ_READ Report 💥

(a) Event Trace Generation (b) FHVuln Detection (c) Path Analysis (d) Path Hijacking

Fig. 4: A demonstration of how J ERRY detects the vulnerability in Fig. 1.

invoke the installation program without extra user interactions. permissions to modify the content of an existing file. In the
However, the usage stage may involve complex command line scenario of a non-existent file path, J ERRY relies on the ACL
options or graphical user interface (GUI) interactions. For of its existing parent directory to determine the feasibility of
target programs with command line interfaces, J ERRY acquires creating files or file paths within it. The performed operation
the command line options from the configuration file and gen- is the corresponding windows driver API to access the file. All
erates different option combinations to use the program. Take above information are included in the vulnerability report to
the Git client as an example, J ERRY can generate commands help reproduce the bug.
like git status or git log according to the configuration file. For
target programs with graphical user interfaces (GUI), J ERRY C. FHVuln Detector
uses an automated GUI testing tool [89] to interact with the
program and performs simple actions such as button clicking. The FHVuln detector (lines 7 – 12 in Algorithm 1) ana-
As such, J ERRY may miss program behaviors requiring com- lyzes event traces to identify FHVulns. If an event performs
plicated user interactions, suggesting false negatives. dangerous operations over a hijacked file, it is considered as
vulnerability and J ERRY will generate a vulnerability report
J ERRY monitors target program execution and records file recording the event trace with the triggering event highlighted.
access events. Fig. 4 shows an example of the event traces In Fig. 4, event ❺ in iteration 3 performs the
for the vulnerability in Fig. 1. Each event provides detailed IRP MJ READ [26] operation on C:\.git\config, which is a
information describing the accessing process, the accessed hijacked file. Hence, J ERRY reports it as a vulnerability. Note
files, and the performed operation. For the accessing process, that event ❹ in iteration 3 is not a bug-triggering event since
we record its process ID, its command line option (or GUI the operation IRP MJ CREATE [25] only opens a stub to the
events), and the executed program. For the accessed files, we object pointed by the path.
record file names, their existence and permissions (whether can
be manipulated by the path hijacker or not), and their types The impact of FHVulns is closely associated with sensitive
(directory or file). J ERRY evaluates whether files or file paths operations. Of the six categories of sensitive operations, the
are susceptible to hijack by examining the access control list impact of five can be directly determined by the operation
(ACL) [31]. It verifies whether attackers possess the necessary itself. Process creation and image loading enable arbitrary

6
 Algorithm 1: The workflow of J ERRY ing a normal file, programs commonly check the existence
Input: p: the target program under test of its parent directory while such a check is unnecessary
Input: c: the corresponding configuration file when accessing a directory. For instance, in Fig. 4, event ❸
Output: R: the set of vulnerability reports in iteration 1 accesses the C:\.git\ path without checking the
1 def get event trace(p,c,stage): parent’s existence. Hence, the path C:\.git\ is regarded as a
2 if stage ∈ directory. In contrast, event ❹ in iteration accesses the path
{IN ST ALL, U N IN ST ALL, REP AIR, U P DAT E} C:\.git\config after opening a stub for C:\.git\. Thus, it is
then inferred as a file. In addition to the above heuristic, J ERRY also
3 trace ← run package manager(p, c, stage); applies other heuristics such as using common file extensions
4 else (e.g., exe and dll) to recognize typical files. If a path is involved
5 trace ← interact with ui(p, c);
6 return trace;
in directory-specific operations (such as children traversal),
7 def detect fhvuln(trace): then it is identified as a directory.
8 for event ∈ trace do As a fallback, J ERRY also employs a trial-and-error mech-
9 if is vulnerable(event) then anism 4 to handle paths whose types cannot be inferred. An
10 r ← generate report(trace);
11 R ← R ∪ {r};
encountered path with unknown type is by default considered
12 return r; as a file. If the file is used by file-specific operations later on,
13 def update path pool(P, trace): then the guess is correct. Otherwise, if the path is accessed by
14 P ′ ← collect paths(trace); directory-specific operations, the guess is wrong and the path
15 for path ∈ P ′ do hijacker will create a directory instead.
16 if path ∈ / P then
17 if exist(path) then E. Path Hijacker
18 type ← check type(path);
19 else The path hijacker (lines 23 – 26) mimics the behavior of
20 type ← inf er type(path); an attacker by creating and hijacking non-existent files for the
21 path.type ← type; target program. For exe and dll files, J ERRY replaces them
22 P ← P ∪ {path}; with manually crafted files. For other file types, it utilizes a
23 def manipulate path(P): specially created blank file consisting of newline and space
24 for path ∈ P do characters for hijacking. This is because J ERRY aims to ensure
25 if ¬ exist(path) then
26 create f ile or dir(path);
that the program runs as possible even after the file has
27 def main(p , c ): been hijacked. If the file is accessed by creating, moving or
28 R←∅; deleting operations, the path hijacker will create a symbolic
29 c.stages ← {IN ST ALL, U N IN ST ALL, link pointing to a special location (e.g. C:\symbolic\) for
30 REP AIR, U P DAT E, ST ART U P }; monitoring.
31 c.stages ← c.stages ∪ explore ui usage() ;
32 for stage ∈ c.stages do To act like an attacker, the path hijacker is a standalone
33 trace ← [ ]; process in J ERRY, which executes with the permissions of a
34 P ← ∅; normal user without root or administration rights.
35 do
36 P ← P; IV. I MPLEMENTATION
37 trace ← get event trace(p, c, stage);
38 R ← R ∪ {detect f hvuln(R, trace)}; We implemented J ERRY on Windows. The implementation
39 update path pool(P, trace); consists of 4.5k lines of C code based on the Microsoft
40 manipulate path(P); Windows Driver Kit, together with 2.5k lines of Python code.
41 while P ̸= P ; Instead of elaborating every step of J ERRY in detail, we focus
42 return R ; on the implementation details of the event trace generation step
since this step involves many external tools to interact with the
target program and monitor its execution.
code execution, while creating, moving, deleting operations Event Trace Generator. The primary objective of this
result in data corruption. Only FHVulns related to reading module is to automate the installation, uninstallation, updating,
operation require manual analysis, as reading data alone may repairing, starting up and usage of targeted programs. We
not necessarily pose an actual security impact. utilized Chocolatey [65], a command line manager to install,
uninstall and update software. For repairing, we monitor the
D. Path Pool Maintainer behavior of installation and implement it for software packaged
by Windows Installer [57] We start up the target software by
The path pool maintainer (lines 13 – 22 in Algorithm 1)
directly invoking the program in the command line.
infers the types (directory or file) of newly encountered files
and adds them to the path pool. It is trivial to acquire the To automate the use of targeted programs, J ERRY supports
type of an already existing file by simply querying the file. command-line interface (CLI) and graphical user interface
However, it is tricky to analyze whether a non-existent file is (GUI) in a different manner. For software with command-line
a directory or a normal file. Hence, J ERRY applies a simple interface, J ERRY automates its usages by randomly combing
heuristic to infer file types according to their usages.
4 For the clarity of presentation, this trial-and-error mechanism is not
The heuristic is based on the observation that when access- reflected in Fig. 3 and Algorithm 1.

7
distinct command-line options in the corresponding configu- TABLE I: The Overall Evaluation Results on Known
ration file. For software with GUI interface, we utilize the Vulnerabilities. The column # reported means the number of results
UIAutomation tool [89] to automate button click events. reported by corresponding tool.

Event Monitor Module. We have developed a monitoring Tool # reported TP FP FN Precision Recall
tool at the kernel driver level using the Minifilter frame-
PrivescCheck 34 20 14 31 58.8% 39.2%
work [73] to track the events of files. J ERRY uses inter- J ERRY-Crassus 44 37 7 14 84.1% 72.5%
faces [24] provided by Minifilter to perform hooking before J ERRY 50 50 0 1 100.0% 98.0%
each file operation function. If the target file exists, J ERRY
records its permissions and path. Otherwise, when the parent unavailability of the LPET tool and the limited information
directory of the file has weak permissions, J ERRY records the on its hijacking verification mechanism, making it challenging
permission and path of the parent directory. to replicate. However, LPET shares a similarity strategy with
Crassus, and we can estimate the effectiveness of LPET for
V. E VALUATION qualitative analysis based on the strategic differences between
these two tools.
I would not be at all surprised if many holes remain.
— A Git maintainer commented on CVE-2022-41953 Metrics. In this evaluation, we adopt two commonly used
metrics, namely positive predictive value (a.k.a precision) and
A. Evaluation Setup true positive rate (a.k.a recall), to compare the effectiveness of
J ERRY against the two baseline tools. Eq. (1) and (2) show the
We evaluated the effectiveness and efficiency of J ERRY by
equations to compute precision and recall, where TP, FP and
comparing it against three baseline tools in detecting known
FN represent true positives, false positives and false negatives,
vulnerabilities, and subsequently applying the tool to detect
respectively.
new vulnerabilities in widely used real-world projects.
Benchmarks. We evaluated J ERRY with two distinct TP
P recision = (1)
benchmark suites: the “known vulnerability suite” and the TP + FP
“unknown vulnerability suite”. ❶ The known benchmark suite TP
Recall = (2)
is extracted from the 268 CVEs studied in Section II, where TP + FN
51 reproducible CVEs are included. Among the rest of the
217 unreproducible CVEs, 147 lack sufficient reproducing Evaluation Configuration. Installation and updates of a
instructions, 52 only exist in unavailable vulnerable versions, software will change the system state, which may not be
and we fail to install the target programs for the remaining undone. To avoid such impacts, we conduct our experiments
18 CVEs. The details of each CVE in the known benchmark on a virtual machine hosted on a Lenovo laptop with 14 Intel
suite, including its CVE ID, affected programs, triggering Core i9 processors, 32 GB of memory and a 512 SSD drive,
stages, and triggering operations, are listed in TABLE A1 running on Windows 11. The virtual machine is a VMWare
in the appendix. ❷ The unknown benchmark suite consists image configured with 4 CPU cores, 16GB of memory, and a
of 438 popular software programs. We collected a total of 200 GB hard drive, also running Windows 11.
663 software packages, including all software with more than
100,000 downloads on Chocolatey [65], and all pre-installed
Windows software from top PC vendors including DELL, B. Effectiveness on Known Vulnerabilities
Lenovo, and HP. Among the 663 software packages, 225 pack- We evaluated the effectiveness of J ERRY on the 51 known
ages were excluded because they either had not been updated vulnerabilities by comparing it with two existing tools, Privesc-
after 2020, or could not be successfully installed. Finally, Check and J ERRY-Crassus. The overall evaluation results are
we obtained a total of 438 software programs. All programs shown in TABLE I. We also give the detailed results for each
in this suite are widely-used applications and vulnerabilities CVE in the appenix (TABLE A1).
reported in the suite will have significant security impacts.
Details of the unknown vulnerability suite will be revealed on Overall Results. J ERRY significantly outperformed both
the website [55]. baseline tools with respect to precision and recall. It success-
fully identified 50 out of 51 vulnerabilities without any false
Baselines. We compared J ERRY against three base line positives. In other words, the precision and recall of J ERRY
tools: PrivescCheck, J ERRY-Crassus and LPET. Privesc- are 100.0% and 98.04% (50/51), respectively. In comparison,
Check [49] is a static tool which detects executable files PrivescCheck and J ERRY-Crassus were less effective. Specif-
with weak permission by scanning the access control metadata ically, PrivescCheck (resp. J ERRY-Crassus) detected 20 (resp.
provided by Windows. Crassus [36] detects FHVulns by ana- 37) out of 51 vulnerabilities with a precision of 58.8% (resp.
lyzing event traces monitored by ProcMon [50], identifying 84.1%) and a recall of 39.2% (resp. 72.5%).
existing or non-existent exe files, dll files and openssl.cnf
which can be hijacked. However, Crassus does not have a In addition, we analyzed the vulnerabilities commonly
built-in module to automatically trigger the events. To enable a detected by each tool to further evaluate the effectiveness of
meaningful comparison, we extended Crassus by incorporating J ERRY. As shown in TABLE A1, the vulnerabilities detected
the event trace generator module and replaced our monitor with by PrivescCheck and J ERRY-Crassus can all be identified by
ProcMon, named it J ERRY-Crassus. LPET [72] is a dynamic J ERRY. Besides, there are 13 vulnerabilities uniquely detected
tool designed to discover FHVulns when using software. by J ERRY, whereas no vulnerabilities can be uniquely detected
We cannot directly compare J ERRY with LPET due to the by any baselines. The result echoes the high effectiveness of

8
J ERRY in terms of the number of identified known vulnerabil- So far, a total of 84 of the identified vulnerabilities have been
ities. confirmed (and fixed). Among the 84 confirmed vulnerabilities,
51 were assigned CVE IDs, and 21 were rewarded with a
FN Analysis for J ERRY. J ERRY only missed one vul- total of $83,400 bug bounties. TABLE II shows part of the
nerability, which all other baseline tools also missed. After real-world vulnerabilities that were reported by J ERRY and
investigation, we found that the missed vulnerability was CVE- confirmed by developers. Meanwhile, we also applied the
2020-26284 [15], which existed in the file parsing module of two other baseline tools to explore these projects, and the
the Go language standard library. The vulnerability required results were not satisfactory. Specifically, PrivescCheck only
parsing specific content and invoking the relevant module to found 39 vulnerabilities (11.5% of J ERRY), while J ERRY-
trigger it. Crassus detected 143 vulnerabilities (42.2% of J ERRY). In
FP/FN Analysis for PrivescCheck and J ERRY-Crassus. all 143 vulnerabilities detected by J ERRY-Crassus, 6 FHVulns
We also analyzed the false positives/false negatives in Privesc- result from issues with openssl.cnf, 124 FHVulns are due
Check and J ERRY-Crassus. For false positives, PrivescCheck to overly-permissive dll files, and 13 FHVulns are related
reported 14 false positives, which resulted from its method to exe files. Since there are no FHVulns related to bat files
of scanning the parent directory permissions when encounter- in our evaluation, LPET will report 137 FHVulns, excluding
ing an executable. In particular, if the parent directory has the 6 related to openssl.cnf. This demonstrates the significant
weak permissions, it will report a potential FHVuln as a advantage of J ERRY over PrivescCheck, J ERRY-Crassus and
result of DLL hijacking. However, it is possible that the exe- LPET in discovering zero-day FHVulns.
cutable is not loading any missing DLLs from that directory, FP Analysis for J ERRY. J ERRY has reported 21 false
which results in false positives. In addition, for non-existent positive issues, all of which are related to read operation.
files, J ERRY-Crassus reported all the recorded dll files and For example, we discovered instances where a program reads
openssl.cnf where the parent directories have weak permissions file content without utilizing it or where the data is rendered
as FHVulns. However, it did not verify successful hijacking useless. For instance, the Azure CLI leverages the “knack”
operations, leading to seven false positives. Expanding J ERRY- package to load configuration settings, utilizing a bottom-up
Crassus to include other file types may increase true positives, search policy to locate the “.azure/config” file. This process
but also results in much more false positives without post- involves reading the contents of all identified files during
hijack operation verification. initialization. However, the configuration settings used can be
For false negatives, excluding the vulnerability (i.e., CVE- controlled by a parameter, making the content of the configura-
2020-26284) mentioned above that none of the three tools tion file useless. It is worth noting that some configuration files
could detect, PrivescCheck failed to detect 30 vulnerabilities may not be suitable for Windows systems due to the use of
in total. 20 of these vulnerabilities resulted from its neglect Linux file paths, which may lead to hijacking. Additionally, it
of certain operations that could cause vulnerabilities, such is important to mention that certain configurations can only be
as reading (10), creating (5), deleting (4), and moving (1). utilized in Linux systems (e.g., C:\etc\gcrypt\fips enabled).
Moreover, PrivescCheck missed one vulnerability (i.e., CVE- Case Studies. We present two examples to demonstrate
2020-15145) because it only scanned the permissions in the how the user interface exploration and path inference features
installation directories listed in the registry. The remaining nine of J ERRY facilitate the detection of critical FHVulns.
vulnerabilities were overlooked because it only considered the
vulnerabilities during the installation phase. Similarly, J ERRY- Case-A. While testing Visual Studio, the UI Explorer of
Crassus missed 13 vulnerabilities, with CVE-2020-26284 ex- J ERRY initially clicks the button labeled as “Git” and opens a
cluded. Among them, 10 false positives were reported because menu list. Subsequently, from the menu list, the UI Explorer
the tool did not take into account the impact of creating (5), selects the item labeled as “Open git in cmd”. Visual Studio
deleting (4), and moving (1) operations. In addition, it only then searches for git.exe in CWD, which has weak permissions.
scanned a limited range of openssl.cnf, resulting in missing 3 J ERRY detects this file operation and places a malicious git.exe
out of 10 vulnerabilities related to read operations. in CWD. Moreover, it confirms that the malicious git.exe is
successfully loaded into Visual Studio. J ERRY automatically
Comparison with LPET. LPET shares similar detection documents the detailed steps of the entire exploit process, as
rules with J ERRY-Crassus but extends the rule set to include well as the potential security impacts (i.e., arbitrary code ex-
bat files while excluding the openssl.cnf file. As LPET contains ecution) for this vulnerability. We reported this FHVuln along
a verification module, it can detect 33 FHVulns without any with the generated steps to MSRC and received confirmed
false positives. feedback quickly. Due to its severity, MSRC rewarded us with
$30,000.
C. Effectiveness on Unknown Vulnerabilities
Case-B. Gem [52] is a package manager of Ruby pro-
To verify if J ERRY is able to identify unknown vulnera- gramming language. While starting up, Gem attempts to access
bilities, we further applied J ERRY to 438 real-world projects. a file or directory with the path C:\ProgramData\gemrc. As
It found 339 zero-day vulnerabilities in 176 out of 438 the path does not exist, Gem stops to access the file or
software programs with 21 false positives. Among the 339 directory and continues executing the rest of the code. During
identified vulnerabilities, 126 were attributed to new paths testing, J ERRY detected this behavior and attempted to create a
discovered during the testing process. Some of these zero-day malicious file with the path C:\ProgramData\gemrc for Gem.
vulnerabilities were found in high impact software programs Gem was able to access the file and continued executing
with over 500 million downloads, such as Adobe Reader DC, the rest of the code. As the rest of the code includes a
Chrome, Visual Studio, Git for Windows, VMware and so on. reading operation, the malicious file was successfully loaded

9
TABLE II: Part of Real-world FHVulns Detected by J ERRY TABLE III: Average Running Time (s) of J ERRY-NoInfer
and Confirmed by Developers. The abbreviations Ins, Uni, Up, Rep, and J ERRY. The columns Ins, Uni, Upd, Rep, and SU mean Installation,
SU and Us represent Installation, Uninstallation, Updating, Repairing, Starting Uninstallation, Updating, Repairing, and Starting Up, respectively.
Up and Usage, respectively. The abbreviations PC, IL, RD, CT, MV and
DT represent Process Creation, Image Loading, Reading, Creating, Moving Tool Ins Uni Upd Rep SU Usage
and Deleting, respectively. The Symbol “⋆” indicates that the corresponding
software is pre-installed. J ERRY-NoInfer 8039.4 1417.6 3871.9 1206.9 556.17 33.8
J ERRY 1128.1 414.2 893.5 254.7 115.5 15.8

No. Software Name # Download Stage Operation Status

1 Adobe Reader DC 465,124,436 Ins CT Confirmed by Gem. Since C:\ProgramData\gemrc contains a URL to the
2 Adobe Reader DC 465,124,436 Uni DT Confirmed central repositories, this FHVuln affects thousands of software
3 Chrome 97,544,900 Ins CT CVE-2023-2939 packages built with Ruby. In other words, attackers can hijack
4 Chrome 97,544,900 Ins RD Fixed links that lead to software package downloads. By redirecting
5 Firefox 40,111,618 Uni DT CVE-2023-4052 these links to repositories under their control, attackers can
6 JRE8 24,394,580 Ins CT Fixed plant malicious code in the software within the repositories.
7 Visual Studio 10,670,579 Ins CT CVE-2023-21567 This nefarious activity has the potential to cause significant
8 Visual Studio 10,670,579 Us PC Confirmed damage to the software supply chain.
9 Git for Windows 10,256,420 Ins PC CVE-2022-31012
10 Git for Windows 10,256,420 SU RD CVE-2022-24765 However, all existing methods are unable to detect it as
11 Git for Windows 10,256,420 Us PC CVE-2022-41953 they can only be performed on existing files.
12 Git for Windows 10,256,420 Us PC CVE-2023-23618
13 Git for Windows 10,256,420 SU PC CVE-2023-29012
D. Efficiency
14 Git for Windows 10,256,420 SU RD CVE-2023-29011
15 Openssh for Windows 5,884,392 SU RD CVE-2022-26558 In addition to the effectiveness of J ERRY, another im-
16 Sysinternals 5,859,086 SU IL Confirmed portant evaluation metric is the time it takes to detect these
17 Nodejs 5,353,689 SU RD Confirmed
vulnerabilities. In this section, we evaluated the efficiency of
18 DellCommandUpdate 4,210,082 Ins DT CVE-2023-23698
J ERRY by performing an ablation study on all 489 software
19 DellCommandUpdate 4,210,082 Ins CT CVE-2023-28071
programs from the benchmark and real world. In particular, we
20 Visual Studio Code 4,172,599 Us PC CVE-2022-38020
21 Dotnet SDK 3,016,753 SU IL CVE-2023-28260
considered J ERRY-NoInfer, which does not use our proposed
22 Dotnet SDK 3,016,753 Us IL CVE-2023-33126
path type inference and tested these paths which cannot decide
23 Dotnet SDK 3,016,753 Us RD CVE-2023-33135
whether file or directory by our heuristics directly one by one.
24 iTunes for Windows 2,382,592 SU IL CVE-2023-32351 Our experience shows that the strategies we used can increase
25 Dropbox 2,290,276 Uni DT Confirmed speed without reducing false positives.
26 Azure Cli 1,197,993 SU IL Fixed
The results of this evaluation are shown in TABLE III. As
27 Gvim 1,897,408 Ins PC CVE-2022-37172
28 Php 1,665,675 Ins PC CVE-2022-45307
we can see here, in terms of average running time, J ERRY
29 Azure pipeline agent 1,376,209 Ins PC CVE-2022-45306
achieved at least 2.14 faster in the usage stage and 7.13 faster
30 Ruby 1,369,541 Ins PC CVE-2022-45301
in the installation stage because there are only a few paths
31 Ruby 1,369,541 SU RD Fixed that can be hijacked in the usage stage, but in the installation
32 StrawberryPerl 1,187,107 Ins PC CVE-2022-36564 stage, there are much more paths that can be hijacked than
33 Intel Software 1 945,347 Ins CT Fixed other stages. Therefore, overall, J ERRY significantly reduces
34 Intel Software 1 945,347 Ins DT Fixed its running time while ensuring the same effect.
35 VMWare Tools 819,878 SU RD CVE-2022-22977
36 VMWare Tools 819,878 SU DT Fixed
E. Responsible Disclosure
37 Msys2 683,078 Ins PC CVE-2022-37172
38 Bazel 314,066 SU RD Confirmed As demonstrated in Section II, FHVulns can lead to se-
39 MySQL 278,425 SU PC CVE-2022-39403 vere consequences, such as arbitrary code execution, privilege
40 MySQL 278,425 SU RD CVE-2022-39402 escalation, data loss, and open redirect attacks. In light of
41 MySQL 278,425 SU RD CVE-2022-39404
these risks, we took the responsibility of disclosing all the 339
42 Github Cli 226,930 SU PC Fixed
vulnerabilities we identified in 176 software programs with
43 ZeroTierOne 177,047 SU IL CVE-2022-1316
a detailed report and Proof of Concept (PoC) to vendors of
44 WPS Office 122,094 Ins IL Fixed
45 WPS Office 122,094 Ins IL Fixed
the affected software. We reported 48 of these vulnerabilities
46 WPS Office 122,094 SU IL Fixed
via third-party vulnerability coordination platforms, including
47 Intel Software 2 ⋆ Ins CT Fixed
HackerOne [43], Bugcrowd [34], and Intigriti [46]. Further-
48 Intel Software 3 ⋆ Ins PC Fixed more, we reached out to 107 companies or organizations
49 Intel Software 4 ⋆ Ins PC Fixed to report 291 vulnerabilities through their dedicated email
50 Intel Software 5 ⋆ SU IL Fixed addresses and forms for reporting security vulnerabilities.
51 Dell Command Intel ⋆ Uni DT CVE-2023-23697 As per responsible disclosure practices, we will not publicly
vPro release any unfixed vulnerabilities until the developers address
52 Dell Command Inte- ⋆ Uni DT CVE-2023-24572
gration Suite
them. It is worth noting that all vulnerabilities with detailed
53 Dell Command Moni- ⋆ Uni DT CVE-2023-24573 information in our paper have been fixed by developers. At
tor present, 84 of the identified vulnerabilities have been either
54 Dell Command Moni- ⋆ Uni DT CVE-2023-28049 confirmed or fixed, and 51 CVE identifiers have been assigned
tor
to these issues.

10
 2% 1%
Weak Permission 1% Process Creation Installation
5%
Linux Path Search In Windows 5%
17% Image Loading Uninstallation
Unquoted Path Search 17%
30% 32% Reading 31% Updating
Path Search Order
Creating Repairing
Symbol-Link Follow Search 30% 60%
4% 30% 3%
23% Moving Starting Up
Dynamic-Link Library Search 1%
6%
3% 0%
Bottom-up Search Deleting Usage

(a) Origins (b) File Operations (c) Stages

Fig. 5: Distribution of new FHVulns on different origins, file operations, and stages.

VI. A NALYSIS OF N EW FHV ULNS FHVulns, we found a new type of search strategy, the bottom-
up search strategy, which is software-tailored. The bottom-
To provide guidance for future studies on FHVulns, we up search strategy employs an iterative approach, starting
conducted an empirical analysis of the 339 newly detected the search in the current working directory and progressively
vulnerabilities to re-address RQ1 and RQ2. navigating upwards towards parent directories. Unlike built-in
search strategies, this new type of strategy is OS-neutral and
A. Distribution of New FHVulns also results in eight FHVulns in our real-world experiment
results. For instance, the vulnerability illustrated in Fig. 1
Origin Distributions. Fig. 5(a) shows the distribution remained concealed in Git for 18 years, from the initial release
of new FHVulns based on their origins. The chart clearly of Git. Another similar FHVuln, CVE-2023-33135 [75], was
indicates that weak permissions of existing files was the most found in Dotnet SDK [48], which is the core functionality
common origin of FHVulns, accounting for more than one- required to create Dotnet projects. Dotnet uses its own search
third (32%) of all occurrences. Dynamically loaded libraries strategies to locate the .config directory from the CWD to
was the second most frequent origin, accounting for 30% of the the root directory. When Dotnet is executed in a directory
FHVulns. The remaining 38% was distributed among several without a Dotnet project, it will eventually locate C:\.config
other categories, including Linux paths on Windows (4%), , which can be hijacked by the attackers as C:\ is world-
unquoted paths (3%), path search order (6%), and bottom-up writable. By controlling the configuration in C:\.config\dotnet
search (2%). −tools.json, attackers can execute arbitrary code by making
Dotnet download malicious tools from websites.
Operation Distributions. Fig. 5(b) illustrates the distri-
bution of various file operations. The chart shows the most
prevalent types of file operations are reading (30%) and
image loading (30%), followed by process creation (17%) and
Finding 2: Reading operations result in more FHVulns
creating (17%). On the other hand, deleting (5%) and moving
than we studied (30.4% vs 7.1%), and they are more
(1%) are the least frequent operations.
dangerous than we think.
Stage Distributions. Fig. 5(c) presents the distribution of
various stages. The starting up stage accounts for the majority
of FHVulns, representing 60% of the total occurrences. The
installation stage follows with 31%, while the remaining Observation 2 reveals that there are six types of sensitive
stages, namely usage, uninstallation, and updating, account for operations that can be exploited, which aligns with our findings
only a minor fraction of 9%. on new vulnerabilities. However, a notable difference exists
between existing and new FHVulns. Specifically, among exist-
ing FHVulns, only 7.1% of them involved reading operation,
B. New Findings with 89.5% (17/19) of these cases attributed to reading the
Our investigation has yielded two noteworthy findings that hijacked openssl.cnf file in the OpenSSL library. In contrast,
differ from the existing observations and can provide guidance for new FHVulns, the percentage of reading operation is as
for future studies. high as 30.4% (103/339), representing a significant increase.
Furthermore, the types of FHVulns involving reading operation
in new FHVulns are more diverse than those in existing ones.
Finding 1: The bottom-up search strategy, a software- Hijacking files with reading operation can lead to severe
tailored search strategy that led to eight new FHVulns in consequences, including arbitrary code execution (as illustrated
fundamental software like Git and Dotnet SDK that had in Fig. 1), URL redirection, and sensitive information dis-
gone unnoticed for 18 years, has not received extensive closure. For example, CVE-2023-2939 identified by J ERRY
research attention. enables attackers to hijack the settings.dat file, which contains
a URL that Chrome uses to transmit diagnostic information
Observation 1 reveals that five search strategies account to its servers. Attackers can replace the URL with their
for the majority (89.9%) of hijacked files, which also applies own URL to obtain the diagnostic information. Thus, reading
to newly detected 223 FHVulns (65.8%). However, all five operation poses greater risks than previously considered and
strategies listed in the observation are built-in search strategies requires more attention in the future, as will be discussed in
of the operating systems. After investigating the newly detected Section VIII.

11
 VII. D ISCUSSIONS the developers and identified three main reasons why they
introduced FHVulns. Firstly, they were not aware of the
It is actually incomplete on Windows: a malicious user can existence of FHVulns. Many of them only learned about
create C:\.git ! FHVulns for the first time through our reports. Interestingly,
— A Git developer commented on CVE-2022-24765 some developers initially disagreed with the threat model we
A. What is the reason for the higher number of FHVulns in proposed in Fig. 2, thinking that their software was only
Windows compared to Unix-like systems? for single-user, until they had deeper discussions with other
developers and realized that their software was for multi-
We conducted a thorough analysis of FHVulns in Windows user. Secondly, developers lacked secure usage of APIs. The
and Unix-like systems (Linux and Mac) [56] and identified operating system provides many secure API options for devel-
two root causes based on the design principles that govern opers to use. For example, in the API LoadLibraryEx [47], the
these operating systems. parameter LOAD LIBRARY SEARCH can specify the search
priority to avoid malicious DLLs being loaded before the target
More Existing Directories with Weak Permissions. In
DLLs. However, in actual development, developers may not
Unix-like system, only the /tmp directory is world-writable. Its
deliberately use these parameters. Thirdly, developers lacked
purpose is to accommodate data that is only required for a brief
security responsibility. During the discussion, we found that
period, such as temporary files generated by programs running
some developers believed that files with weak permissions
on the system. In Windows system, besides the directory C:\
were introduced due to users’ incorrect usage, and the software
Windows\Temp which is like /tmp, there are another two di-
itself did not need to strengthen its defenses.
rectories with weak permissions that lead to FHVulns, i.e., C:\
ProgramData and C:\ root directories. While C:\ProgramData Lack of Effective Tool. Due to the lack of systematic
is designed to be used for storing shared program data and research on FHVulns, existing tools have difficulty detecting
configuration files, some software programs may mistakenly FHVulns comprehensively. Based on Observation 1, it can be
store sensitive configuration files and executable files in this concluded that the majority of FHVulns are caused by five
directory. This can increase the risk of FHVulns occurring. search strategies, and the paths of the hijacked files are often
Moreover, the C:\ root directory has weak permissions due nonexistent. As a result, existing approaches are ineffective in
to historical reasons [4], [82]. This has resulted in numerous identifying these vulnerabilities, since they do not take into
hijacking issues. When new folders are created in C:\, they account the search strategies and generate limited event traces
inherit the permissions of C:\ and become world-writable, (Section III-B). Furthermore, these approaches have limited
which further exacerbates security risks. scope, as they only focus on a subset of file operations, leading
More Searched Directories with Weak Permissions. to numerous FHVulns going undetected.
Many search strategies, like bottom-up search strategy, path
search order, symbolic links and dynamically loaded libraries, C. Who is responsible for the FHVulns?
are applicable to both Unix-like systems and Windows sys-
tems. However, these strategies are associated with relatively The responsibility for the security of a file or directory with
fewer FHVulns in Unix-like systems compared to Windows. weak permissions lies with the software developer in cases
One reason for this is that in Windows, when searching where the software creates the file or directory. When such a
for executable files, the operating system looks in CWD as file or directory is created by the administrator (e.g., global
well as in directories specified in the PATH environment configure file for all users), the system administrator assumes
variable. In contrast, Unix-like systems limit their search to responsibility for its security. However, if a user provides
directories listed in the PATH variable only [3]. In terms of a potentially hijacked file or directory that is subsequently
symbolic links, Windows has special directory links known as used by the software, the party responsible for its security
junction points [27], which do not undergo strict permission is unclear. Through deep discussions with developers, most
checks during creation. This feature is not present in Unix- of them tend to rely on providing warnings to users when
like systems. Additionally, Windows searches for dynamically there is a risk with the current file or directory. However,
loaded libraries (DLLs) within the software program direc- some developers believe that merely warning users without
tory and the CWD, whereas Unix-like systems do not [21]. taking measures to prevent or limit potential risks may be
These differences mean that search-related vulnerabilities have viewed as irresponsible. Developers should, therefore, consider
a larger attack surface in Windows compared to Unix-like implementing protective measures in the software. For exam-
systems. ple, to address CVE-2022-24765, Git now requires users to
whitelist trusted files and directories with weak permissions.
B. Why do FHVulns still widely exist? However, such defenses may be inconvenient for some users,
limiting their ability to use the software. After fixing CVE-
While there have been efforts to identify FHVulns, they
2022-24765, many users complained on social media platforms
continue to persist in real-world software. In fact, our research
about Git’s whitelist mechanism. Therefore, developers must
identified 339 zero-day FHVulns in 438 popular software pro-
strike a balance between protecting user safety and experience
grams, including Git, Adobe, and Chrome. After conducting
to provide secure and accessible software products. Moreover,
a detailed analysis, we concluded that there are two main
it is recommended that developers of the Windows operating
categories of reasons contributing to the widespread existence
system revisit the system design to address the issue of
of these vulnerabilities.
FHVulns at the root level. However, it may be not realistic
Lack of Awareness. During the process of reporting and since the new design of the operating system has introduced
fixing these vulnerabilities, we had in-depth discussions with challenges for backward compatibility.

12
 VIII. L IMITATION AND F UTURE W ORK further exploration of resource objects for hijacking is worth
considering. Moreover, some FHVulns can exist in multiple
It’s probably much more effective to make certain git config operating systems simultaneously. For example, software can
variables require that the user that runs the command also be designed with system-independent search strategies (e.g.,
owns the file. bottom-up search strategy in Finding 1), which can be the
— Linus Torvalds commented on CVE-2022-24765 origins of FHVulns.
In this section, we discuss limitation, possible improve-
ments for J ERRY and suggestions for defending against C. How to defend against and mitigate FHVulns?
FHVulns based on our observations (Section II), new findings
After reporting the new FHVulns to developers, we en-
(Section VI-B) and the discussions (Section VII).
gaged in many discussions with them about how to fix and
mitigate FHVulns. We conducted an extensive analysis and
A. What are the limitations of J ERRY? summary of these discussions to provide software developers,
As mentioned in Section III-C, J ERRY detects FHVuln system administrators, and users with effective recommenda-
when both hijacking and sensitive operations are satisfied. tions for defending against FHVulns.
However, FHVulns related to read operation can lead to Suggestions for Software Developers. To address
false positives, necessitating supplementary manual analysis FHVulns, software developers should avoid using paths with
to accurately evaluate the impact. This represents a major weak permissions (Requirement 1) and verify the status of files
limitation of the JERRY framework. In addition, J ERRY uti- before using them (Requirement 2). To block Requirement 1,
lizes chocolatey to automate the installation, uninstallation, and ❶ Avoiding using Built-in directories with weak permissions.
updating stage of software. When testing software not hosted Software developers should either place sensitive files to paths
on the Chocolatey website, it is necessary to implement a with strict permissions (i.e., C:\Program Files) or public paths
corresponding local script. In the usage stage, J ERRY only (i.e., C:\ProgramData) while actively setting right permissions
supports simple user interactions, which may lead to false for sensitive files. For example, most public configuration files,
negatives. such as system config of rubygem, are placed in public paths
such as C:\ProgramData, to ensure that all users can assess and
B. Where can we make improvements to J ERRY? share them. Therefore, during the installation, software should
Mitigating False Positives and False Negatives. To im- create a new configuration file and assign high-level permis-
prove the effectiveness of J ERRY, we can employ several sions to it. ❷ Correcting API Usages. It is necessary to read the
strategies to reduce both false positives and false negatives. API document carefully to ensure that they correctly use the
First, for FHVulns that involve reading operations, J ERRY does API and its parameters. Our study revealed that the majority
not consider the specific way in which the hijacked file content of FHVulns arising from the dynamic loaded libraries search
is used by the software, leading to 21 false positives. For strategy can be attributed to the CWD. Consequently, it is rec-
example, J ERRY reported a false positive for the libgcrypt ommended that developers employ LoadLibraryEx instead of
library [69], which attempts to read the configuration file at C:\ LoadLibraryA and manage the search strategy by configuring
etc\gcrypt\fips enabled on Windows. However, the configura-
the LOAD LIBRARY SEARCH flag to prevent including CWD
tion in this file is only used in libgcrypt for Linux [68]. In other in the search paths. [41] Moreover, when performing sensitive
words, even if the content of C:\etc\gcrypt\fips enabled is actions like creating or deleting files, it is crucial to proactively
read, it is not used by libgcrypt for Windows and therefore does set relevant parameters to prevent symbolic link resolution
not pose any security impacts. Therefore, we may combine issue [58]. Specifically, the function CreateFileA requires the
taint analysis [63], [90] and program understanding [78], [87] FILE FLAG OPEN REPARSE POINT parameter, as stated in
techniques to figure out where the file content propagates. the document [74]. ❸ Design software-tailored search strate-
gies cautiously. Based on Finding 1, it is evident that software-
In addition, we can employ static analysis techniques [64], tailored search strategies may lead to various FHVulns. Thus,
[91] to detect more FHVulns by identifying potential vul- developers need to design search strategies with caution, taking
nerabilities. It is challenging to trigger certain components into account multiple user scenarios. To block Requirement 2,
of software that contain FHVulns through dynamic testing. ❹ Checking file status before use. Developers ought to verify
Hence, static analysis can be utilized to identify suspected whether sensitive files have been hijacked by checking their
FHVulns along with the trigger conditions, which can guide ownership. If the file’s owner differs from that of the user,
J ERRY to trigger these vulnerabilities. Furthermore, we found the software should either terminate its operation or prompt
that some FHVulns (e.g., CVE-2020-26284) can only be users to confirm whether they wish to proceed with potentially
triggered via specific user-provided contents. To address this “hijacked” sensitive files.
issue, mutation-based techniques [61], [79] can be employed
to generate diverse contents. Suggestions for System Administrators. It was observed
that approximately 23 software programs in our real-world ex-
More Attack Vectors. In addition to files, other resources periments were installed in directories with weak permission,
such as registries and named pipes can also breach security and only four of them set an appropriate permissions to files. ❶
boundaries. For example, a study found that two service As a result, software developers should consider changing their
registry keys with weak permissions were present on Windows software’s default installation directory (the first suggestion
7, and can enable attackers to obtain SYSTEM privilege by for software developers), and system administrators can ensure
modifying their value [32]. Additionally, hijacked named pipes double security by employing the custom installation mode and
can also be used for privilege escalation [33]. Therefore, installing the software in a directory with high permissions.

13
Additionally, we found that various direct subdirectories of B. File-related Vulnerability Exploitation
the root directory C:\, which were not initially present in
Several researchers have focused on exploiting DLL hi-
the system, were vulnerable to hijacking due to the exces-
jacking vulnerabilities while minimizing the impact on the
sively permissive permission settings of the Windows OS
normal functioning of software programs. As a promising
during initialization. ❷ Therefore, it is advisable for system
approach, they have proposed DLL proxying attacks [12],
administrators to remove the write permission of Authenticated
[22]. Numerous studies have been conducted on security issues
Users [29] group from the C:\ directory. This action can
caused by symbolic links [1], [5]–[8], [58], [92]. Some of
significantly decrease the likelihood of path hijacking, while
the researchers [9] used symbolic link testing tools [2] to dig
having minimal side effects. (Requirement 1)
into these vulnerabilities and investigated how symbolic links
Suggestions for Software Users. Besides, it is crucial for can be used to execute arbitrary code [92]. Basu et al. [58]
software users to be aware of security risks and follow safe discovered that on case-insensitive systems, symbolic links can
practices when using software. Particularly, users should avoid lead to problems such as content overwriting and permission
launching software program in paths with weak permissions, modification. These approaches can be combined with J ERRY
such as C:\ProgramData\. (Requirement 1) Additionally, be- to amplify the security impacts of detected FHVulns.
fore using software in publicly writable paths, users need to
check for any suspicious files. (Requirement 2) For instance, C. General Hijacking Studies
when using software downloaded from the internet in publicly Researchers have explored various types of hijacking be-
writable paths, users ought to verify its integrity by checking yond file hijacking. For instance, hijacking named pipes on
the checksum. Windows can result in privilege escalation, and a tool called
PipeViewer [30] has been developed to identify such vulnera-
bilities. Account hijacking has also been studied comprehen-
IX. R ELATED W ORK sively by researchers like Avinash Sudhodanan et al. [85]. In
web security, session hijacking [60], [66] and cookie hijack-
A. File-related Vulnerability Detection ing [67], [83], [84] are common types of hijacking incidents.
Additionally, techniques like control flow hijacking [51], [88]
Static Analysis. To detect file-related vulnerabilities, var- and data flow hijacking [71] are often used to exploit memory
ious static analysis techniques have been proposed. Some corruption vulnerabilities. However, our research specifically
techniques [62], [70], [76] focused on identifying weak permis- focuses on file hijacking, which can lead to a breach of
sions in the Windows system by scanning permission metadata. security boundaries in operating systems. This type of attack
PrivescCheck [49] statically scanned the permission metadata can compromise software security and allow attackers to gain
in Windows and report potential file-related vulnerabilities. elevated privileges, execute arbitrary code, and so on, making
Bauer et al. [59] employed association rule mining techniques it critical to understand file hijacking.
to detect access control misconfiguration, while Parkinson et
al. [77] utilized rule mining methods to identify incorrect X. C ONCLUSION
permission configurations. Shaikh et al. [81] proposed a deci-
sion tree and data classification-based approach for detecting This paper presents the first empirical investigation of
incomplete and inconsistent (allow or deny) policies in access FHVulns. The study observations inspired us to create a dy-
control datasets. These methods analyzed the permissions of namic analysis tool, known as J ERRY, for detecting FHVulns.
existing files statically to identify file-related vulnerabilities. To date, J ERRY has identified 339 zero-day FHVulns in 438
In the context of FHVulns, these techniques can only detect real-world software programs. We have taken full responsi-
the FHVulns with the first origin, neglecting the majority of bility for disclosing all of the zero-day FHVulns, of which 84
the FHVulns (Observation 1). have been either confirmed or resolved, with 51 being assigned
CVE identifiers. Moreover, our findings on the existing and
Dynamic Analysis. Many approaches employed dynamic newly detected vulnerabilities can further help to guide future
techniques to detect file-related vulnerabilities. Spartacus [53] work on detecting and fixing FHVulns.
analyzed the traces recorded by ProcMon [50] to detect DLL
hijacking or binary hijacking. Crassus [36] considered the per- ACKNOWLEDGMENT
missions of the path when detecting file-related vulnerabilities. The authors would like to express their gratitude to the
Researchers also focused on finding file-related vulnerabilities anonymous reviewers for their helpful feedback on an earlier
caused by symbolic link automatically by triggering APIs pro- version of this paper. This work is partly supported by National
vided by Windows service [10]. Vetle [86] utilized ProcMon Key R&D Program of China under Grant #2022YFB3103900,
to monitor file system events with “NOT FOUND” result, and Strategic Priority Research Program of the CAS under Grant
verified file hijacking vulnerabilities through manual testing. #XDCO2030200 and Chinese National Natural Science Foun-
Similarly, LPET [72] designed a dynamic file system event dation (Grants #62032010, #62202462).
monitor to detect temporary directories with weak permissions
during the software installation, updating, and uninstallation R EFERENCES
stage. In the context of FHVulns, these techniques are like
the FHVuln detector module in J ERRY. They may miss out [1] “A link to the past - abusing symbolic links on windows,”
https://infocon.org/cons/SyScan/SyScan%202015%20Singapore/
on some sensitive operations (Observation 2). Moreover, most SyScan%202015%20Singapore%20presentations/SyScan15%
of them lack the ability to generate the event traces during 20James%20Forshaw%20-%20A%20Link%20to%20the%20Past.pdf,
different software lifecycle stages (Observation 3). 15.

14
 [2] “Symoliclink testing tools,” https://github.com/googleprojectzero/ [32] “An Unconventional Exploit for the RpcEptMapper Registry Key
symboliclink-testing-tools, 15. Vulnerability,” https://itm4n.github.io/windows-registry-rpceptmapper-
[3] “How does unix search for executable files,” https://superuser.com/ exploit/, 2023.
questions/238987/how-does-unix-search-for-executable-files, 2010. [33] “Breaking Docker Named Pipes SYSTEMatically: Docker Desktop
[4] “Windows 7 Special Directories (Folders),” https://wiki.carleton.edu/ Privilege Escalation,” https://www.cyberark.com/resources/threat-
pages/viewpage.action?pageId=9961710, 2011. research-blog/breaking-docker-named-pipes-systematically-docker-
desktop-privilege-escalation-part-1, 2023.
[5] “Between a Rock and a Hard Link,” https://
googleprojectzero.blogspot.com/2015/12/between-rock-and-hard- [34] “Bugcrowd,” https://bugcrowd.com/, 2023.
link.html, 2015. [35] “Common Vulnerabilities and Exposures,” https://cve.mitre.org/, 2023.
[6] “Windows 10 Symbolic Link Mitigations,” https:// [36] “Crassus Windows privilege escalation discovery tool,” https://
googleprojectzero.blogspot.com/2015/08/windows-10hh-symbolic- github.com/vu-ls/Crassus/, 2023.
link-mitigations.html, 2015.
[37] “CVE-2022-25969,” https://cve.mitre.org/cgi-bin/cvename.cgi?name=
[7] “Windows Exploitation Tricks: Arbitrary Directory Creation to Ar- 2022-25969, 2023.
bitrary File Read,” https://googleprojectzero.blogspot.com/2017/08/
windows-exploitation-tricks-arbitrary.html, 2017. [38] “CVE-2022-26319,” https://cve.mitre.org/cgi-bin/cvename.cgi?name=
2022-26319, 2023.
[8] “Windows exploitation tricks: Exploiting arbitrary file writes for local
elevation of privilege,” https://googleprojectzero.blogspot.com/2018/04/ [39] “CVE-2022-39845,” https://cve.mitre.org/cgi-bin/cvename.cgi?name=
windows-exploitation-tricks-exploiting.html, 2018. 2022-39845, 2023.
[9] “Abusing privileged file operations,” https://troopers.de/ [40] “CVSS,” https://nvd.nist.gov/vuln-metrics/cvss, 2023.
downloads/troopers19/TROOPERS19 AD Abusing privileged file [41] “Dynamic link library search order,” https://learn.microsoft.com/en-us/
operations.pdf, 2019. windows/win32/dlls/dynamic-link-library-search-order/, 2023.
[10] “Battle Of Windows Service:A Silver Bullet To Discover File Privilege [42] “githooks - Hooks used by Git,” https://git-scm.com/docs/githooks,
Escalation Bugs Automatically,” https://i.blackhat.com/USA-19/ 2023.
Wednesday/us-19-Wu-Battle-Of-Windows-Service-A-Silver-Bullet- [43] “HackerOne,” https://hackerone.com/, 2023.
To-Discover-File-Privilege-Escalation-Bugs-Automatically.pdf, 2019.
[44] “Hijack Execution Flow: DLL Search Order Hijacking,” https://
[11] “CVE-2019-5443,” https://cve.mitre.org/cgi-bin/cvename.cgi?name= attack.mitre.org/techniques/T1574/001/, 2023.
CVE-2019-5443/, 2019.
[45] “Hijack Execution Flow: Path Interception by Search Order Hijacking,”
[12] “Windows Privilege Escalation - DLL Proxying,” https:
https://attack.mitre.org/techniques/T1574/008/, 2023.
//itm4n.github.io/dll-proxying/, 2019.
[46] “Intigriti,” https://www.intigriti.com/, 2023.
[13] “CVE-2020-13542,” https://cve.mitre.org/cgi-bin/cvename.cgi?name=
CVE-2020-13542/, 2020. [47] “LoadLibraryEx,” https://learn.microsoft.com/en-us/windows/win32/
[14] “CVE-2020-13884,” https://cve.mitre.org/cgi-bin/cvename.cgi?name= api/libloaderapi/nf-libloaderapi-loadlibraryexa, 2023.
CVE-2020-13884/, 2020. [48] “.NET is the free, open-source, cross-platform framework for
[15] “CVE-2020-26284,” https://cve.mitre.org/cgi-bin/cvename.cgi?name= building modern apps and powerful cloud services.” https://
CVE-2020-26284, 2020. dotnet.microsoft.com/en-us/, 2023.
[16] “CVE-2020-27955,” https://cve.mitre.org/cgi-bin/cvename.cgi?name= [49] “PrivescCheck- Privilege Escalation Enumeration Script for Windows,”
CVE-2020-27955/, 2020. https://github.com/itm4n/PrivescCheck, 2023.
[17] “CVE-2020-36167,” https://cve.mitre.org/cgi-bin/cvename.cgi?name= [50] “Process Monitor,” https://learn.microsoft.com/en-us/sysinternals/
2020-36167, 2020. downloads/procmon, 2023.
[18] “CVE-2020-8224,” https://cve.mitre.org/cgi-bin/cvename.cgi?name= [51] “Return Oriented Programming,” https://en.wikipedia.org/wiki/Return-
CVE-2020-8224/, 2020. oriented programming/, 2023.
[19] “GitHub CLI can execute a git binary from the current directory,” https: [52] “RubyGems,” https://rubygems.org/, 2023.
//github.com/cli/cli/security/advisories/GHSA-fqfh-778m-2v32/, 2020. [53] “Spartacus,” https://github.com/Accenture/Spartacus, 2023.
[20] “CVE-2021-0057,” https://cve.mitre.org/cgi-bin/cvename.cgi?name= [54] “Symbolic link,” https://en.wikipedia.org/wiki/Symbolic link, 2023.
2021-0057, 2021.
[55] “The website of Jerry,” https://sites.google.com/view/iamjerry, 2023.
[21] “ld.so(8) — Linux manual page,” https://man7.org/linux/man-pages/
man8/ld.so.8.html/, 2021. [56] “Unix like,” https://en.wikipedia.org/wiki/Unix-like, 2023.
[22] “SuperDllHijack,” https://github.com/anhkgg/SuperDllHijack/, 2021. [57] “Windows Installer,” https://learn.microsoft.com/en-us/windows/win32/
msi/windows-installer-portal, 2023.
[23] “Windows security servicing criteria,” https://www.microsoft.com/en-
us/msrc/windows-security-servicing-criteria, 2021. [58] A. Basu, J. Sampson, Z. Qian, and T. Jaeger, “Unsafe at any copy: Name
collisions from mixing case sensitivities,” in 21st USENIX Conference
[24] “Writing Preoperation and Postoperation Callback Routines,” on File and Storage Technologies (FAST 23), 2023, pp. 183–198.
https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/
writing-preoperation-and-postoperation-callback-routines/, 2021. [59] L. Bauer, S. Garriss, and M. K. Reiter, “Detecting and resolving policy
misconfigurations in access-control systems,” ACM Transactions on
[25] “IRP MJ CREATE,” https://learn.microsoft.com/en-us/windows- Information and System Security (TISSEC), vol. 14, no. 1, pp. 1–28,
hardware/drivers/kernel/irp-mj-create, 2022. 2011.
[26] “IRP MJ READ,” https://learn.microsoft.com/en-us/windows-
[60] M. Bugliesi, S. Calzavara, R. Focardi, and W. Khan, “Cookiext:
hardware/drivers/ifs/irp-mj-read, 2022.
Patching the browser against session hijacking attacks,” Journal of
[27] “Junction Point,” https://learn.microsoft.com/en-us/sysinternals/ Computer Security, vol. 23, no. 4, pp. 509–537, 2015.
downloads/junction, 2022.
[61] S. K. Cha, M. Woo, and D. Brumley, “Program-adaptive mutational
[28] “Samsung Kies,” https://www.samsung.com/cn/support/kies/, 2022. fuzzing,” 2015 IEEE Symposium on Security and Privacy, pp. 725–741,
[29] “Understand special identities groups,” https://learn.microsoft.com/ 2015.
en-us/windows-server/identity/ad-ds/manage/understand-special- [62] H. Chen, N. Li, C. S. Gates, and Z. Mao, “Towards analyzing complex
identities-groups/, 2022. operating system access control configurations,” in Proceedings of the
[30] “A tool that shows detailed information about named pipes in Win- 15th ACM symposium on Access control models and technologies, 2010,
dows,” https://github.com/cyberark/PipeViewer/, 2023. pp. 13–22.
[31] “Access Control List,” https://learn.microsoft.com/en-us/windows/ [63] L. Chen, Y. Wang, Q. Cai, Y. Zhan, H. Hu, J. Linghu, Q. Hou, C. Zhang,
win32/secauthz/access-control-lists, 2023. H. Duan, and Z. Xue, “Sharing more and checking less: Leveraging

15
 common input keywords to detect bugs in embedded systems,” in [87] Y. Wang, W. Wang, S. R. Joty, and S. C. H. Hoi, “Codet5: Identifier-
USENIX Security Symposium, 2021. aware unified pre-trained encoder-decoder models for code understand-
[64] Q. A. Chen, Z. Qian, Y. Jia, Y. Shao, and Z. M. Mao, “Static detection ing and generation,” ArXiv, vol. abs/2109.00859, 2021.
of packet injection vulnerabilities: A case for identifying attacker- [88] W. Wu, Y. Chen, X. Xing, and W. Zou, “Kepler: Facilitating control-
controlled implicit information leaks,” Proceedings of the 22nd ACM flow hijacking primitive evaluation for linux kernel vulnerabilities.” in
SIGSAC Conference on Computer and Communications Security, 2015. USENIX Security Symposium, 2019, pp. 1187–1204.
[65] Chocolatey Community, “Chocolatey Package,” https: [89] yinkaisheng, “UIAutomation,” https://github.com/yinkaisheng/Python-
//community.chocolatey.org/packages, 2023. UIAutomation-for-Windows, 2023.
[66] K. Drakonakis, S. Ioannidis, and J. Polakis, “The cookie hunter: [90] X. Zhang, X. Wang, R. Slavin, and J. Niu, “Condysta: Context-aware
Automated black-box auditing for web authentication and authorization dynamic supplement to static taint analysis,” 2021 IEEE Symposium on
flaws,” in Proceedings of the 2020 ACM SIGSAC Conference on Security and Privacy (SP), pp. 796–812, 2021.
Computer and Communications Security, 2020, pp. 1953–1970. [91] Y. Zheng and X. Zhang, “Path sensitive static analysis of web appli-
[67] M. Ghasemisharif, A. Ramesh, S. Checkoway, C. Kanich, and J. Polakis, cations for remote code execution vulnerability detection,” 2013 35th
“O single sign-off, where art thou? an empirical analysis of single sign- International Conference on Software Engineering (ICSE), pp. 652–661,
on account hijacking and session management on the web.” in USENIX 2013.
Security Symposium, 2018, pp. 1475–1492. [92] S. Zuckerbraun, “Abusing arbitrary file deletes to escalate privilege and
[68] Gnupg, “Gnupg,” https://www.gnupg.org/documentation/manuals/ other great tricks,” https://www.thezdi.com/blog/2022/3/16/abusing-
gcrypt/Configuration.html, 2023. arbitrary-file-deletes-to-escalate-privilege-and-other-great-tricks, 22.
[69] Google, “Crashpad,” https://chromium.googlesource.com/crashpad/
crashpad, 2023. A PPENDIX
[70] S. Govindavajhala and A. W. Appel, “Windows access control demys-
tified,” Princeton university, 2006. In this appendix, we list detailed evaluation results on
[71] H. Hu, Z. L. Chua, S. Adrian, P. Saxena, and Z. Liang, “Automatic gen- known vulnerabilities in TABLE A1, including CVE-ID, af-
eration of data-oriented exploits,” in 24th USENIX Security Symposium fected software, stage, operation, and results of PrivescCheck,
(USENIX Security 15), 2015, pp. 177–192. J ERRY-Crassus, and our tool J ERRY.
[72] C. Huang, X. Han, and G. Yu, “LPET–mining MS-windows software
privilege escalation vulnerabilities by monitoring interactive behavior,”
in Proceedings of the 2020 ACM SIGSAC Conference on Computer and
Communications Security, 2020, pp. 2089–2091.
[73] MSDN, “Minifilter Framework,” https://learn.microsoft.com/en-us/
windows-hardware/drivers/ifs/filter-manager-concepts, 2021.
[74] MSDN, “CreateFileA,” https://learn.microsoft.com/en-us/windows/
win32/api/fileapi/nf-fileapi-createfilea, 2023.
[75] msrc, “CVE-2023-33135,” https://msrc.microsoft.com/update-guide/
vulnerability/CVE-2023-33135, 2023.
[76] P. Naldurg, S. Schwoon, S. Rajamani, and J. Lambert, “Netra: seeing
through access control,” in Proceedings of the fourth ACM workshop
on Formal methods in security, 2006, pp. 55–66.
[77] S. Parkinson, V. Somaraki, and R. Ward, “Auditing file system permis-
sions using association rule mining,” Expert Systems with Applications,
vol. 55, pp. 274–283, 2016.
[78] J. Patrick-Evans, M. Dannehl, and J. Kinder, “Xfl: Naming functions
in binaries with extreme multi-label learning,” 2021.
[79] H. Peng, Z. Yao, A. A. Sani, D. J. Tian, and M. Payer, “Gleefuzz:
Fuzzing webgl through error message guided mutation,” USENIX Se-
curity’23, 2023.
[80] C. B. Seaman, “Qualitative methods in empirical studies of software
engineering,” IEEE Transactions on software engineering, vol. 25, no. 4,
pp. 557–572, 1999.
[81] R. A. Shaikh, K. Adi, and L. Logrippo, “A data classification method
for inconsistency and incompleteness detection in access control policy
sets,” International Journal of Information Security, vol. 16, pp. 91–
113, 2017.
[82] C. Siechert and E. Bott, Microsoft Windows XP inside out. Microsoft
Press, 2002.
[83] S. Sivakorn, A. D. Keromytis, and J. Polakis, “That’s the way the cookie
crumbles: Evaluating https enforcing mechanisms,” in Proceedings of
the 2016 ACM on Workshop on Privacy in the Electronic Society, 2016,
pp. 71–81.
[84] S. Sivakorn, I. Polakis, and A. D. Keromytis, “The cracked cookie jar:
Http cookie hijacking and the exposure of private information,” in 2016
IEEE Symposium on Security and Privacy (SP). IEEE, 2016, pp. 724–
742.
[85] A. Sudhodanan and A. Paverd, “Pre-hijacked accounts: An empirical
study of security failures in user account creation on the web,” in 31st
USENIX Security Symposium (USENIX Security 22), 2022, pp. 1795–
1812.
[86] Vetle, “Finding privesc with procmon,” https://bordplate.no/
presentations/finding privesc with procmon.pdf, 2019.

16
TABLE A1: The Detailed Evaluation Results on Known Vulnerabilities. The abbreviations Ins, Uni, Up, Rep, SU and Us
represent Installation, Uninstallation, Updating, Repairing, Starting Up and Usage, respectively. The abbreviations PC, IL, RD,
CT, MV and DT represent Process Creation, Image Loading, Reading, Creating, Moving and Deleting, respectively.

No. CVE ID Affected Software Stage Operation PrivescCheck J ERRY-Crassus J ERRY

1 CVE-2022-41604 ZoneAlarm Ins MV ✓

2 CVE-2022-39845 Samsung Kies Uni DT ✓
3 CVE-2022-39286 Jupyter Core Us PC ✓ ✓
4 CVE-2022-38611 Watchdog Anti-Virus SU IL ✓ ✓ ✓
5 CVE-2022-36415 Scooter Beyond Compare Uni IL ✓ ✓
6 CVE-2022-35861 pyenv Us RD ✓
7 CVE-2022-29320 MiniTool Partition Wizard SU PC ✓ ✓ ✓
8 CVE-2022-28964 Avast Premium Security Us CT ✓
9 CVE-2022-27535 Kaspersky VPN Us DT ✓
10 CVE-2022-27094 Sony PlayMemories Home SU PC ✓ ✓ ✓
11 CVE-2022-24826 git-lfs Us PC ✓ ✓
12 CVE-2022-24767 Git for Windows Uni IL ✓ ✓
13 CVE-2021-46368 TRIGONE Remote System Monitor SU PC ✓ ✓ ✓
14 CVE-2021-45975 Acer Care Center Up IL ✓ ✓ ✓
15 CVE-2021-43463 Ext2Fsd SU PC ✓ ✓ ✓
16 CVE-2021-43460 System Explorer SU PC ✓ ✓ ✓
17 CVE-2021-43455 FreeLAN SU PC ✓ ✓ ✓
18 CVE-2021-43454 AnyTEXT Seacher SU PC ✓ ✓ ✓
19 CVE-2021-42923 ShowMyPC SU IL ✓ ✓
20 CVE-2021-38570 Foxit Readinger Uni DT ✓
21 CVE-2021-37363 Gestionale Open Ins PC ✓ ✓ ✓
22 CVE-2021-36753 Sharkrdp bat Us PC ✓ ✓ ✓
23 CVE-2021-3606 OpenVPN SU RD ✓ ✓ ✓
24 CVE-2021-31847 McAfee Agent Rep IL ✓ ✓
25 CVE-2021-30490 ViewPower Ins PC ✓ ✓ ✓
26 CVE-2021-28098 Forescout CounterACT SU CT ✓
27 CVE-2021-22000 VMware Thinapp SU IL ✓ ✓
28 CVE-2020-9442 OpenVPN Connect client SU IL ✓ ✓
29 CVE-2020-8224 Nextcloud Desktop Client SU RD ✓ ✓
Eaton’s 9000x Programming
30 CVE-2020-6654 Ins IL ✓ ✓ ✓
and Configuration Software
31 CVE-2020-5992 NVIDIA GeForce NOW SU RD ✓ ✓
32 CVE-2020-5977 NVIDIA GeForce Experience SU RD ✓
33 CVE-2020-27643 1E Client Us CT ✓
34 CVE-2020-26941 NOD32 Antivirus ESET Ins CT ✓
35 CVE-2020-26538 Foxit Readinger SU PC ✓ ✓
36 CVE-2020-26284 Hugo Us PC
37 CVE-2020-26050 SaferVPN SU RD ✓ ✓
38 CVE-2020-25744 SaferVPN Us CT ✓
39 CVE-2020-25043 Kaspersky Secure Connection Ins DT ✓
40 CVE-2020-22809 Windscribe SU PC ✓ ✓ ✓
41 CVE-2020-15843 ActFax SU IL ✓ ✓ ✓
42 CVE-2020-15264 Boxstarter SU IL ✓ ✓ ✓
43 CVE-2020-15261 Veyon SU PC ✓ ✓ ✓
44 CVE-2020-15145 Composer Ins PC ✓ ✓
45 CVE-2020-13885 Citrix Workspace App Uni IL ✓ ✓
46 CVE-2020-13884 Citrix Workspace App Uni PC ✓ ✓
47 CVE-2020-13866 WinGate Ins PC ✓ ✓ ✓
48 CVE-2020-13542 LogicalDoc Ins PC ✓ ✓ ✓
49 CVE-2020-12431 Splashtop Software Up RD ✓
50 CVE-2020-10143 Macrium Reflect SU RD ✓ ✓
51 CVE-2020-10140 Acronis True Image SU IL ✓ ✓

17