ParaTaintGX: Detecting Memory Corruption Vulnerabilities in SGX Applications via Parameter-Taint Model

Abstract

Intel Software Guard Extensions (SGX) have been widely studied and adopted in privacy-preserving information systems to enhance the security and privacy guarantees of sensitive data computation. By constructing a protected enclave within the processor, SGX provides hardware-enforced confidentiality and integrity for sensitive data and critical code. Nevertheless, due to inevitable interactions between trusted enclaves and untrusted host environments, SGX applications remain vulnerable to memory corruption attacks. Existing detection techniques exhibit fundamental limitations, including the lack of systematic induction of SGX-specific memory corruption behaviors, the absence of fine-grained parameter-level taint modeling during call-chain construction, and relatively inefficient call-chain exploration strategies over large search spaces. To address these issues, we propose ParaTaintGX, an analysis framework that integrates parameter-level taint states into vulnerability detection. ParaTaintGX constructs fine-grained call-chain nodes that capture both functions and the taint states of their parameters. It further introduces a Multi-node Heuristic Priority Search Algorithm to guide call-chain exploration. In addition, a backtracking-based pruning strategy is applied during path analysis to efficiently identify memory corruption vulnerabilities. Our evaluation demonstrates that ParaTaintGX discovers 12 vulnerabilities across 10 open-source SGX projects, outperforming the best baseline tool by two vulnerabilities. It achieves 19.35% precision, surpassing the most precise existing tool by 8.37 percentage points. These results highlight its superior detection capability and precision.

1. Introduction

In modern computing environments where cloud platforms, distributed systems, and blockchain-based applications are increasingly deployed [1,2,3,4,5,6,7,8,9], large volumes of privacy-sensitive data are centrally collected and processed on untrusted computing platforms, making data security and privacy protection during computation a critical concern. To prevent sensitive information from being exposed throughout the computation lifecycle, researchers have proposed a wide range of privacy-preserving and security-enhancing mechanisms [10,11,12,13,14]. However, most existing security and privacy protection mechanisms are built upon the assumption of a trusted privileged software stack, including the operating system and the virtual machine monitor. Once these high-privilege components are compromised, adversaries can gain unrestricted access to application memory and arbitrarily manipulate sensitive data and code, thereby fundamentally undermining the effectiveness of runtime protection [15,16,17,18].

Trusted Execution Environment (TEE), such as Intel SGX, address this limitation by shifting the root of trust from the vulnerable software stack into the processor via hardware mechanisms. This provides a strongly isolated execution environment for designated code and data, ensuring that critical computations retain verifiable security guarantees even when the host platform is untrusted or fully compromised.

In this context, Intel SGX provides a hardware-based trusted execution environment that establishes a protected enclave within the processor to ensure the confidentiality and integrity of critical code and sensitive data [19]. As a result, SGX has become a powerful security mechanism and has been widely adopted across numerous real-world systems and projects [20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35].

However, the interactions between SGX enclaves and the untrusted host environment introduce attack surfaces that can lead to memory corruption vulnerabilities, enabling adversaries to hijack enclave control flow, leak sensitive data, or compromise enclave integrity [35,36,37,38].

To mitigate memory corruption vulnerabilities in SGX applications, researchers have developed a range of detection techniques—such as TeeRex [39], COIN [40], Guardian [41], SymGX [42], and IntraFuzz [43]—which leverage symbolic execution, fuzzing, and other methods to uncover security flaws in various versions of Intel SGX SDK, ranging from 2.12 to 2.14 and above. In our evaluation, we focus on Intel SGX SDK version 2.14 and have demonstrated promising effectiveness.

However, these approaches still exhibit several fundamental limitations in practice:

• Insufficient vulnerability taxonomy: Existing work lacks a systematic characterization of SGX memory corruption vulnerabilities. This results in reduced detection efficiency in large-scale analyses.
• Coarse-grained pruning strategies: Most analysis tools prune paths at the function level during call-chain construction, failing to adequately distinguish differences in parameter taint states across distinct calling contexts. This coarse granularity frequently removes valid paths with unique taint-propagation behaviors, leading to false negatives
• Inefficient call-chain exploration: Tools relying on depth-first search or random traversal struggle to reason about complex function interactions such as recursion and mutual calls, significantly degrading call-chain construction efficiency.
• Lack of parameter-level taint modeling: Building call chains solely at the function level fails to capture parameter-specific taint information during call-chain backtracking. As a result, backtracking cannot accurately distinguish parameter taint information across different calling contexts, hindering the determination of taint flow across function boundaries and leading to the generation of false positives.

Building upon these challenges, we propose ParaTaintGX, a novel static analysis framework tailored for SGX applications, designed to efficiently detect memory corruption vulnerabilities. By systematically analyzing publicly available SGX projects, we extract characteristic vulnerability patterns that serve as the foundation for subsequent identification of SGX-specific memory corruption vulnerabilities.

Using Ghidra as our reverse-engineering framework, we construct the call chain by introducing a fine-grained call-chain node model that jointly characterizes each function and the taint locations of its parameters. This design significantly enhances the precision of taint propagation, reducing false negatives caused by coarse-grained pruning during call-chain construction, and mitigating false positives that arise from missing parameter-level taint information during backtracking.

Furthermore, we develop a multi-node heuristic priority search algorithm driven by this refined node model to prioritize the exploration of more promising call-chain nodes while avoiding redundant or irrelevant paths, thereby improving the efficiency of call-chain construction. Finally, we design a pruning algorithm tailored for our parameter-aware call-chain backtracking, which eliminates unnecessary backtracking steps and further boosts overall analysis performance.

We evaluated ParaTaintGX, IntraFuzz [43], SymGX [42], and TeeRex [39] using SGX applications and the OpenCVE database of publicly disclosed vulnerabilities. Our results show that ParaTaintGX reported 62 vulnerabilities, of which 12 were confirmed; TeeRex reported 4564 vulnerabilities, with 9 confirmed; SymGX reported 82 vulnerabilities, with 9 confirmed; and IntraFuzz reported 124 vulnerabilities, with 10 confirmed. These results clearly indicate that ParaTaintGX substantially outperforms the evaluated state-of-the-art tools in detecting memory corruption vulnerabilities.

In summary, our main contributions are as follows:

• We classify vulnerability types using the OpenCVE database of publicly disclosed SGX vulnerabilities, identify common SGX vulnerability patterns, and extract characteristic features of these vulnerabilities.
• To mitigate false negatives caused by pruning strategies during call-chain construction and false positives arising from context-insensitive parameter taint states during backtracking, we introduce a parameter-aware call-chain node model, which improves both the precision and reliability of call-chain analysis.
• To address the inefficiency of call-chain exploration, we propose a multi-node heuristic priority search algorithm that prioritizes promising nodes and reduces redundant path traversals, thereby enhancing call-chain construction efficiency.
• We design a pruning algorithm for link backtracking to eliminate unnecessary analyses during call-chain backtracking, further improving efficiency.
• Based on these techniques, we implement ParaTaintGX, a tool for detecting memory corruption vulnerabilities in SGX programs. ParaTaintGX has been validated on multiple real-world vulnerability samples and open-source SGX projects, demonstrating high detection accuracy and analysis efficiency.

The rest of this paper is organized as follows. Section 2 introduces the background of SGX communication mechanisms and the underlying causes of memory corruption vulnerabilities. Section 3 introduces related work. Section 4 describes the architecture and design of ParaTaintGX. Section 5 presents the experimental results. Section 6 concludes the paper and discusses directions for future work.

2. Background

In this section, we review SGX communication between the untrusted and trusted execution environment, the potential memory corruption vulnerabilities that may result from such interactions, and the limitations of existing analysis tools.

2.1. SGX

SGX is a hardware-based security technology that enhances protection beyond traditional software defenses by providing hardware-enforced confidentiality and integrity for sensitive code and data. As illustrated in Figure 1, SGX enables applications to create isolated execution environments inside the CPU, known as enclaves. The enclave constitutes a protected memory region in which both code and data are encrypted and isolated, preventing access or tampering even from privileged system components such as the operating system or the BIOS. The remainder of the application is executed in the untrusted host environment. Direct communication between the enclave and the untrusted environment is not allowed. Instead, data exchange must occur through the ecall and ocall interfaces provided by the Intel SGX SDK [44]. The untrusted host invokes enclave functions via ecalls, whereas the enclave interacts with the untrusted environment through ocalls. By allowing developers to encapsulate sensitive code and data within enclaves, SGX ensures the confidentiality of memory contents and preserves the integrity of enclave-executed code.

These ecall and ocall interfaces are declared in the EDL file. Listing 1 uses the EDL file from the sgxwallet project for illustration:

• enclave{}: This section serves as the root structure of the EDL file and defines the boundary of an enclave.
• trusted{}: This section specifies the ecall interfaces exposed by the enclave to the untrusted environment, which can invoke these interfaces to execute specific enclave operations.
• [in]: This parameter is an input pointer. The memory referenced by the pointer is treated as input, and the SGX SDK copies the data from the untrusted environment into the enclave after performing integrity and boundary checks.
• [out]: This parameter is an output pointer, indicating that data is copied from inside the enclave to the corresponding buffer in the untrusted environment. The SGX SDK performs integrity checks prior to the data leaving the enclave.
• [string]: This parameter indicates that the parameter is a null-terminated string. The SGX SDK applies additional validation and handling tailored to string parameters.
• [count = size]: This parameter specifies the number of elements contained in the buffer pointed to by the parameter. The SGX SDK uses this information to conduct boundary checks, ensuring that memory copying operations remain within the expected bounds.
• [user_check]: This parameter indicates that the SGX SDK does not automatically validate the pointer. Developers are responsible for performing the required safety and boundary checks manually.

Listing 1. EDL file in the sgxwallet project.

2.2. Memory Corruption Vulnerability

Although SGX provides strong hardware-level isolation, improper memory accesses in SGX applications have still resulted in numerous exploitable vulnerabilities [38,45,46,47,48,49,50,51,52,53,54,55,56]. These vulnerabilities primarily stem from out-of-bounds reads and out-of-bounds writes.

Out-of-bounds reads occur when data is copied from a pointer-referenced memory region to the untrusted environment without verifying whether the referenced address resides inside the enclave.

The absence of such validation may lead to unintended disclosure of confidential enclave data to the untrusted environment, thereby compromising enclave confidentiality.

For instance, CVE-2021-22552 [45] which is shown in Listing 2, is a representative out-of-bounds read vulnerability in SGX applications. The root cause lies in how the MessageReader component processes input: the enclave interprets the response_buffer supplied by the untrusted environment as a MessageReader object and subsequently accesses buffer parameters according to the parsed response_reader structure. This design implicitly assumes that response_buffer is trustworthy. As a result, the enclave directly dereferences offset-based fields (e.g., parameter_address(i)) derived from this structure. When an attacker forges a malicious response_buffer, the enclave follows these attacker-controlled offsets and reads arbitrary memory locations, ultimately exposing sensitive enclave data and triggering an out-of-bounds read vulnerability.

Out-of-bounds write vulnerabilities arise from the lack of a validation mechanism to determine whether the target memory address of a write operation resides within the enclave. Without such checks, sensitive enclave data may be overwritten, thereby compromising the integrity of the protected information.

For instance, CVE-2020-8937 [46], which is shown in Listing 3, is a representative out-of-bounds write vulnerability in SGX applications. The cause of this vulnerability lies in obtaining a queue pointer from the output, after which the function enc_untrusted_wait_queue_set_value proceeds to write data to the memory referenced by the queue pointer. Since the queue pointer is not validated to confirm that it resides within the enclave, an attacker who controls the queue pointer can write data into the enclave, thereby compromising the integrity of sensitive enclave data and resulting in an out-of-bounds write vulnerability.

Listing 2. SGX code with out-of-bounds read vulnerability.

Listing 3. SGX code with out-of-bounds write vulnerability.

Therefore, despite SGX’s strong hardware protections, memory corruption vulnerabilities in SGX applications remain a critical security concern. Detecting these vulnerabilities is essential for maintaining the security guarantees provided by SGX.

2.3. Shortcomings of Existing Analysis Tools

Unfortunately, existing tools such as TeeRex [39], COIN [40], SymGX [42], and IntraFuzz [43] approach specific types of SGX security issues primarily from the perspectives of symbolic execution or fuzzing.

However, they lack systematic analysis and characterization of memory corruption vulnerabilities in SGX projects, fail to implement fine-grained parameter-level taint modeling during call-chain construction, and adopt relatively inefficient call-chain exploration strategies for large search spaces.

Consequently, these tools suffer from high false positive rates, high false negative rates, and low efficiency in detecting such vulnerabilities, particularly under complex calling relationships.

During call chain construction, pruning is often performed at the function level, which results in low precision. Figure 2 illustrates such a scenario: when function A has few parameter taints, it cannot directly trigger a dangerous function.

However, if function B is invoked and subsequently calls function A again, the number of parameter taints in function A increases, ultimately enabling the dangerous function to be called.

In this case, function-level pruning alone may remove the critical path from function B to the heavily tainted function A, preventing the dangerous function from being reached and causing false negatives.

Furthermore, existing tools commonly employ relatively inefficient call chain construction strategies, such as depth-first search or random traversal, resulting in low overall efficiency and, in some cases, failure to complete within a finite time frame.

During call chain backtracking, the lack of fine-grained modeling of parameter-level taint states in existing tools prevents the distinction of parameter taint sources across different calling contexts, which can lead to false positives. As illustrated in Figure 3, when backtracking to function C, it may be unclear whether the current parameter taint state originates from function A or function B, which can lead to unrelated paths being misidentified as critical paths. Furthermore, existing tools often analyze all possible paths, including many unnecessary ones, resulting in inefficient call chain backtracking.

In summary, existing tools for SGX memory corruption vulnerability analysis still exhibit certain limitations in the systematic categorization of vulnerability characteristics, the precision of call chain construction in complex calling scenarios, and the efficiency of vulnerability analysis. To address these issues, We propose ParaTaintGX, a novel framework that ultimately enhances the accuracy and efficiency of SGX memory corruption vulnerability detection.

3. Related Work

Intel SGX, a cutting-edge hardware-based Trusted Execution Environment (TEE) technology, provides robust hardware protections for addressing data security and privacy concerns and has been extensively applied and studied in both academia and industry [26,27,28,29,30,31,32,33,34,57,58,59,60,61,62,63,64,65,66,67,68]. However, while offering these protections, the unique security model of SGX also introduces two new attack surfaces: side-channel attacks [69,70,71,72,73,74,75,76,77,78,79,80,81] and memory corruption vulnerabilities [38,39,40,41,42,48,49].

In the study of memory corruption vulnerabilities, Van Bulck et al. [49] revealed the inherent vulnerability of the enclave runtime environment; even when the enclave code itself is free of flaws, attackers may compromise its security by manipulating runtime libraries that mediate interactions between the enclave and the external environment. TeeRex [39] employs a symbolic execution engine to identify exploitable memory corruption primitives and explore the execution paths of enclave code. COIN [40] systematically examines the enclave attack surface along four dimensions—inputs, call sequences, concurrency, and nesting—by modeling adversarial interactions with enclave interfaces under these conditions. Guardian [41] employs symbolic execution to analyze SGX enclave code and verify whether data originating from the untrusted environment—such as ECALL parameters and OCALL return values—are properly validated, thereby identifying vulnerabilities arising from missing or insufficient input checks. SymGX [42] targets pointer operations that cross the trusted and untrusted boundaries of SGX applications, employing static symbolic execution to detect potential memory corruption vulnerabilities, while taking into account the multi-entry points and stateful execution characteristics of SGX applications. SGXFuzz [81] synthesizes nested pointer structures/size fields via fault signals, runs enclaves natively without SGX hardware, and detects memory corruption by mutating pointer locations to validate trust-boundary checks. FuzzSGX [82] parses EDL files for ECALL/OCALL interfaces, infers dependencies via static analysis and symbolic execution, generates host apps, and leverages a dedicated runtime to detect memory corruption and data races. EnclaveFuzz [35] extracts input structures/dependencies from enclave sources and EDL files, generates harnesses, fuzzes three input dimensions, and leverages an SGX-specific sanitizer and optimized SDK to detect memory corruption and SGX-specific vulnerabilities. IntraFuzz [43] uses an intra-enclave tracer, shared memory-based process management, and crash analysis via stack trace parsing to detect memory corruption vulnerabilities.

The works most closely related to ParaTaintGX include vulnerability detection tools such as IntraFuzz, SymGX, TeeRex, COIN, and other similar approaches [43,81]. However, these methods suffer from several limitations: unclear characterization of vulnerability features specific to SGX projects, inefficient search strategies during call-chain construction, and imprecise modeling of parameter-level taint states. When applied to complex calling relationships and parameter-sensitive SGX memory corruption vulnerabilities, these shortcomings result in constrained pruning precision and an inability to accurately trace taint propagation paths. Consequently, they are prone to generating false positives or false negatives in certain scenarios, ultimately leading to suboptimal effectiveness in detecting SGX memory corruption vulnerabilities.

4. Research Method

In this section, we first introduce the core components of ParaTaintGX, with a primary focus on its taint analysis architecture. We then illustrate how ParaTaintGX constructs call chains by treating the Function and Parameter Taint State as the fundamental analysis unit and leveraging a multi-node heuristic priority search algorithm. Finally, we present an efficient pruning strategy for call chain backtracking.

4.1. Framework

Figure 4 illustrates a taint analysis architecture designed according to SGX vulnerability patterns. The architecture consists of two major components: a call chain construction mechanism that adopts the "Function and Parameter Taint State” as its fundamental analytical unit, and a taint backtracking approach driven by the constructed call chains.

To construct call chains under the "Function and Parameter Taint State” abstraction, we begin by creating fine-grained call chain nodes corresponding to functions that contain taint sources and the entry-point taint states of their parameters. These nodes serve as entry points for analyzing the pcode intermediate representation of the associated functions and for performing intra-procedural taint propagation. When a new function call is identified in the intermediate code, if a node representing that function and its entry-point parameter taint states already exists, pruning is applied to avoid creating duplicate nodes; otherwise, a new fine-grained call chain node is instantiated based on the new function and its entry-point parameter taint states. This node is then linked with its predecessor node to extend the call chain. This procedure proceeds iteratively; however, instead of expanding nodes in a predetermined order, the exploration of the call chain is guided by a multi-node heuristic priority search algorithm. Specifically, newly generated nodes are inserted into a priority queue, and a heuristic scoring function is used to dynamically select high-priority nodes for further expansion, enabling an efficient and targeted construction of relevant call chains.

In the call-chain-based taint backtracking phase, we use the sink nodes collected during call chain construction to trace the corresponding taint propagation paths via our backtracking algorithm, ultimately generating vulnerability reports.

4.2. Call Chain Construction Based on Function and Parameter Taint State as the Fundamental Unit

In traditional static analysis, a call graph is modeled as a directed graph $G=(V,E)$. The vertex set V contains nodes representing program functions, where each node $v_i$ corresponds to a function identifier $f_i$.The edge set E consists of directed edges, and an edge $e_{ij}$=$(v_i,v_j)$ denotes that function $f_i$ invokes function $f_j$. A call chain is defined as a path within the graph G, typically denoted as $C=$ <$v_1$, $v_3$, $v_7$…, $v_k$>, meaning that function $f_1$ calls $f_3$, $f_3$ calls $f_7$, and this continues until reaching $f_k$.

However, traditional static analysis methods alone cannot capture information about parameter taint states during call chain construction and backtracking. To address this limitation, we design a call chain node that uses the Function and Parameter Taint State as its basic unit. We define a more fine-grained call chain node in the call graph as $V=(f,M,D,T,N,P)$, represented as a sextuple:

• f: The function identifier, consistent with the meaning of a call chain node in traditional call graphs.
• $M\in {\{0,1\}}^n$: A taint bit vector indicating the taint states of the n parameters of function f, where a value of 1 indicates a tainted parameter, while 0 indicates a clean parameter.
• $T=\left|M\right|={\sum }_{i=1}^n{b}_i$: The total number of tainted parameters in the current function.
• $D=depth\left(f\right)$: The length of the shortest path in the call chain from the taint source to function f.
• $N=\left|\mathrm{succ}\right(V\left)\right|$: The number of direct successor nodes reachable from the current node.
• $P=\{(V_{\mathrm{pre}},\pi )\mid \pi$ denotes the propagation path from $f_{\mathrm{pre}}$ to $f_{\mathrm{current}}$, and $(V_{\mathrm{pre}},V_{\mathrm{current}})\in E\}$: Indicates which function is called the current function and records the corresponding propagation path.

This sextuple design allows precise tracking of parameter taint states, improving the accuracy of call chain construction and backtracking in static analysis of SGX applications.

The structure of ParaTaintNode is illustrated in Listing 4. The fields taintsNum (number of tainted parameters), depth (shortest call depth from the taint source), and callNum (number of successor ParaTaintNodes) are primarily used in our multi-node heuristic priority search algorithm. The taintBitMap and address fields record the taint positions of the function, which are utilized to determine whether a ParaTaintNode has already been created during call chain construction for pruning purposes, and to assist the pruning process during call chain backtracking.The preParaTaintNodes field stores predecessor nodes to facilitate call chain backtracking and to maintain the corresponding taint propagation paths.

Listing 4. ParaTaintNode Structure.

4.2.1. ParaTaintNode for Mitigating Pruning False Negatives

During call chain construction, the complexity of function call relationships, including recursive and mutually recursive calls, often leads to loops and duplicate paths, which reduces the efficiency of call chain construction. To address this, the traditional call chain pruning strategy avoids revisiting nodes that have already been visited. Formally, given a call chain $G=\langle (v_1,e_{12}),(v_2,e_{23}),(v_3,e_{34}),\dots ,(v_i,e_{ik})\rangle$, if the next node $v_{\mathrm{k}}$ to be added satisfies $\exists v_j\in G$ such that $v_j=v_{\mathrm{k}}$ for some $(j\in \{1,2,3,4,\dots ,i\left\}\right)$, then $v_{\mathrm{k}}$ is pruned.

However, if pruning relies solely on functions as the basic unit, it may reduce duplicate paths and cycles, but it treats a function as a unique identifier and ignores that the same function may exhibit different behaviors under different parameter taint conditions. As a result, this strategy can lead to false negatives in the analysis.

As illustrated in Figure 5 and Listing 5, after the first invocation of e_get_result, subsequent functions such as e_mpz_add are executed, and result is updated to point to a valid internal enclave buffer with an actual length of len_result. When e_get_result is invoked again, it copies the contents of this enclave buffer to external memory. If an attacker can influence the parameter len, i.e., if len becomes tainted, this second invocation may result in an out-of-bounds read from the enclave buffer. However, under a function-level call chain construction strategy, this subsequent invocation of e_get_result is pruned for efficiency, causing the security-critical propagation path to be mistakenly discarded.

Therefore, in our Call Chain design, the ParaTaintNode incorporates a taint bitmap (taintBitMap) to explicitly record the taint status of the function’s parameters. The bitmap establishes a one-to-one correspondence between each parameter and a binary indicator, expressed as $M=(b_1,b_2,\dots ,b_n),b_i\in \{0,1\}$, where

$$b_j=\left\{\begin{array}{cc}1,\hfill & j\text{-th}\mathrm{parameter}\mathrm{of}\mathrm{the}\mathrm{function}\mathrm{is}\mathrm{taint}\hfill \\ 0,\hfill & j\text{-th}\mathrm{parameter}\mathrm{of}\mathrm{the}\mathrm{function}\mathrm{is}\mathrm{not}\mathrm{taint}\hfill \end{array}\right.$$

Listing 5. False Negatives in SGX Code Due to Pruning.

When the j-th parameter of a function is tainted, its corresponding bit $b_j$ is set to 1; otherwise, $b_j$ is set to 0. As illustrated in Figure 6, a taintBitMap value of 5—whose binary representation is 0101—indicates that the first and third parameters of the function represented by this ParaTaintNode are tainted.

By using the taintBitMap, we refine the pruning condition such that, in addition to matching function identities, the parameter taint configuration must also be consistent. Formally, let $G=\langle (v_1,e_{12}),(v_2,e_{23}),(v_3,e_{34}),\dots ,(v_i,e_{ik})\rangle$, where $v_j=(f_j,M_j,D_j,T_j,N_j,P_j)$ and $v_j\in G$, and $v_{\mathrm{k}}=(f_{\mathrm{k}},M_{\mathrm{k}},D_{\mathrm{k}},T_{\mathrm{k}},N_{\mathrm{k}},P_{\mathrm{k}})$. The next node $v_{\mathrm{k}}$ is pruned only if both the function identifiers match $f_j=f_{\mathrm{k}}$ and their taintBitMap are identical $M_j=M_{\mathrm{k}}$.

As illustrated in Algorithm 1, if the newly invoked function does not appear in previously generated call nodes (line 3), or it exists but with a different parameter taint state (line 6), then the corresponding ParaTaintNode has not been created yet (line 11). In this case, a new ParaTaintNode is instantiated and inserted into the priority queue prio_queue. Conversely, if the function already exists in prior call nodes with an identical taint bitmap, it indicates that this ParaTaintNode has already been generated during earlier Call Chain construction (line 9). Therefore, the node does not need to be traversed again and can be safely pruned.

Algorithm 1 ParaTaintNode Matching Algorithm

Input:  Set of all created ParaTaintNode nodes ParaTaintNodeList, address of newly called function address, taint position bitmap of current function taintBitMap Output:  Node paraTaintNode 1: function  getParaTaintNode (ParaTaintNodeList, address, taintBitMap) 2:      for paraTaintNode ∈ ParaTaintNodeList do 3:         if paraTaintNode.address ≠ address then                                   ▹ Check function address match 4:            continue                                                       ▹ Different function 5:         end if 6:         if paraTaintNode.taintBitMap ≠ taintBitMap then                      ▹ Compare parameter taint state under same address 7:            continue                                                        ▹ Different taint state 8:         end if 9:         return paraTaintNode                                                 ▹ Existing node found 10:     end for 11:     return null                                                      ▹ No matching node exists 12: end function

4.2.2. Multi-Node Heuristic Priority Search Algorithm

If Call Chain construction relies on depth-first search or purely random traversal, several challenges emerge:

1.

The explosive number of Call Chains renders effective path identification infeasible.

2.

The chain lengths may grow excessively.

3.

Irrelevant nodes that do not contribute to taint propagation may be explored.

4.

Numerous redundant paths may be repeatedly visited, ultimately degrading efficiency and potentially preventing the analysis from being completed within a practical time frame.

To address problems 1 and 2, let $G=(V,E)$ denote the call graph, where V is the set of function nodes and E is the set of call edges. Let $\mathrm{Path}\left(G\right)$ denote the set of all paths from source nodes to reachable nodes in G. Under unconstrained depth-first search (DFS) traversal, the total number of paths grows exponentially with the call depth:

$$|{\mathrm{Path}}_{\mathrm{explored}}\left(G\right)|=b+b^2+b^3+\dots +b^d=\sum _{i=1}^d{b}^i$$

(1)

In the Formulae (1), b is the average branching factor and d is the maximum call chain depth. When b and d are large, the number of paths explodes, making it computationally infeasible to efficiently identify vulnerability-relevant paths through exhaustive traversal.

To address these challenges, we transform the unconstrained search into a heuristic-guided priority search. We define a priority score function $\mathrm{Score}\left(v\right)$ for each unvisited ParaTaintNode $v\in G$, where nodes with higher scores are considered more likely to reach sink functions and are therefore expanded first.

We maintain a priority queue $\mathcal{Q}$ that stores all unvisited ParaTaintNodes ordered by their scores in descending order. Formally, for any two nodes $V_i,V_j\in \mathcal{Q}$:

$$V_i\mathrm{precedes}{V}_j\mathrm{in}\mathcal{Q}\iff \mathrm{Score}\left(V_i\right)>\mathrm{Score}\left(V_j\right)$$

(2)

At each iteration, the algorithm dequeues the node with the highest score from $\mathcal{Q}$ for expansion.

The priority score for a ParaTaintNode V is defined as

$$\mathrm{Score}\left(V\right)=\underset{\mathrm{Reward}\mathrm{term}R\left(V\right)}{\underbrace{w_1·N+w_2·T}}-\underset{\mathrm{Penalty}\mathrm{term}D\left(V\right)}{\underbrace{w_3·{\left(D\right)}^{\alpha }}}$$

(3)

In the Formulae (3):

• $N=|\mathrm{succ}(V)|$ represents the branching factor of node V, i.e., the number of potential callee functions reachable from V;
• T is the number of tainted parameters, reflecting the taint propagation potential;
• $D=\mathrm{depth}\left(V\right)$ is the shortest call chain distance from the source function to V, which penalizes nodes that are too far from the source;
• The weights $w_1=w_2=0.4$, $w_3=0.2$, and exponent $\alpha =1.2$ are empirically calibrated on a validation set of SGX applications.

The reward term $R\left(V\right)=w_{1}N+w_{2}T$ captures the local taint propagation potential. Intuitively, nodes with more outgoing edges (larger N) offer more opportunities to propagate taint to subsequent functions, while nodes with more tainted parameters (larger T) have higher likelihood of triggering dangerous operations. Hence, nodes with higher reward scores are prioritized for exploration.

The penalty term $D\left(V\right)=w_3{D}^{\alpha }$ introduces a non-linear depth penalty. This term discourages the exploration of excessively long call chains by reducing the priority of nodes far from the source, while the exponent $\alpha >1$ ensures that the penalty grows super-linearly with depth. This design preserves the possibility of reaching deeply nested but relevant paths while mitigating the impact of path explosion caused by unbounded depth.

The weighting parameters ($w_1=w_2=0.4$, $w_3=0.2$, and $\alpha =1.2$) are determined through a systematic experimental tuning procedure on a validation set of SGX applications. Equal weights are assigned to N and T to reflect their respective contributions to taint propagation potential. The depth penalty weight $w_3$ is set to a relatively low value in order to avoid overly aggressive pruning of deeply nested yet potentially relevant paths, while still discouraging unnecessary exploration. The exponent $\alpha$ introduces a mild nonlinear growth in the depth penalty, enabling a balanced trade-off between analysis completeness and efficiency. Our experimental results indicate that moderate variations of these parameters do not significantly affect detection outcomes, suggesting that the scoring function is robust with respect to parameter selection.

Unlike the exhaustive DFS described in Formula (1), our heuristic-guided priority search selectively expands only a subset of nodes. Let $p_i$ denote the probability that a node at depth i is selected for expansion. Due to the depth penalty term $D\left(V\right)$, we have

$$p_1<1,p_2\ll p_1,p_3\ll p_2,\dots ,p_d\ll 1$$

Importantly, not all nodes at a given depth are selected; each node’s selection probability is independently governed by the priority score. The expected number of explored paths is

$$|{\mathrm{Path}}_{\mathrm{explored}}\left(G\right)|=\sum _{i=1}^d{b}^i·p_i$$

Since $p_i$ decays rapidly with depth ($p_i\to 0$ as i increases), the contribution of deeper layers becomes negligible, effectively mitigating the path explosion problem.

In summary, the priority value of a ParaTaintNode is computed by summing the number of functions it can call and the number of its parameter taints, and then subtracting its shortest path length. This design encourages the exploration of new ParaTaintNode nodes, prioritizes nodes more likely to reach sink functions, and mitigates the negative impact of excessively long call chains on analysis efficiency.

As shown in Algorithm 2, we customize a PriorityQueue by defining a dedicated Comparator to order stored ParaTaintNode instances according to a predefined scoring function. Specifically, the compare method of the Comparator interface is overridden (line 2) to establish the node comparison logic. For two ParaTaintNode objects, denoted as node1 and node2, their corresponding scores, score1 and score2, are first computed (line 3 and line 4). The nodes are then sorted in descending order using Double.compare (score2, score1) (line 5), ensuring that the priority queue consistently processes taint nodes with higher scores first.

Algorithm 2 Priority Queue Comparator

Input:  Two ParaTaintNode instances node1 and node2 Output:  Integer where: - positive value: node2 has higher priority than node1, - zero: node1 and node2 have equal priority, - negative value: node1 has higher priority than node2 1: Define Comparator <ParaTaintNode> taintNodeComparator:              ▹ Custom comparator for ParaTaintNode priority ordering 2: function compare(node1, node2) 3:     score1 ← w1 * node1.taintsNum + w2 * node1.callNum − w3 * Math.pow(node1.depth, alpha)             ▹ Calculate priority scores 4:     score2 ← w1 * node2.taintsNum + w2 * node2.callNum − w3 * Math.pow(node2.depth, alpha) 5:     return Double.compare(score2, score1)                                ▹ Descending order (higher score first) 6: end function

To address problem 3, if all parameters of a newly invoked function are clean, neither this function nor the functions it subsequently calls can contribute to taint propagation. However, conventional call-chain construction algorithms still include such functions, resulting in a large number of ineffective paths. Therefore, when performing taint analysis on the Pcode intermediate representation of the function associated with a ParaTaintNode, we evaluate whether any of its parameters are tainted. If no taint exists—i.e., V(T) = 0 or V(M) = (0, 0, 0, …, 0)—the function and its subsequent paths are excluded from further analysis.

Algorithm 3 illustrates how call chain construction is integrated with intra-function taint propagation to analyze taint flows within the current function. Based on the call opcode in pcode and the taint status of function parameters, the algorithm determines whether a new mapping to a callee function should be established by creating a corresponding ParaTaintNode. Initially, the taint propagation path is initialized (line 2), and the control flow graph of the target function is retrieved (line 3). Using the source information contained in the current ParaTaintNode, the relevant basic blocks are identified and inserted into an initial worklist (line 5). The algorithm then enters the main loop, iterating over all basic blocks in the worklist. Within each basic block, all pcode instructions are processed sequentially (line 11). For each instruction, taint propagation is performed to update both the taint set and the associated propagation path (line 12). When a call opcode is encountered, a critical decision is made (line 13). If any input varnode of the call instruction is tainted, the target function address is extracted, and a taint bitmap for the callee’s parameters is computed. A new ParaTaintNode is then created and inserted into the priority queue as well as the global node list (line 16). This newly created node is linked to the current paraTaintNode, thereby extending the call chain while preserving the taint propagation path. If the new node corresponds to a sink function, such as strcpy, memcpy, or snprintf, which are representative data-copy-related functions, it is added to the sinkParaTaintNodeList for subsequent backward analysis (line 17). After all pcode instructions within a basic block have been processed, the resulting taint set is associated with that block (line 22). The algorithm continues processing remaining basic blocks in the worklist until the list is exhausted, completing intra-function taint propagation for the current function.

Algorithm 3 Taint Propagation Analysis Function Algorithm

Input:  Taint analysis function func, call chain node paraTaintNode, dangerous function node set sinkParaTaintNodeList, priority queue priority_queue, set of all created nodes ParaTaintNodeList Output:  No return value 1: function funcTaintsFlow(func, paraTaintNode, sinkParaTaintNodeList, priority_queue, ParaTaintNodeList) 2:     path ← initPath()                                                                ▹ Initialize taint propagation path 3:     cfg ← getCfg(func)                                                                 ▹ Extract control flow graph 4:     sourceBlock ← getSourceBlock(cfg, getSource(paraTaintNode)) 5:     basicBlockList ← InitWorkList(sourceBlock)                                                 ▹ Initialize worklist with source blocks 6:     while basicBlockList ≠ null do 7:         basicBlock ← getBasicBlock(basicBlockList) 8:         addSuccBasicBlockToWorklist(basicBlockList, basicBlock)                                               ▹ Add successors to worklist 9:         taintSet ← getTaintSetByPreBasicBlock(basicBlock)                                              ▹ Merge taint sets from predecessors 10:         pcodes ← getPcodeByBasicBlock(basicBlock)                                               ▹ Get intermediate representations pcode 11:         for pcode ∈ pcodes do 12:            taintFlow(pcode, taintSet, path)                                                      ▹ Propagate taints and update path 13:            if getOpcode(pcode) $==$ CALL and inVarnode ∈ taintSet then 14:                targetFuncAddr ← getAddress(pcode)                                                       ▹ Extract callee address 15:                taintBitMap ← getTaintBitMap(pcode, taintSet) 16:                newParaTaintNode ← AddNewParaTaintNode(priority_queue, ParaTaintNodeList, paraTaintNode, targetFuncAddr, taintBitMap, path) ▹ Create new call chain node and establish link 17:                if isSinkFunction(newParaTaintNode) then 18:                    addSinkParaTaintNodeList(newParaTaintNode, sinkParaTaintNodeList)    ▹ Add sink nodes corresponding to data-copy-related sink functions (e.g., strcpy, memcpy, snprintf) 19:                end if 20:            end if 21:         end for 22:         basicBlock ← AddtaintSet(basicBlock, taintSet)                                                 ▹ Attach final taint set to basic block 23:     end while 24: end function

To address problem 4, when loops or mutually recursive calls occur within the program, our modeling strategy—where each distinct ParaTaintNode is uniquely defined by its function and associated parameter taint state—allows us to enforce a single-visit policy for each node. This effectively prevents redundant exploration of call paths arising from cyclic or mutually recursive structures.

Accordingly, we maintain a ParaTaintNodeList that records all ParaTaintNode instances created during call chain construction. Before inserting a new ParaTaintNode into the prio_queue, we first check whether it already exists in this list. If so, the node is not re-created or re-enqueued. In this way, ParaTaintNodeList guarantees that each ParaTaintNode is processed at most once.

Algorithm 4 illustrates the construction procedure of a ParaTaintNode, which enforces that each node is visited at most once. After taint propagation identifies the functions invoked by the current function, the getParaTaintNode method determines—based on the callee’s address and its parameter taint state—whether a corresponding ParaTaintNode already exists in the previously constructed Call Chain (line 3). If such a node is found, it is excluded from reinsertion into the priority queue prio_queue; instead, only its predecessor reference (line 8) and shortest path distance (line 7) are updated. Conversely, if no existing node matches the current function invocation, a new ParaTaintNode is initialized (line 4) and inserted into prio_queue for subsequent exploration (line 5).

Algorithm 4 Adding New ParaTaint Node Algorithm

Input:  Priority queue priority_queue, set of all created nodes ParaTaintNodeList, predecessor node preParaTaintNode, current function address targetFuncAddr, parameter taint bitmap taintBitMap, taint propagation path from predecessor node to current node path Output:  Call chain node newParaTaintNode 1: function AddNewParaTaintNode(priority_queue, ParaTaintNodeList, preParaTaintNode, targetFuncAddr, taintBitMap, path) 2:     newParaTaintNode ← getParaTaintNode(ParaTaintNodeList, targetFuncAddr, taintBitMap) ▹ Check if node already exists 3:     if newParaTaintNode $==$ null then 4:         newParaTaintNode ← new ParaTaintNode(getTaintsNum(taintBitMap), preParaTaintNode.depth $+1$, getCallNum(address), taintBitMap, address) ▹ Initialize new node(prevents redundant analysis) 5:         addParaTaintNode(priority_queue, ParaTaintNodeList, newParaTaintNode)▹ Add to priority_queue and ParaTaintNodeList 6:     end if 7:     newParaTaintNode.depth ← min(preParaTaintNode.depth $+1$, paraTaintNode.depth) ▹ Update minimal call chain depth 8:     addPreParaTaintNode(newParaTaintNode, preParaTaintNode, path)▹ Establish predecessor link with propagation path 9:     return newParaTaintNode 10: end function

4.2.3. Path Backtracking

After the call chain construction is completed, we backtrack from the ParaTaintNode associated with the dangerous function to the ParaTaintNode corresponding to the source function. Since each ParaTaintNode records the taint propagation segment from its predecessor to itself, concatenating these segments along the same chain yields the final taint propagation path.

In the call chain backtracking process, considering only inter-function invocation relationships without incorporating taint flow semantics may incorrectly classify non-taint-related paths as dangerous, thereby producing false positives. As illustrated in Listing 6, the actual vulnerable paths are ecall_process_network → internal_function_B → ocall_write_to_network and ecall_process_log → internal_function_B → ocall_write_to_log. However, if the Call Chain is built solely based on function invocation relationships, the case depicted in Figure 7 can arise. During call chain backtracking, the absence of parameter-level taint information prevents us from distinguishing the true data-dependent path, potentially leading to an incorrect interpretation such as ecall_process_network → internal_function_B → ocall_write_to_log, which ultimately causes false positive reports.

By adopting our call chain construction method that treats the "Function and Parameter Taint State" as the fundamental analysis unit, these false positives are effectively eliminated. As illustrated in Figure 8, the backtracking process ultimately yields two valid taint propagation paths, both of which actually exist in the program.

Moreover, after constructing the Call Chain using ’Function and Parameter Taint State’ as the basic abstraction unit, some redundant paths may still remain in the resulting chain. These irrelevant chains introduce unnecessary overhead and therefore degrade efficiency during the subsequent backtracking phase.

Listing 6. False Positive Example in Path Backtracking.

To eliminate redundant backtracking paths, we formalize a taint-aware pruning strategy based on subset comparison of taint bitmaps.

For two ParaTaintNodes, $V_i=(f_i,M_i,D_i,T_i,N_i,P_i)$ and $V_j=(f_j,M_j,D_j,T_j,N_j,P_j)$, with the same function identifier ($f_i=f_j$), we say that $V_i$ is taint-subsumed by $V_j$, denoted as $V_i\subseteq V_j$, if and only if

$$f_i=f_j\mathrm{and}{M}_i\subseteq M_j$$

During backtracking from sink to source, let ${\mathcal{P}}_{\mathrm{cur}}=\langle V_{\mathrm{cur}},V_{{\mathrm{prev}}_1},V_{{\mathrm{prev}}_2},\dots ,V_{\mathrm{sink}}\rangle$ be the current path under exploration. Let $V_{\mathrm{cur}}$ be the current node. If there exists a previously visited node $V_{\mathrm{prev}}\in {\mathcal{P}}_{\mathrm{cur}}$ such that

$$V_{\mathrm{prev}}\subseteq V_{\mathrm{cur}}$$

then further backtracking from $V_{\mathrm{cur}}$ is pruned. This process is illustrated in Algorithm 5.

Algorithm 5 Pruning Condition Check

Input:  Previously visited node kParaTaintNode, current node currentParaTaintNode Output:  Boolean indicating whether pruning is applicable 1: function AddNewParaTaintNode(kParaTaintNode, currentParaTaintNode) 2:     if $(kParaTaintNode.taintBitMap\&currentParaTaintNode.taintBitMap)==kParaTaintNode.taintBitMap$ then 3:         return True                             ▹ Pruning applicable 4:     else 5:         return False                          ▹ Continue forward tracing 6:     end if 7: end function

4.2.4. Precision–Efficiency Trade-Off

Static analysis tools for vulnerability detection often face a fundamental trade-off between precision and efficiency. Highly precise analysis typically requires fine-grained modeling of program states, which can significantly increase the analysis space and computational overhead. Conversely, aggressive pruning and coarse-grained modeling may improve efficiency but often introduce false positives or false negatives.

ParaTaintGX is designed to balance this trade-off through a combination of fine-grained taint modeling and heuristic exploration strategies.

ParaTaintGX improves detection precision by introducing the ParaTaintNode model, which represents a function together with its parameter taint state. Compared with traditional function-level call graph nodes, this representation distinguishes different invocation contexts based on the differences in parameter taint. As a result, ParaTaintGX can avoid incorrect pruning of vulnerability-relevant paths and significantly reduce false negatives during call-chain construction.

However, parameter-level taint modeling may increase the number of potential analysis states. To mitigate this overhead and maintain scalability, ParaTaintGX integrates two efficiency-oriented mechanisms.

First, a multi-node heuristic priority search algorithm is adopted to guide the exploration of the call graph. By prioritizing nodes with larger taint propagation potential and shorter distances to the source, the algorithm focuses on paths that are more likely to reach vulnerability sinks, thereby reducing unnecessary exploration of irrelevant call chains.

Second, ParaTaintGX introduces a taint-state-aware pruning strategy during backward tracing. If the taint state of a newly visited node contains that of a previously visited node, further exploration of that path is pruned. This strategy effectively eliminates redundant analysis paths while preserving vulnerability-relevant propagation chains.

Through the combination of parameter-sensitive taint modeling, heuristic exploration, and taint-aware pruning, ParaTaintGX achieves a practical balance between analysis precision and computational efficiency.

5. Evaluation

In this section, we collected publicly available SGX applications to conduct an experimental evaluation of our proposed method. To comprehensively assess the performance of ParaTaintGX, we formulated the following research questions:

RQ1: 

How effective is ParaTaintGX in detecting known vulnerabilities?

RQ2: 

How effective is ParaTaintGX in identifying vulnerabilities in real-world SGX applications?

RQ3: 

How accurate are the vulnerability reports generated by ParaTaintGX in real-world SGX applications?

RQ4: 

Can ParaTaintGX achieve higher code coverage than baseline approaches?

RQ5: 

How does ParaTaintGX perform without the multi-node heuristic priority search algorithm?

5.1. Test Set

We collected 27 SGX-related applications from GitHub [83], successfully compiled them and selected 10 representative SGX applications [84,85,86,87,88,89,90,91,92,93]. In addition, we selected 12 publicly available CVE vulnerabilities from SGX projects such as Asylo and sgxwallet [45,46,47,50,51,52,54,55,56,94,95,96]. Based on an in-depth analysis of their underlying vulnerability mechanisms, we manually reproduced these vulnerabilities and implemented corresponding test programs, which were subsequently used as a benchmark for evaluation. These selected applications and vulnerabilities are widely representative, allowing a more comprehensive evaluation of our proposed approach.

The details of the open-source GitHub applications are presented in

Table 1. Details of Open-Source GitHub Applications.

Project	Version	#.ECall	#.OCall
sgx-log [85]	7b5530e	4	6
TaLoS [86]	6405695	207	58
Asylo [84]	fa6485c	5	13
Sgx-reencrypt [87]	6f06591	4	4
sgxwallet [88]	da89bfe	18	3
SGXCryptoFile [89]	92f3cd6	38	12
Sgx-biniax2 [90]	35aaa1e	3	4
opaque [93]	68223fe	16	5
ShieldStore [91]	5de0122	3	3
Verifiable-election [92]	5f0f9f1	7	2

. For each GitHub application, we have collected the number of OCall entries (#.OCall) and ECall entries (#.ECall), which reflect the complexity of the SGX applications.

5.2. Experimental Setup

ParaTaintGX, developed based on the Ghidra framework, serves as our analysis tool. All experiments were conducted on a Windows 11 PC equipped with an AMD Ryzen 7 5800H CPU and 16 GB of memory.

In our experiments, all data flowing from the untrusted environment to the trusted enclave environment are considered as sources. This includes pointer-type parameters in ECall interfaces as well as memory regions allocated from the external operating system via OCall. Furthermore, all parameters of functions that perform memory copy operations are defined as sinks to accurately capture potential out-of-bounds read and write behaviors.

To accurately evaluate the vulnerability detection capabilities of ParaTaintGX, we selected three industry-recognized state-of-the-art SGX vulnerability detection tools—IntraFuzz, SymGX, and TeeRex—as baseline tools for comparison. All factors were kept constant, and a time limit of 12 h was set to avoid any bias arising from differences among the tools.

5.3. Detection Performance on Known Vulnerabilities

To answer RQ1, we evaluated all tools using a vulnerability set comprising 12 real CVEs. The assessment metrics included Precision, Recall, F1-Score and Average Detection Time. Precision quantifies the accuracy of the system and is defined as the ratio of true positives (TP) to the total number of reported cases (true positives (TP) plus false positives (FP)):

$$\mathrm{Precision}={\displaystyle \frac{TP}{TP+FP}}$$

(4)

Recall measures the completeness of detection and is defined as the ratio of true positives to the total number of actual vulnerabilities (true positives (TP) plus false negatives (FN)):

$$\mathrm{Recall}={\displaystyle \frac{TP}{TP+FN}}$$

(5)

The F1-Score provides a balanced measure combining both Precision and Recall:

$$\mathrm{F}1\text{-}\mathrm{Score}=2\times {\displaystyle \frac{\mathrm{Precision}\times \mathrm{Recall}}{\mathrm{Precision}+\mathrm{Recall}}}$$

(6)

Average Detection Time measures the average time consumed by a tool to complete one full vulnerability detection cycle on a single CVE test set. Cases exceeding the predefined time limit are considered failures.

We evaluated ParaTaintGX, IntraFuzz, SymGX, and TeeRex on a test set comprising 12 CVEs. For each tool, we measured the numbers of true positives (TP), false positives (FP), false negatives (FN) and the average detection time (ADT). The computed core performance metrics are summarized in

Table 2. Core Performance Metrics.

Tool	TP	FP	FN	Recall	Precision	F1-Score	ADT
TeeRex	5	1089	7	41.7%	0.46%	0.009	31.17 ± 6.14 min
SymGX	6	12	6	50.0%	33.3%	0.399	12.90 ± 3.66 min
IntraFuzz	7	29	5	58.3%	19.4%	0.291	26.24 ± 8.13 min
ParaTaintGX	9	8	3	75.0%	52.9%	0.620	11.12 ± 3.26 min

and illustrated in Figure 9.

ParaTaintGX successfully detected 9 of the 12 vulnerabilities, achieving a recall of 75%. This result outperforms IntraFuzz (58.3%), SymGX (50%), and TeeRex (41.7%). In terms of the F1-score, ParaTaintGX achieved 0.620, which is significantly higher than SymGX (0.399), IntraFuzz (0.291), and TeeRex (0.009). These results indicate that ParaTaintGX provides a better balance between detection accuracy and completeness.

Regarding detection efficiency, ParaTaintGX required an average of 11.12 ± 3.26 min to analyze a vulnerability case. This is substantially faster than IntraFuzz (26.24 ± 8.13 min) and TeeRex (31.17 ± 6.14 min), and slightly faster than SymGX (12.90 ± 3.66 min).

To further assess the detection capabilities of ParaTaintGX, we analyzed the False Negative Rates (FNR) of ParaTaintGX, SymGX, IntraFuzz, and TeeRex across two vulnerability categories: out-of-bounds read and out-of-bounds write vulnerabilities. This analysis was conducted on the same set of 12 publicly disclosed CVEs.

As illustrated in Figure 10, ParaTaintGX achieves the lowest overall FNR among all evaluated tools.

For out-of-bounds read vulnerabilities, ParaTaintGX achieves an FNR of 28.5%, which is substantially lower than that of IntraFuzz (42.9%), SymGX (57.1%), and TeeRex (71.4%).

For out-of-bounds write vulnerabilities, the FNR of ParaTaintGX further decreases to 20%. In comparison, IntraFuzz, SymGX, and TeeRex all exhibit an FNR of 40%.

These results demonstrate that ParaTaintGX maintains superior detection capability across different vulnerability categories when compared with the baseline tools.

5.4. Vulnerability Detection Effectiveness

To answer RQ2, we evaluated ParaTaintGX and three baseline tools on a dataset containing 10 real-world SGX applications.

The vulnerability reports generated by the tools were manually verified to ensure correctness. The verified results are summarized in

Table 3. Vulnerability detection results on real SGX applications.

Project	TeeRex [39]		SymGX [42]		IntraFuzz [43]		ParaTaintGX#		ParaTaintGX
	Alerts	Vul	Alerts	Vul	Alerts	Vul	Alerts	Vul	Alerts	Vul
Asylo [84]	821	4	12	6	23	6	17	7	11	8
Sgx-log [85]	282	0	11	0	16	0	10	0	7	0
TaLoS [86]	401	1	18	1	12	1	15	1	10	1
Sgxreencrypt [87]	92	0	0	0	5	0	0	0	0	0
Sgxwallet [88]	273	1	6	0	13	1	11	0	6	1
SGXCryptoFile [89]	744	0	5	0	8	1	12	0	4	0
Sgx-biniax2 [90]	691	2	9	0	12	0	11	0	7	0
Opaque [93]	529	0	10	0	11	0	13	0	8	0
ShieldStore [91]	321	1	4	1	9	0	6	1	3	1
Verifiable-election [92]	410	0	7	1	15	1	12	1	6	1
Total	4564	9	82	9	124	10	107	10	62	12
# ParaTaintGX# denotes the variant with the Multi-node Heuristic Priority Search Algorithm disabled.

. In the table, the column ‘alerts’ represents the total number of vulnerability reports generated by each tool, while ‘vul’ denotes the number of vulnerabilities confirmed through manual validation.

Across the evaluated applications, ParaTaintGX identified a total of 12 vulnerabilities. In comparison, IntraFuzz detected 10 vulnerabilities, while both TeeRex and SymGX detected only 9.

These results indicate that ParaTaintGX is capable of discovering more vulnerabilities than the baseline tools, demonstrating its effectiveness in detecting security issues in real-world SGX applications.

5.5. Precision of Vulnerability Reports

Detection rate alone is insufficient for evaluating vulnerability detection tools. Precision is also a critical metric because a large number of false positives can obscure real vulnerabilities and significantly increase the manual auditing effort required from developers.

To answer RQ3, we conducted vulnerability mining experiments on 10 open-source SGX applications and compared the precision of ParaTaintGX with three baseline tools. The detailed results are summarized in Table 3. Precision is defined as the ratio of confirmed vulnerabilities (Vul) to the total number of reported alerts (Alerts).

$$\mathrm{Precision}={\displaystyle \frac{\mathit{Vul}}{\mathit{Alerts}}}$$

(7)

The results reveal that TeeRex produces a large number of false positives. It reported 4564 potential vulnerabilities, but only 9 were confirmed as real vulnerabilities after verification, yielding a precision of only 0.2%. For example, in the Sgxwallet project, TeeRex generated 273 vulnerability reports, but only one real vulnerability was confirmed. This significantly increases the effort required for manual verification.

In comparison, IntraFuzz and SymGX achieve higher precision. IntraFuzz reported 124 vulnerabilities and identified 10 real vulnerabilities, resulting in a precision of 8.06%. SymGX reported 82 vulnerabilities, with 9 confirmed cases, achieving a precision of 10.98%.

ParaTaintGX generated 62 vulnerability reports, of which 12 were confirmed as real vulnerabilities. This results in a precision of 19.35%, which significantly outperforms SymGX (10.98%). The comparison is illustrated in Figure 11.

5.6. False Positive Analysis

By analyzing false positive cases, we have identified two main sources. First, inaccuracies in pointer analysis: the intermediate code layer has limited expressiveness for memory aliases and pointer offsets, leading to ambiguous taint propagation through memory pointers. This inaccuracy in taint analysis ultimately results in false positives. Second, incomplete modeling of boundary check semantics: some programs already incorporate effective boundary protection mechanisms that are not explicitly recognized by ParaTaintGX, consequently generating false positives.

We conducted a quantitative attribution analysis on 50 false positive cases: 32 cases (64%) originated from inaccuracies in pointer analysis, while the remaining 18 cases (36%) were attributed to incomplete modeling of boundary check semantics.

5.7. Code Coverage

To answer RQ4, we conducted a systematic comparative analysis of the code coverage achieved by ParaTaintGX and three baseline tools on real SGX applications, aiming to assess the practical contribution of our method to code coverage. The complete results are presented in Figure 12. Overall, ParaTaintGX achieved the highest code coverage across all tested applications, with an average coverage of 59.45%, significantly outperforming SymGX (48.33%), TeeRex (38.98%), and IntraFuzz (17.51%). This result indicates that ParaTaintGX is able to explore more effective code regions related to taint propagation within a limited analysis time.

This advantage can be attributed to our designed multi-node heuristic priority search algorithm. This mechanism enables the prioritized exploration of call-chain nodes that are more likely to reach dangerous functions, thereby avoiding the waste of analysis resources on a large number of irrelevant or low-value paths. It also effectively addresses the decline in analysis efficiency caused by excessively long call chains and reduces analysis redundancy for complex calling structures through pruning. Ultimately, ParaTaintGX achieves higher code coverage.

5.8. Ablation Study

To answer RQ5, we evaluate the effectiveness of the Multi-node Heuristic Priority Search Algorithm in ParaTaintGX by comparing the tool’s performance with and without this algorithm in terms of code coverage and vulnerability detection capability.

Figure 12 and Table 3 present the experimental results, where ParaTaintGX# denotes the variant of ParaTaintGX that keeps all other components unchanged but disables the Multi-node Heuristic Priority Search Algorithm. As shown in Table 2, ParaTaintGX# is still able to detect 10 vulnerabilities and outperforms all baseline methods. This result validates the effectiveness of our fine-grained modeling of parameter-level taint states.

We also measured the code coverage achieved by ParaTaintGX when the Multi-node Heuristic Priority Search Algorithm was disabled. The average coverage was 53.94%, which increases by 5.51 percentage points after enabling the algorithm.

As described in Section 4.2.2, with the Multi-node Heuristic Priority Search Algorithm enabled, ParaTaintGX detected a total of 12 vulnerabilities. This improvement stems from the algorithm’s ability to skip nodes that have already been visited or exhibit no taint-propagation capacity, while prioritizing the exploration of nodes more likely to reach dangerous functions. Therefore, we conclude that the Multi-node Heuristic Priority Search Algorithm effectively enhances the overall performance of ParaTaintGX.

5.9. Scalability and Limitations Discussion

Although the current evaluation is conducted on 12 publicly disclosed CVE vulnerabilities and 10 open-source SGX applications, the design of ParaTaintGX aims to support scalable analysis on larger SGX software ecosystems.

From the perspective of scalability, ParaTaintGX performs vulnerability detection through a call-chain exploration framework guided by parameter-level taint states. The multi-node heuristic priority search algorithm prioritizes nodes that are more likely to reach sink functions, thereby avoiding exhaustive traversal of low-value paths. This design significantly reduces the search space during analysis and enables the framework to scale to larger code bases with complex calling structures.

In addition, the pruning strategy applied during backtracking further reduces redundant path exploration. This helps maintain analysis efficiency as the program size increases.

Regarding generalization, ParaTaintGX focuses on common memory corruption patterns in SGX enclave programs. Since these vulnerability patterns widely exist in SGX applications that interact with untrusted environments through ECALL and OCALL interfaces, the proposed analysis approach can be applied to a broad range of SGX-based systems.

Nevertheless, several limitations remain in large-scale real-world deployments.

First, the precision of static taint analysis depends on the accuracy of pointer analysis. For programs with highly complex pointer operations or indirect memory accesses, the analysis may still produce false positives.

Second, some application-specific boundary checks implemented through customized logic may not be fully recognized by the current modeling approach, ultimately leading to false positives.

Despite these limitations, the experimental results on representative SGX applications and real CVEs demonstrate that ParaTaintGX provides a practical and effective solution for detecting memory corruption vulnerabilities in SGX enclave programs.

6. Conclusions and Future Work

Memory corruption vulnerabilities pose a critical threat to SGX applications, as they enable attackers to hijack control flow within an enclave, modify its data variables and pointers, and ultimately lead to data leakage or tampering. However, detecting such vulnerabilities remains challenging for state-of-the-art analysis methods. This is primarily due to insufficient definition of SGX-specific vulnerability patterns and the limited precision in function call chain construction.

To address these challenges, we propose a novel approach, ParaTaintGX. Our tool specifies prevalent memory corruption vulnerability types in SGX and, during static analysis, constructs call chains based on the combination of function identifiers and parameter taint states. This approach mitigates false negatives caused by aggressive pruning during chain construction and reduces false positives introduced during backtracking. Furthermore, we introduce a multi-node heuristic priority search algorithm to significantly enhance the efficiency of call chain construction. Finally, a dedicated pruning strategy is employed during backtracking to further improve analysis performance. In our evaluation, ParaTaintGX identified 12 vulnerabilities across 10 open-source projects, whereas existing tools detected only a small subset of these. Overall, ParaTaintGX demonstrates superior effectiveness in detecting memory corruption vulnerabilities compared to current solutions.

Despite the effectiveness of static analysis guided by SGX vulnerability patterns, vulnerability reports still require manual validation. Such validation demands substantial domain expertise to reason about input sources, execution contexts, and feasible triggering conditions, which imposes a high auditing cost. In future work, we plan to integrate the static analysis results produced by ParaTaintGX with directed fuzzing techniques, enabling automated validation and exploitation of suspicious taint-propagation paths. This combination is expected to substantially reduce manual effort while improving the reliability and practicality of vulnerability verification.