DSLR–: A low-overhead data structure layout randomization for defending data-oriented programming

Abstract

By developing a Turing-complete non-control data attack to bypass existing defenses against control flow attacks, Data-Oriented Programming (DOP) has gained significant attention from researchers in recent years. While several defense techniques have been proposed to mitigate DOP attacks, they often introduce substantial overhead due to the blind protection of a large range of data objects. To address this issue, we focus on selecting and protecting the specific target data that are of interest to DOP attackers, rather than securing the entire non-control data in the program. In this regard, we perform static analysis on 20 real-world applications and identify the target data, verifying that they constitute only a small percentage of the overall program, averaging around 3%. Additionally, we propose a semi-automated tool to analyze how to chain operations on the target data in these 20 applications to achieve Turing-complete attacks. Furthermore, we introduce DSLR-: a low-overhead Data Structure Layout Randomization (DSLR) method, which modifies the existing DSLR technique to only randomize the selected target data for DOP. Experimental results demonstrate that DSLR- effectively mitigates DOP attacks, reducing performance overhead by 71.2% and memory overhead by 82.5% compared to the original DSLR technique.

Keywords

Memory corruption attacks data-oriented programming data structure layout randomization

1. Introduction

For decades, memory corruption attacks [27,55] have remained a significant security threat in the cyberspace. These attacks exploit software vulnerabilities and require minimal prerequisites to be launched, contributing to their prevalence. Memory corruption attacks can be categorized into two types based on the corrupted data: control-flow hijacking attacks, which manipulate control data (e.g., code injection attacks [16], code reuse attacks [4,60,67]), and data-oriented attacks, which manipulate non-control data (e.g., direct data manipulation (DDM) [9], data-oriented programming (DOP) [25]). However, the widespread adoption of protection mechanisms for control data, such as data execution prevention (DEP) [53], StackGuard [61], address space layout randomization (ASLR) [51], and control-flow integrity (CFI) [24,32], makes it challenging for attackers to manipulate control data. As a result, attackers shift their focus to exploring alternative attack vectors and increase their attention on non-control data. Recent research by Hu et al. [25] reveals that (non-control) data-oriented programming (DOP), which focuses on manipulating non-control data, can also cause significant harm to programs. In advanced attack practices, Turing-complete attacks can be achieved by chaining numerous data-oriented gadgets.

In fact, several defenses can mitigate DOP attacks, for example, data encryption [3,7,57], data structure layout randomization (DSLR) [8,41] and data flow integrity (DFI) [20,43] provide barrier for attackers to identify, locate and manipulate the desired data. Pointer-based bounds checking (PBC) [18,19,45] verifies that access through a pointer is in bounds. Pointer authentication code (PAC) [34,40] protects the integrity of pointers. However, we observe that existing defenses result in high performance overhead due to the large scope of the data to be protected. And the non-negligible overhead prevents them to be widely adopted in production environments. Hence, there is an urgent need for a light-wight and effective protection scheme.

In this paper, we try to propose a target-specific method for data protection, i.e., to protect only the selected data targeted by DOP attacks. Firstly, we collect, classify the target data of the real-world programs and analyze how DOP operates on these data. Specifically, we analyze the LLVM intermediate representation (IR) code of 20 real-world applications, and develop a semi-automated tool to analyze how to chain operations on the target data to achieve Turing-complete attacks. Additionally, we verify that the amount of target data is relatively small, averaging around 3%. Secondly, we propose DSLR–, which modify the existing DSLR tool [41] to randomize the absolute address of target data and relative distances between them. Thirdly, we design experiments to evaluate the effectiveness and overhead of the proposed scheme. The experiments show that randomizing the target data can effectively resist DOP. In addition to this, compared to the original DSLR tool, our randomization tool reduces the performance overhead by 71.2% and the memory overhead by 82.5%.

In conclusion, this paper makes several contributions:

We perform static analysis on 20 real-world applications to identify the target data manipulated by the DOP. We calculate the percentage of these target data and show that target data are only a small part of total data in the program.

We propose DSLR– that is able to randomize the absolute address of target data and the relative distance between them. Our experiments verify that our tool can effectively resist DOP and greatly reduce the performance overhead and memory overhead of original DSLR tools.

We introduce a semi-automated tool can analyze how to chain operations on target data to achieve Turing-complete attacks, which previously could only be achieved by the researcher’s intuition. Moreover, we analyze 20 real-world applications and find that Openssl [49], libpcap [38] and libpng [39] have exploitable complete DOP attack chains, which is not found in existing researches.

2. Background

2.1. DOP attacks

Fig. 1.

The process and requirements of DOP attack.

Non-control data attacks hijack data objects in two ways: direct data manipulation (DDM) or using sequences in instructions to construct malicious code (DOP). The goals of these two attacks are basically similar, they both exploit memory vulnerabilities (e.g., buffer overflow vulnerabilities [22], use-after-free [69], double free vulnerabilities [6], etc.) to read and write memory at specified locations. Thus, attackers can manipulate security-critical data to achieve the attacks goals such as elevating privileges or bypassing authentication. However, DDM hardly realizes complex operations until the advent of DOP proves that non-controll data attacks can achieve Turing-complete attacks which allow attackers perform arbitrary computations. In this section, we focus on DOP attacks and show how to deploy DOP. Overall, DOP firstly identifies security-critical data in the program, and then looks for instructions (gadgets) that can manipulate these data. Finally, DOP identifies a dispatcher that can stitch these gadgets to launch the attacker’s malicious behavior. Specifically, DOP’s three steps and requirements are shown in Fig. 1:

Step 1: Usually, DOP’s malicious goal is to hijack security-critical data of an application (e.g., private key, password, uid, etc.). Thus, attackers need to know the memory region of the security-critical data (), and identify them so that they precisely obtain these data’s values ().

Step 2: Secondly, DOP leverages several gadgets (short sequences of instructions in the program’s control-abiding execution that can perform specific operations) to manipulate target data. The target data contain security-critical data and some other specific data in order to hijack security-critical data. In this step, attackers usually need to analyze the source code or IR code of the program to find how to manipulate target data.

Step 3: Finally, DOP needs a dispatcher, i.e., a piece of code that can stitch together these operations to realize the attacker’s arbitrary behavior. Typically, the dispatcher includes a memory error () that allows attackers construct different inputs to activate the dispatcher to execute different gadgets. So that, the memory error allows attackers perform legitimate writes ().

2.2. Existing defenses

Data objects, especially non-controll data objects, are the attack vectors of DOP attacks. Therefore, some defense methods are proposed to break requirements (-).

Break requirement 1: Data structure layout randomization (DSLR) [8,41] can hide location information of target data from attackers, make it difficult for the attacker to locate the target data in memory. Static DSLR [41] modifies the AST representation of GCC, and disrupts the layout of struct-type data. Moreover, runtime DSLR [8] can also randomize data objects which are initialized during the runtime. It converts the AST of the code to GIMPLE representation (a three-address representation of instruction), parses statements in the GIMPLE representation, and inserts data structure self-randomizing (DSSR) statements in statements involving the data structure field. Then, DSSR statements can be used for randomizing process during runtime.

Break requirement 2: Hiding the value of data object in memory through data encryption [3,7,57] provides a barrier for attacker to identify the data in memory. These methods can be divided into static data object encryption (including source-level [3] and IR-level [7]) and runtime data object encryption [57]. Researches [3,7] generate point-to graph (a directed graph representing the point-to relationship of the code), compute the equivalence classes based on point-to-graph and assign different masks to different equivalence classes. Besides, except for data objects randomization, runtime data object encryption [57] continuously re-randomizes the mask at runtime on set intervals.

Break requirement 3: To prevent attackers from exploiting vulnerabilities to change the program’s pointer-type data, PAC [40] ensures the validity of pointers, i.e., the value of a pointer is not arbitrarily manipulated by an attacker. And it uses cryptographic message authentication codes (MACs) to protect the integrity of pointers. PBCs [45] check the address range of each pointer to see if it is within the specified range during the runtime of a program. They use hash table to store each pointer and its referent’s address [30,47,62], or directly encode an pointer’s size information and base address in the pointer being checked [1,18,19]. So that they can verify whether pointer accesses are valid. Thus, both PACs and PBCs prevent attackers from exploiting memory error to change the value of pointer.

Break requirement 4: DFI [20,43] ensures that variables can only be written by legitimate writes before each read instruction, i.e., the definitions of instruction that write the value should be in the set of reaching definitions for the read [10]. To deploy it, DFI needs to generate a data-flow graph (DFG), which is the define-use relationship of each variables. And DFI instruments ensure that data changes for each variable are within the scope of this DFG.

Theoretically, fine-grained and complete data protection can resist most DOP attacks [25]. However, such protection strategies usually incur extremely high performance overheads, making them impossible to be widely adopted in production environments (we discuss this issue in Section 7). Therefore, this paper tries to find another data protection strategy, i.e., to protect DOP-specific data objects only.

3. Problem statement

In this paper, we aim to answer the following questions:

Q1: Which type of data is the target of DOP attacks in real-world programs, what are these data’s semantics, and how to identify them?

Q2: What is the percentage of target data manipulated by gadgets or dispatcher in the real-world programs?

Q3: What is the security effectiveness by only protecting the target data of gadgets or dispatcher? And what is the performance benefit compared with existing works that provide full data protection?

Q4: Is there any automated or semi-automated method to find dispatchers in real-world program?

4. Data object analysis

In this section, we analyze two types of data in the program: security-critical data and DOP’s target data. Here, we investigate the difference between security-critical data and target data:

Security-critical data: These data are closely related to the security of the program. Besides, these data are more easier to identify compared with the target data. Therefore, DOP tends to look for instructions around these data when selecting gadgets.

Target data: Attackers can direct or indirect manipulate these data, such as the variables involved in gadgets. The goal of manipulating these data is to manipulate security-critical data. Generally speaking, security-critical data is also part of the target data.

For example, as shown in Fig. 2, this is a code snippet’s call graph of ProFTPD [56]. The value cmd, which is an argument to function pr_cmd_dispatch, contains the information of users’ command, such as user configuration data. And if attackers hijack value cmd, they may achieve privilege elevation to execute malicious acts. However, In order to manipulate cmd, they need to leverage the function make_ftp_cmd and modify the parameter buf. In this case, the security-critical data is variable cmd, and the target data is variable cmd and buf. Therefore, we need to understand which security-critical data are attackers typically select as their goals, so we firstly list several types of security-critical data that are the focus of DOP attacks (Section 4.1), and we secondly analyze how the DOP operates on the target data to achieve modification of security-critical data (Section 4.2).

4.1. Security-critical data

How to choose the exploitable security-critical data is often determined by the attackers’ goals and semantics of the data. For example, DOP attacks may aim to leak confidential memory data, which poses a significant security threat to production systems [26]. These data include sensitive information like private keys and passwords. Privilege escalation is another objective for DOP attackers, where they gain unauthorized access to protected resources. This may involve modifying or corrupting data that indicates the user’s access level or permission (e.g., uid, group id), or authorization data (e.g., authorization flags), or data with high security levels (e.g., root directory). Additionally, attackers can construct malicious payloads by tampering with URLs to achieve privilege elevation, as demonstrated in the user input data attack against GHTTPD [9]. Furthermore, attacks can manipulate a program’s file descriptor, a non-negative integer value that points to a records table maintained by the kernel for each process, to exploit open files to perform unauthorized read or write operations on them.

As an example, in Table 1, we list several security-critical variables in ProFTPD [56] that fall under the aforementioned types.

Table 1
Examples of some security-critical data in ProFTPD’s source code

Security-critical data File name Variable name Data type Features

private keys display.c key pointer pointer of char

passwords auth.c res pointer pointer of struct

uid/group id auth.c res->pw_uid uint32

fsio.c PR_ROOT_UID uint32

auth.c pw_gid uint32

user’s command main.c cmd pointer pointer of struct

username auth.c pw_name pointer pointer of char

authorization flag auth.c auth_flags int

root directory fsio.c pw_dir pointer pointer of char

url mod_xfer.c session.xfer.path pointer pointer of char

file descriptors fsio.c fh->fh_fd int

Security-critical data	File name	Variable name	Data type	Features
private keys	display.c	key	pointer	pointer of char
passwords	auth.c	res	pointer	pointer of struct
uid/group id	auth.c	res->pw_uid	uint32
fsio.c	PR_ROOT_UID	uint32
auth.c	pw_gid	uint32
user’s command	main.c	cmd	pointer	pointer of struct
username	auth.c	pw_name	pointer	pointer of char
authorization flag	auth.c	auth_flags	int
root directory	fsio.c	pw_dir	pointer	pointer of char
url	mod_xfer.c	session.xfer.path	pointer	pointer of char
file descriptors	fsio.c	fh->fh_fd	int

4.2. Target data operation

Different from DDM which hardly realize complex operations, DOP proves that non-control data attacks can achieve Turing-complete attacks which allow the attacker to perform arbitrary computations. More specifically, in a DOP attack, gadgets with specific operations can simulate a Turing machine, including arithmetic/logical, assignment, load/store, jump operation. Then, a dispatcher combines these gadgets to implement complex behaviour. In this section, we analyze DOP operations on target data according to two granularities: gadgets-level operation and dispatcher-level operation.

4.2.1. Gadgets-level operation

We summarize the operations involved in several types of gadgets. As an example, we enumerate the different semantic gadgets of ProFTPD [56] (which is found by Hu et al. [25]), and analyze the operations involved in these gadgets and the corresponding data objects respectively. To illustrate this more clearly, we show in the Fig. 2 that the call graph of the functions in which each gadgets is located.

Fig. 2.

The call graph of functions where gadgets are located in ProFTPD.

Code 1.

Arithmetic gadget in ProFTPD

Arithmetic/Logical Gadgets. This type of gadgets involves arithmetic operations (e.g., addition, subtraction, multiplication and division) and logical operations. The arithmetic operations modify the values of variables in a program. In Code 1, we show an addition gadget in ProFTPD. The security-critical data in Code 1 is struct session, which is a global variable (Line 3). And once attackers can control this global variable, they can modify all the data in the program that uses this variable. Besides, the accumulation of some loop-control variable can control the start or stop of loops (e.g., while, for, etc.) in a program, which is often used by DOP to control the loops, such as variable current in Code 5, Line 12. Logical operations are often used as judgment conditions for conditional statements (e.g., if, switch, etc), such as variable s->stat is a judgment condition in Code 7, Line 5.

Code 2.

Assigment gadget in ProFTPD

Assignment Gadgets. These gadgets assign the value of one variable to another variable. Some of these gadgets involve library functions, such as function sstrncpy in Line 10 of Code 2, which assigns the data value pointed to by *rptr to cp. And security-critical variable cp (which is assigned the value buf) points to the data returned to the client by the server (Line 6, Code 2). Thus, modifying the contents of cp can modify the data returned by the server. In LLVM IR code, some assignment gadgets are recognized by its library functions, which are expressed as global variables like @sstrncpy. And other assignment operations are represented as load/store operations.

Code 3.

Load gadget in ProFTPD

Load Gadgets. The load gadgets read a value from the specified memory. The form of this operation is *p=**q, where p, q are two memory addresses respectively. For example, Code 3 relizes load operation: *resp_buf=**resp_buf. It first uses function sreplace (Line 3) as the first deference, which moves data from the resp_buf to &ServerName. And then function pr_response_send_raw (Line 5) reads the content of ServerName to the buffer resp_buf, which is the second dereference. Thus, this gadget allows attackers control the security-critical variable resp_buf, which has the message that server replied to the user, by *resp_buf=**resp_buf.

Code 4.

Store gadget in ProFTPD

Store Gadgets. The store gadgets write the specified content to memory. As show in Code 4, cmd->sever = main_sever modifies the security-critical data struct cmd, which is a user’s command data. The variable cmd->sever contains server-related configuration information, such as the server’s label/name, address, port number, TCP settings, etc. If attackers can control and modify this data, they can cause unintended behavior.

Jump Gadgets. In LLVM IR code, jump gadgets are represented as call, jmp and ret. These gadgets usually have an non-control data to control the jump conditions of the program. For example, Line 10–Line 14 in Code 5 is a while loop, and the attacker can control this loop via the variable *pbuf ->current.

Code 5.

Jump gadget and dispatcher in ProFTPD

Besides, Hu et al. propose a DOP tool [17] to find potential gadgets. In particular, the DOP tool firstly identifies store instructions and extracts the operands of those instructions. It then employs a backward data-flow analysis to identify the definitions of the operands used in the store instructions. The generated data-flow contains instructions that derive the operands, such as loaded from memory or calculated from registers. If a load operation is found in the data-flow analysis, it is considered a potential gadget. The gadgets we show in Code 1–Code 5 are just a part of these potential gadgets. In our experiments (seciton 6.1.1), we use this tool to find potential gadgets for 20 real-world applications including ProFTPD. We show that the data objects manipulated by these potential gadgets are a small percentage of the program, about 3% on average.

4.2.2. Dispatcher-level operation

In order to achieve arbitrary malicious behaviour, attackers need to identify a dispatcher, a code fragment which is capable of stitching gadgets together. In fact, DOP attacks [25] firstly finds all potential gadgets in the application, and then identifies a dispatcher that can stitch certain gadgets to achieve a specific behavior. Therefore, not all potential gadgets can be utilized by dispatchers, only the gadgets involved in dispatchers can be exploited by DOP attacks. As shown in the Fig. 3, the dispatcher is a sequence of code containing a loop and a selector. The loop can execute the same code segment n times (round-1, round-2,…, round-n). The selector executes different gadgets in each round, depending on the attacker’s input. Unlike attacks such as Return-Oriented Programming (ROP) [60], DOP does not execute gadgets sequentially, but rather executes different gadgets in different rounds.

Fig. 3.

The dispatcher is a sequence of code containing a loop and a selector.

Therefore, to determine whether a code segment is a dispatcher, the following conditions need to be satisfied:

Condition 1: dispatcher contains a loop, with non-control data which attackers can manipulate to control the loop conditions.

Condition 2: dispatcher contains a selector that jumps to available gadgets, with non-control data which attackers can manipulate to select different gadgets.

Condition 3: the loop/selector is supposed to reach the target data or security-critical data which can be manipulated by the attackers.

Condition 4: there is a vulnerability in the dispatcher that can be exploited by attackers to perform legitimate writes. In this paper, we only consider known vulnerabilities in the program, such as Common Vulnerabilities and Exposures (CVEs) [13].

For example, Code 5 shows an example of a dispatcher in ProFTPD with a while loop (Line 10-Line 14) and a selector (Line 6). As shown in Fig. 2, function cmd_loop calls the functions pr_netio_telnet_gets (loop), make_ftp_cmd and pr_cmd_dispatch (selector). The variable buf is the output of pr_netio_telnet_gets and make_ftp_cmd, and the variable cmd is the output of make_ftp_cmd and the parameter of pr_cmd_dispatch. The attacker modifies the variable cmd by controlling the variable buf (Line 11-Line 13 in Code 5), thus motivating the function pr_cmd_dispatch to choose different branches for execution.

Semi-automated tool for dispatcher searching However, through our practical experience, Hu et al.’s DOP tool [17] is unable to identify the dispatcher. In Hu et al.’s research [25], how to get a dispatcher is tricky and is almost based on researchers’ intuition. In this paper, we propose a semi-automated tool to determine whether a fragment of logic is dispatcher by following the steps below.

Step 1 (By automated tool): First, we use wllvm [70] to compile the source code of the application and obtain its LLVM IR code. Next, we generate potential gadgets and create a list of functions where these potential gadgets are located by using Hu et al.’s DOP tool [17]. By utilizing SVF [66], a static value-flow analysis tool for LLVM-based languages, we obtain the complete call graph of the application. Through a Depth-First Search (DFS) on the obtained call graph, we traverse the call chains of the functions where potential gadgets are located. If a call chain of a certain function includes all the functions where potential gadgets are located, we consider that function as a possible dispatcher. For example, as shown in columns 1–3 of Table 2, we automatically obtain the functions in ProFTPD where all potential gadgets are located and their call relationships, so that we can get the possible dispatchers. It is worth noting that we may still unable to get a complete call chain because some functions in the source code are optimized by the compiler to become inline functions (e.g., function cmd_loop in Code 5), resulting in the inline function not being found when the function call chain is analyzed for the IR code.

Step 2 (Manually): We complete the call chain of the functions by analyzing the source code and determine whether the possible dispatchers satisfy condition 1–condition 4. For example, as shown in columns 4–8 of Table 2, We manually validate whether the possible dispatchers satisfy condition 1 to condition 4.

As shown in Table 2, by executing step 1 and 2, we find dispatcher (function cmd_loop) in the file main.c. Also, there are no function in the other files satisfy condition 1–condition 4. In fact, our experiments (Section 6.1.2) calculate the percentage of target data in dispatcher is very small, which is 0.77% on average for three applications (including Openssl [49], libpcap [38], libpng [39]).

Table 2

The process of finding dispatcher in ProFTPD by our semi-automated tool

Source files	The function where the potential gadgets are located	Possible dispatchers	Condition 1	Condition 2	Condition 3	Condition 4	Is dispatcher
netio.c	pr_netio_gets	N/A	N/A
	pr_netio_poll
	pr_netio_telnet_gets
fsio.c	pr_fsio_gets	pr_fsio_getline	no	no	no	no	no
fsio.c	pr_fsio_getline	pr_fsio_getline	no	no	no	no	no
event.c	pr_event_unregister	pr_event_unregister	✓	no	no	no	no
table.c	pr_table_kadd	N/A	N/A
	pr_table_empty
	pr_table_next
timers.c	handle_alarm	pr_timer_reset	✓	no	✓	no	no
		pr_alarms_unblock	no	no	✓	no	no
		pr_timer_remove	✓	no	✓	no	no
		pr_timer_add	no	no	✓	no	no
		pr_timer_sleep	no	no	✓	no	no
main.c	pr_signals_handle	main(cmd_loop)	✓	✓	✓	✓	✓
	pr_cmd_dispatch
	_dispatch
	main
	fork_server
ftpdctl.c	sstrncpy	N/A	N/A
	main
	sstrcat
data.c	pr_data_sendfile	N/A	N/A
data.c	pr_data_xfer	N/A	N/A
pool.c	new_block	N/A	N/A
pool.c	pstrdup	N/A	N/A
modules.c	pr_module_load	modules_init	✓	no	✓	no	no
modules.c	pr_stash_add_symbol	modules_init	✓	no	✓	no	no
dirtree.c	_reorder_dirs	N/A	N/A
	fixup_servers
	_check_limit
parser.c	pr_parser_read_line	pr_parser_parse_line	✓	no	✓	no	no
parser.c	pr_parser_read_line	pr_parser_parse_file	✓	no	✓	no	no
support.c	safe_token	N/A	N/A
	get_token
	run_schedule
bindings.c	init_bindings	pr_ipbind_add_binds	✓	✓	✓	no	no
bindings.c	pr_namebind_create	init_bindings	no	✓	✓	no	no

5. DSLR–: A low-overhead DSLR method

5.1. Assumption settings

Before we introduce DSLR–, we assume that the system is protected with two widely used defenses: ASLR and CFI, by default.

ASLR We consider ASLR mechanism [51] in Linux system, where ASLR is enabled by command randomize_va_space. Command randomize_va_space = 1 randomizes the positions of the stack, virtual dynamic shared object (VDSO) page, and shared memory regions. Command randomize_va_space = 2 adds data segments randomization. As shown in Table 3, when ASLR is enabled, we start ProFTPD and record the addresses of some security-critical variables in file auth.c, labeled as address1. Then we restart ProFTPD and also record the addresses of these variables, labeled as address2. We can observe that the addresses of the variables have changed after two consecutive startups. However, ASLR does not randomize the relative distances between two data objects. For example, in Table 3, the relative distance between res->pw_uid and res is always kept 0x7f9d89a3f3d00 − 0x7f9d89a3f3c0 = 0x7f8314c333d0 − 0x7f8314c333c0 = 0x10. If the address of one data object is leaked, an attacker can locate other exploitable data objects by inferring the relative distance between the two data objects. For example, in Code 6, if the attackers can control esi and eax, they can use the distance between esi and ebx to get the value of ebx.

CFI Another defense, CFI [24,32] is proposed to eliminate control-flow hijacking attacks, such as code injection attacks [16] and code resuse attacks [4,60]. The core idea is to restrict a program’s control-flow transfers to always stay within the limits of the control-flow graph (CFG). Now, CFI protection is implemented on the Clang/LLVM compiler framework, and is enabled by default [11]. Specifically, CFI checks the operands of call, jmp and ret operations, which is defined as the control-data. However, DOP manipulates the non-control data of the program, and none of the gadgets or dispatchers modify any control data or violate CFI in the real program execution [25].

Code 6.

A code snippet demonstrates that attackers use the relative distance between data objects to get the address of the target data

Table 3

The memory addresses of some security-critical data in file auth.c when ASLR is enabled

Security-critical data	File name	Variable name	Randomize by ASLR?	Address 1	Address 2
passwords	auth.c	res	✓	0x7f9d89a3f3c0	0x7f8314c333c0
uid/group id	auth.c	res->pw_uid	✓	0x7f9d89a3f3d0	0x7f8314c333d0
uid/group id	auth.c	res->pw_gid	✓	0x7f9d89a3f3d4	0x7f8314c333d4
username	auth.c	res->pw_name	✓	0x7f9d89a3f3c0	0x7f8314c333c0
authorization flag	auth.c	auth_flags	✓	0x55817773cee0	0x556f372cfee0

5.2. Design of DSLR–

As described in Section 2.2, DSLR can hide the location information of target data from attackers, i.e., the randomized structures make it difficult for attackers to reverse-engineer the exact layout of the data in memory. Hu et al. [25] also mentioned in their research that data-plane randomization can prevent DOP attacks. However, the DSLR strategy proposed by Lin et al. [41] randomizes almost all structures except for structures that are initialized during runtime. This strategy of blindly randomizing a wide range of data is not an optimal strategy in the context of DOP attacks. Therefore, this paper proposes DSLR–, which focuses on randomizing only the target data in DOP attacks.

In practice, we can provide two options for randomizing the scope of target data: randomizing the target data within potential gadgets and randomizing the target data within dispatchers. Although it is evident that the number of target data within dispatchers is smaller than the number of target data within potential gadgets, and randomizing the target data within dispatchers can effectively mitigate Turing-complete malicious behavior by DOP attackers. However, attackers still have the possibility to manipulate target data that is not within dispatchers but within potential gadgets, leading to DDM attacks. Therefore, for more comprehensive protection, we choose to randomize the target data within potential gadgets.

To achieve DSLR–, we modify the randomization tool developed by Lin et al. [41]. Lin et al.’s work operates on GCC’s Abstract Syntax Tree (AST) representation, which provides a tree-based representation of the code structure [72]. Their approach supports inserting garbage fields and reordering variables within the AST. We retain these methods from [41] and also perform data randomization at the AST representation level. Randomizing at the AST level offers several advantages: 1) The AST contains rich source code information, enabling comprehensive analysis and modification. 2) The AST is easy to understand and manipulate, facilitating the randomization process. 3) Since GCC does not allocate memory space to data objects when generating the AST, the modifications made during randomization do not need to involve specific memory addresses. Furthermore, we use the keyword _obfuscate_ in the source code to tell GCC which struct is to be randomized. And we use the keyword _garbage_ and _reorder_ to define how to randomize the struct, which are inserting garbage fields into the struct and reordering the fields in the struct, respectively. These two randomization methods are able to disrupt struct’s variables and change the absolute addresses and relative distances of these variables. Thus, our randomization can effectively make it difficult for attackers to manipulate the target data, which is verified in Section 6.2.2.

However, our approach differs from Lin et al. [41] in terms of the scope of data randomization. While Lin et al. randomize a wide range of data structures, excluding those that are initialized during runtime, we specifically focus on struct-type data manipulated by potential gadgets. By narrowing the scope, we effectively reduce the performance overhead and memory overhead of the randomization task. We show it in Section 6.2.3.

6. Evaluation

In this section, to prove our point, we calculate the percentage of target data in potential gadgets and dispatcher. Besides, we also evaluate DSLR– from the following aspects: percentage of randomized variables, security effectiveness, performance overhead, and binary size & memory overhead.

Experiments environment. We conduct our experiments on a machine powered by an Intel(R) Xeon(R) Gold 5118 CPU @ 2.30 GHz with 16 cores. The experiments are performed using the Ubuntu 20.04.5 LTS operating system.

6.1. Percentage of target data calculation

6.1.1. Target data in potential gadgets

We automate the process of obtaining potential gadgets using the Hu et al.’s DOP tool [17] on the IR codes of 20 applications. These applications consist of two categories: 1) 4 applications analyzed in the Hu et al.’s research [25] (nginx, ProFTPD, sudo and WU-FTPD), and 2) 16 applications which we compile successfully in FuzzBenchmark [21], as shown in Table 5. We compile these programs by using wllvm [70] so that we can get the LLVM IR code of a whole program.

Moreover, we calculate the percentage of target data operated by potential gadgets. This percentage is calculated by dividing the number of target data by the number of all type variables in the program, including global variables, local variables and heap variables. Specifically, we automate the process of static analysis to count the number of these three types of variables from LLVM IR code. Since heap variables are dynamically allocated, it is not possible to determine the exact number of heap variables at runtime through static analysis. Instead, we can only estimate the runtime quantity by statically counting the occurrences of allocation functions such as malloc. Here, we only consider variables and exclude constants because constants cannot be modified, making them particularly irrelevant for DOP attacks. Thus, the number of all type variables in the program is calculated by Equation (1), and the percentage of target data in potential gadgets is calculated by Equation (2). $\begin{aligned} (1) & {Num}_{all type variables} = {Num}_{g l o b a l variables} + {Num}_{local variables} + {Num}_{heap variables} \\ (2) & P_{target data in potential gadgets} = \frac{{Num}_{target data in potential gadgets}}{{Num}_{all type variables}} \end{aligned}$

We take ProFTPD [56] as an example and show it’s gadgets and target data found by DOP tool in Table 4. For example, IR code file main.c has gadgets in the functions pr_signals_handle, pr_cmd_dispatch, _dispatch, main and fork_server. Some of these gadgets operate directly on the security-critical data in Table 1, including struct cmd (user’s command data), session (url data), etc. Besides, some security-critical files, such as authorization file auth.c, do not have gadgets. It is worth noting that the security-critical variables defined in such security-critical files (like auth.c) may be referenced in other files and used as target data, which is not considered by us yet. Overall, Table 5 illustrates the percentage of target data in potential gadgets for 20 applications. It is noteworthy that the percentage of target data in potential gadgets for these applications is generally low, with a maximum of 6.89% and an average of 3.28%.

Table 4
Some examples of gadgets found by DOP tool [17] in ProFTPD

File name Function Gadgets example Target data type Is security-critical data?

main.c pr_signals_handle store volatile i32 %and21, i32* @recvd_signal_flags, align 4, !tbaa !1 pointer of int no

pr_cmd_dispatch store %struct.server_struc* %0, %struct.server_struc** %server, align 8, !tbaa !5 pointeof struct cmd->server

store i8* %10, i8** getelementptr inbounds (%struct.session_t* @session, i64 0, i32 34), align 8, !tbaa !9 pointer of char session.xfer.path

_dispatch store i32 %or, i32* %class95, align 4, !tbaa !35 pointer cmd->class

store i8* %add.ptr51.i, i8** @LastArgv, align 8, !tbaa !1 pointer cmd->argv

main store i32 %inc, i32* @nodaemon, align 4, !tbaa !5 pointer no

fork_server store i8* getelementptr inbounds ([13 x i8]* @.str77, i64 0, i64 0), i8** getelementfptr inbounds (%struct.session_t* @session, i64 0, i32 26), align 8, !tbaa !26 pointer, struct no

fsio.c pr_fsio_gets store i8* %incdec.ptr78, i8** %current17, align 8, !tbaa !9 struct fh->fh_fd fh->fh_buf

auth.c No gadgets

File name	Function	Gadgets example	Target data type	Is security-critical data?
main.c	pr_signals_handle	store volatile i32 %and21, i32* @recvd_signal_flags, align 4, !tbaa !1	pointer of int	no
pr_cmd_dispatch	store %struct.server_struc* %0, %struct.server_struc** %server, align 8, !tbaa !5	pointeof struct	cmd->server
	store i8* %10, i8** getelementptr inbounds (%struct.session_t* @session, i64 0, i32 34), align 8, !tbaa !9	pointer of char	session.xfer.path
_dispatch	store i32 %or, i32* %class95, align 4, !tbaa !35	pointer	cmd->class
	store i8* %add.ptr51.i, i8** @LastArgv, align 8, !tbaa !1	pointer	cmd->argv
main	store i32 %inc, i32* @nodaemon, align 4, !tbaa !5	pointer	no
fork_server	store i8* getelementptr inbounds ([13 x i8]* @.str77, i64 0, i64 0), i8** getelementfptr inbounds (%struct.session_t* @session, i64 0, i32 26), align 8, !tbaa !26	pointer, struct	no
fsio.c	pr_fsio_gets	store i8* %incdec.ptr78, i8** %current17, align 8, !tbaa !9	struct	fh->fh_fd fh->fh_buf
auth.c	No gadgets

Table 5

The percentage of target data manipulated by potential gadgets in 20 applications

Application		Num (target data in potential gadgets)	Num (all type variables)	$P_{target data in potential gadgets}$

name	version
nginx [48]	1.20.0	No gadget
Openssl [49]	1.0.1	720	32462	2.22%
ProFTPD [56]	1.3.0	263	18777	1.40%
Openssh [50]	8.8	986	91965	1.07%
sudo [65]	1.9.12	130	14200	0.92%
WU-FTPD [71]	2.6.2	231	14868	1.55%
php [54]	7.0.8	602	16385	3.67%
libarchive [35]	3.3.2	36	3499	1.03%
zlib [73]	1.2.13	1004	14545	6.89%
zstd [74]	1.5.2	4368	88330	4.9%
libgit2 [36]	1.5.1	No gadget
libpcap [38]	1.0	738	28773	2.56%
matio [44]	1.5.23	1939	78598	2.47%
aspell [2]	0.60.8	No gadget
libhevc [37]	android12	No gadget
libpng [39]	1.6.37	1444	26649	5.42%
vorbis [68]	1.3.7	1140	26617	5.42%
jsoncpp [31]	1.9.5	56	85680	0.07%
sqlite [63]	3.40.1	20435	317247	6.44%
curl [12]	7.21.6	No gadget
Average				3.28%

6.1.2. Target data in dispatcher

We use our semi-automated tool (described in Section 4.2.2) to analyze dispatchers for 16 FuzzBenchmark applications. To our knowledge, there have been no studies attempting to find the dispatchers for these 16 FuzzBenchmark applications. Therefore, the locations of dispatchers for these applications are not known beforehand. We obtain exploitable dispatchers in OpenSSL, libpcap and libpng, which are introduced as follow.

Openssl. OpenSSL [49] is an open source toolkit for the Transport Layer Security (TLS) protocol. In code file s3_srvr.c, function SSL_accept listens protocol state and acts corresponding behavior. As shown in Code 7, Function ssl3_accept is dispatcher and includes loop (line 3) and selector (line 5). And function ssl3_accept (dispatcher) calls several functions containing gadgets, including: ssl3_get_client_hello, ssl3_get_cert_verify, etc. These functions represent different ways of handling user responses. However, function ssl3_get_cert_verify, which is used for verifying the client certificate, contains vulnerability CVE-2015-0205 [15] that allows remote attackers to obtain access without knowledge of a private key. Therefore, if attackers can control the selector and the variable s->state, they can exploit the vulnerability in ssl3_get_cert_verify for privilege elevation.

Code 7.

Dispatcher in openssl

Libpcap. libpcap [38] is a portable C/C $+ +$ library for network traffic capture. Function opt_loop in optimize.c is an optimization module, and is used for compiling the filter expressions of network packets. As shown in Code 8, opt_loop (dispatcher, Line 2) calls four functions where gadgets are located, including the opt_blk, fold_op, opt_j and deadstmt. Function opt_blk (selector, Line 9) can perform different optimization strategies based on the variable opt_state. And variable opt_state contains information about network packet filter expressions, such as the number of all network basic blocks, branch information of network basic blocks, etc. Thus, if attackers can hijack the variable opt_state, they can control the way libpcap optimizes network packets.

Code 8.

Dispatcher in libpcap

Libpng. libpng [39] is an official PNG reference library. In file pngpread.c, as shown in Code 9, function png_process_data processes the input image information. png_process_data (dispatcher, Line 2) calls three functions where gadgets are located, including png_push_read_sig, png_push_read_chunk and png_push_read_IDAT. And function png_process_some_data (selector, Line 8) chooses how the file is processed based on the variable png_ptr -> process_mode. However, function png_push_read_chunk has a vulnerability CVE-2014-0333 [14], which allows a remote attacker cause a denial of service (DOS) attack via an IDAT block of zero length. Thus, if attackers control the variable png_ptr -> process_mode, they can deliberately call the function png_push_read_chunk to perform a DOS attack.

Code 9.

Dispatcher in libpng

Furthermore, we calculate the percentage of target data in these three applications’ dispatchers with the Equation (3). As shown in Table 6, we can see that the percentage of target data in dispatcher is very small, which is 0.77% on average. $\begin{matrix} (3) & P_{target data in dispatcher} = \frac{{Num}_{target data in dispatcher}}{{Num}_{all type variables}} \end{matrix}$

Table 6

The percentage of target data in dispatchers for Openssl, libpcap, libpng

Application		Num (target data in dispatcher)	Num (all type variables)	$P_{target data in dispatcher}$

Name	Version
Openssl	1.0.1	64	32462	0.20%
libpcap	1.0	519	28773	1.8%
libpng	1.6.37	86	26649	0.3%
Average				0.77%

6.2. Evaluation of DSLR–

As described in Section 6.1.2, we obtain exploitable dispatchers in OpenSSL, libpcap, and libpng using our semi-automated tool. Additionally, Hu et al. [25] identify exploitable dispatchers in ProFTPD. We consider that the presence of these exploitable dispatchers in the four applications makes them highly susceptible to DOP attacks. Therefore, we apply DSLR– to protect the target data of potential gadgets in these four applications. In addition, for the purpose of comparison, we also use the randomization tool developed by Lin et al. [41] to protect these applications. In this section, we evaluate the percentage of randomized variables, security effect, performance overhead and binary size & memory overhead of DSLR–, as well as compare these aspects with tool [41].

6.2.1. Percentage of randomized variables

We calculate the percentage of randomized variables in Equation (4). As shown in Equation (4), $P_{randomized variables}$ is calculated by dividing the number of randomized variables by the all-type variables in the program. We also employ the tool developed by Lin et al. [41] to randomize the majority of the structures in these four applications, except for structures that are initialized during runtime, and the proportion of randomized structs is also calculated using Equation (4). $\begin{matrix} (4) & P_{randomized variables} = \frac{{Num}_{randomized variables}}{{Num}_{all type variables}} \end{matrix}$

Fig. 4.

Percentage of randomized variables for ProFTPD, Openssl, libpcap, libpng when using DSLR– and tool [41].

As shown in Fig. 4, we conduct a statistical analysis on the percentage of randomized variables in the four applications when using DSLR– and the tool developed by Lin et al. [41]. The results clearly demonstrate that DSLR– achieves a remarkable reduction in the number of randomized variables. Specifically, DSLR– successfully reduces the required randomized variables by an impressive 85.8% compare to [41].

6.2.2. Security effectiveness analysis

In this section, we analyze DSLR–’s security effect from: 1) randomization of relative distances between variables, and 2) the effectiveness against DOP attacks (including privilege elevation and DOS attack).

Randomization of Relative Distances between Variables. DSLR– recognizes that keyword _garbage_ and _reorder_, and disturbs the variables in a struct. Thus, DSLR– can change the absolute and relative distance between the variables. In this way, attackers are not able to use the relative distances between data objects to obtain the address of the target data. Hence, our randomization tool compensates for the limitations of ASLR, as we described in Section 5.1. Take the ProFTPD as an example and show it in Table 7, the relative distance of variables in struct res are randomized with our tool.

Effectiveness of Resistance to Privilege Elevation and DOS Attack. As we describe in Section 6.1.2, Openssl and libpng’s dispatcher respectively contain vulnerabilities CVE-2015-0205 [15] and CVE-2014-0333 [14], which can be exploited by an attacker to achieve privilege elevation and DOS attack. We show in Table 8 which variables an attacker needs to control to achieve these two malicious goals. For example, the struct-type variables *s and s->state (in Openssl) contain the information about connection with clients, and struct-type variable png_ptr (in libpng) contains information about how to process image. Furthermore, these variables also control the selection of gadgets by the selector. If attackers can control these variables, they can control the dispatcher to execute gadgets with vulnerabilities. The struct-type variable *pkey (in Openssl) means the private key of client-side. If attackers control this variable, they can realize privilege elevation (CVE-2015-0205). If attackers can control the variable png_ptr->push_length (in libpng) and set it to zero, they can cause a DOS attack (CVE-2014-0333). Obviously, these variables are all struct-type variables or variables in struct. Since DSLR– randomizes all the structs in gadgets and dispatcher, including the relative distances of the variables in these structs, it can effectively prevent the DOP from manipulating these target data to deploy privilege elevation and DOS attack.

Table 7
The relative distance of variables in struct res are randomized by DSLR–

Randomization method Address of variables in struct res

res->pw_name res->pw_uid res->pw_gid

No randomization 0x7f8314c333c0 0x7f8314c333d0 0x7f8314c333d4

reorder 0x7f689fe273d0 0x7f689fe273c0 0x7f689fe273d4

garbage 0x7f6f40a443c0 0x7f6f40a443d4 0x7f6f40a443d8

reorder & garbage 0x7f9d89a3f3d4 0x7f9d89a3f3c0 0x7f9d89a3f3d8

Randomization method	Address of variables in struct res
No randomization	0x7f8314c333c0	0x7f8314c333d0	0x7f8314c333d4
reorder	0x7f689fe273d0	0x7f689fe273c0	0x7f689fe273d4
garbage	0x7f6f40a443c0	0x7f6f40a443d4	0x7f6f40a443d8
reorder & garbage	0x7f9d89a3f3d4	0x7f9d89a3f3c0	0x7f9d89a3f3d8

Table 8

The variables that attackers aim to manipulate in order to achieve privilege elevation and DOS attacks, as well as the effectiveness of DSLR– in mitigating these two types of attacks

Application	Vulnerability	Variable	Data-type	Semantic of variable	Randomize by DSLR–?
Openssl	CVE–2015–0205 (privilege elevation)	SSL * s	struct	Information about connection with clients	✓
		s ->state	variable in struct	State of connection	✓
		EVP_PKEY * pkey	struct	Private key of client-side	✓
libpng	CVE–2014–0333 (DOS attack)	png_ptr	struct	Information about how to process image	✓
libpng	CVE–2014–0333 (DOS attack)	png_ptr->push_length	variable in struct	The length of a data chunk of image	✓

6.2.3. Performance overhead

In this section, we test our randomization tool with SPECCPU 2006 benchmark [64]. Since our randomization tool makes modifications to GCC, we compile each benchmark program 3 times during our testing, denoted by O1,O2,O3. We show the evaluation results in Table 9. As can be seen, except for some benchmark programs that we can’t compile successfully (denoted by N/A), the performance overhead caused by our randomization tool is small, roughly 2.3% on average.

Table 9
Evaluation of the performance overhead of DSLR–

Application Performance overhead imposed by DSLR–

O1 O2 O3 $O_{average}$

400.perlbench 2.9% 3.9% 1.8% 2.9%

401.bzip2 3.7% 1.9% 2.1% 2.6%

403.gcc 3.3% 2.7% 1.4% 2.5%

429.mcf 1.3% 1.0% 2.9% 1.7%

445.gobmk 3.7% 2.9% 1.1% 2.6 %

456.hmmer 1.3% 2.6% 2.4% 2.1%

458.sjeng 3.4% 1.3% 2.1% 2.3%

462.libquantum 2.6% 2.6% 1.9% 2.4%

464.h264ref 1.7% 2.0% 3.0% 2.2%

471.omnetpp 2.7% 1.5% 2.7% 2.3%

473 astar 1.7% 3.2% 1.2% 2.0%

483.xalancbmk N/A

410.bwaves N/A

416.gamess N/A

433.milc 1.0% 2.1% 1.5% 1.5%

434.zeusmp N/A

435.gromacs N/A

436.cactusADM N/A

437.leslie3d N/A

444.namd 2.4% 2.8% 1.5% 2.2%

447.dealII N/A

450.soplex 2.9% 1.7% 2.4% 2.3%

453.povray 3.0% 2.5% 1.7% 2.4%

454.calculix N/A

459.GemsFDTD N/A

465.tonto N/A

470.lbm 3.5% 2.5% 1.4% 2.5%

481.wrf N/A

482.sphinx3 2.8% 3.4% 1.1% 2.4%

Average 2.3%

Application	Performance overhead imposed by DSLR–
400.perlbench	2.9%	3.9%	1.8%	2.9%
401.bzip2	3.7%	1.9%	2.1%	2.6%
403.gcc	3.3%	2.7%	1.4%	2.5%
429.mcf	1.3%	1.0%	2.9%	1.7%
445.gobmk	3.7%	2.9%	1.1%	2.6 %
456.hmmer	1.3%	2.6%	2.4%	2.1%
458.sjeng	3.4%	1.3%	2.1%	2.3%
462.libquantum	2.6%	2.6%	1.9%	2.4%
464.h264ref	1.7%	2.0%	3.0%	2.2%
471.omnetpp	2.7%	1.5%	2.7%	2.3%
473 astar	1.7%	3.2%	1.2%	2.0%
483.xalancbmk	N/A
410.bwaves	N/A
416.gamess	N/A
433.milc	1.0%	2.1%	1.5%	1.5%
434.zeusmp	N/A
435.gromacs	N/A
436.cactusADM	N/A
437.leslie3d	N/A
444.namd	2.4%	2.8%	1.5%	2.2%
447.dealII	N/A
450.soplex	2.9%	1.7%	2.4%	2.3%
453.povray	3.0%	2.5%	1.7%	2.4%
454.calculix	N/A
459.GemsFDTD	N/A
465.tonto	N/A
470.lbm	3.5%	2.5%	1.4%	2.5%
481.wrf	N/A
482.sphinx3	2.8%	3.4%	1.1%	2.4%
Average		2.3%

In addition, as there are variations in performance overhead across different machines, we reproduce the randomization tool developed by Lin et al. [41] in our own environment. To evaluate the trade-off between performance overhead and the proportion of randomized structures, we configure the randomization ratios of the tool [41] to be 30%, 50%, 70%, and 100%. The results of testing DSLR– and the tool [41] are presented in Fig. 5. It is evident that as the randomization ratio increases, the performance overhead of the tool [41] also increases. In comparison to the tool [41] with a randomization ratio of 100%, DSLR– achieves a remarkable 71.2% improvement in performance.

Fig. 5.

Comparison of the performance overhead of DSLR– and tool [41].

6.2.4. Binary size & memory overhead

Fig. 6.

Binary size overhead and memory overhead of DSLR– and tool [41].

Due to the randomization of variables’ space layout, we also need to measure the binary size overhead and memory overhead introduced by the randomization tool. As shown in Fig. 6a and Fig. 6b, we conduct tests on DSLR– and tool [41] to evaluate their impact on binary size overhead and memory overhead in the context of four applications. The results demonstrate that DSLR– incurs minimal binary size overhead and memory overhead, averaging at 0.77% and 0.70% respectively. In comparison to the tool [41], DSLR– reduces the binary size overhead and memory overhead by approximately 76.3% and 82.5% respectively.

7. Related work

7.1. DOP attacks

Our work builds on the study of DOP attacks proposed by Hu et al. [25]. They also introduce in an earlier research [23] about how to construct data-oriented exploits using deterministic addresses of data objects and relative distances between data objects. Their work confirm the feasibility of DOP, but it is undeniable that how to select exploitable data to form a complete DOP attack chain is very difficult. In this paper, we propose a semi-automated method for locating DOP target data, and after our statistics, the percentage of target data is small, roughly 3% on average.

7.2. Existing defenses

To the best of our knowledge, existing defenses do not focus on the protection of specific data exploited by DOP. Here, we discuss the existing defense strategies and their limitations when applying them to DOP attacking scenarios. Data object encryption [3,7,57] generates equivalence classes of data objects based on a point-to-graph. And if both data objects are accessed through the same pointer, they are considered to be the same equivalence class. However, this type of data encryption is for all pointer type data and causes a non-negligible performance overhead, e.g., runtime data object encryption has 42.12% overhead on average [57]. DSLR [8,41] randomizes all struct-type data in the program and runtime DSLR [8] has significant performance overhead in program gzip, gap and twolf (approximately 100%—120%). Besides, our statistics show that the percentage of struct-type target data for DOP is only about 2.6% for real-world applications. Therefore, randomization of all struct-type of data in existing DSLR is not suitable for the DOP attacking scenarios. Pointer intergity research [34] only gives a protection for control-data (e.g., function pointers, return addresses), which prevents control-flow hijack attacks rather than data-oriented attacks. And PAC [40] leverages cryptographic MACs to protect the pointer not arbitrarily manipulated by an attacker. However, this methods is not suitable for large-scale applications, i.e., execution time and memory consumption increase as the number of protected pointers increases. Pointer boundary checking techniques [45] check the address range of each pointer to see if it is within the specified range during the runtime of program. Theoretically, complete pointer detection prevents all possible DOP exploits. However, the performance and memory overhead of complete pointer protection is also significant, for example, SoftBound [46] produces an average performance overhead of 67% and a memory overhead of 200% in standard benchmarks. DFI [20,43] technology generates a data-flow graph (DFG), which is the define-use relationship of each variables. So that the DFI instruments ensure that each variable is only written by legitimate writes at runtime before each read instruction. Complete DFI is DOP resistant, but it also has very heavy performance overhead, which has 103% for interproc DFI.

7.3. Strategies for selectively protecting data objects

To mitigate the high performance overhead, researchers have also proposed strategies for selectively protecting data objects. In order to effectively protect data against memory disclosure attacks, CRYPTOMPK is introduced by Jin et al. [29], which utilizes crypto-aware static taint analysis to automatically track and label sensitive data. Additionally, it leverages the Memory Protection Keys (MPK) hardware feature of Intel processors to isolate these sensitive data. To counter control flow hijacking attacks, DynPTA [52] combines static analysis with dynamic data flow tracking (DFT) to selectively encrypt a subset of annotated sensitive data in memory. To the best of our knowledge, there is currently no existing selective data protection method specifically designed to defend against DOP attacks. This paper addresses the issue of high overhead in existing defenses during DOP mitigation by only randomizing the memory layout of target data exploited by DOP. Experimental results demonstrate effective resistance against DOP attacks with an average performance overhead of only 2.3% and memory overhead of 0.70%.

8. Discussion

We declare that our research in this paper is specifically focused on DOP attacks. In particular, in Section 4, we propose narrowing down the scope of the data objects that need protection, specifically the target data involved in DOP attacks. In Section 5.2, we introduce DSLR– as a tool for protecting these target data. While the target data may include security-critical data of interest in DDM attacks, we do not guarantee that the protection provided for DOP target data can necessarily withstand DDM attacks.

Furthermore, although Block Oriented Programming (BOP) [28] is also a data-oriented technique that does not violate CFI, we believe that BOP and DOP attacks differ significantly in several aspects:

Payload: In DOP attacks, the payload consists of a sequence of instructions capable of modifying specific memory values. On the other hand, BOP payloads are predefined high-level language SPloit Language (SPL) instructions, with support for 13 different payloads [28].

Implementation approach: In DOP, specific operations are achieved through gadgets, which are individual instructions. These gadgets are linked together using a loop and a selector in the dispatcher, and specific gadgets are executed in each iteration. In contrast, BOP achieves malicious behavior by executing a sequence of BOP gadgets where each BOP gadget is: a functional basic block which executes an SPL statement, and zero or more dispatcher blocks which chain two functional basic blocks. A loop or selector is not necessarily required in the BOP’s dispatcher.

Gadget identification methods: DOP involves compiling the source code into LLVM IR code and utilizing LLVM Pass programs [42], which can perform program transformations and analyses during the compilation process, to search for potential gadgets, as described in Section 6.1.1. In contrast, BOP utilizes symbolic execution [33] to perform static analysis on the source code and identify basic blocks that can achieve the functionality of SPL statements.

In our design, DSLR– is able to randomize struct-type target data of DOP attacks, as discussed in Section 5.2. However, the automated tool for implementing BOP attacks, BOPC [5], generates a set of “what-where” memory writes that indicate how the memory should be initialized (i.e., which values should be written at which memory addresses). When these memory writes pertain to structures, DSLR– may be capable of randomizing them, offering probabilistic defense against BOP attacks. Nevertheless, for non-structure types such as arrays and integers, DSLR– is unable to provide defense.

9. Conclusion and future work

In this paper, we focus on the target data manipulated by the DOP. We analyze how gadgets and dispatchers manipulate these data and the necessary conditions to construct a complete DOP attack chain. We calculate the percentage of target data in the program and show that the data objects manipulated by the DOP are a small percentage of the program. Based on these findings, we propose DSLR– to randomize the memory address of the target data. This randomization covers the absolute addresses of the data objects as well as the relative distances between them. However, our work can still be improved in the following aspects:

We use a semi-automated tool to find the dispatcher and its target data in the program, i.e., the process is still dependent on manual identification. We hope to create an automated tool to do this in the future.

Since our randomization tool is based on the DSLR tool developed by Lin et al. [41], it is not compatible with higher versions of the GCC compiler due to its age. Due to the availability of randomize structure layout support in modern versions of GCC/LLVM [58,59], we intend to incorporate compatibility with these modern versions of GCC/LLVM, and enhance the functionality of our tool in future work. Moreover, we can only randomize struct-type variables in program. We plan to randomize all-type target data in the future.

Footnotes

Acknowledgments

This work was supported by the National Key Research and Development Program for Young Scientists of China (No. 2022YFB3102800). I would like to express my sincere gratitude to Professor Peng Liu and Zhilong Wang for their invaluable guidance, unwavering support, and profound expertise throughout this research. Their mentorship and insightful feedback were instrumental in shaping this work. I also would like to extend my heartfelt appreciation to the reviewers for their constructive feedback and valuable insights. Their thorough examination and thoughtful comments greatly contributed to enhancing the quality and clarity of this paper.

References

Akritidis,

Costa,

Castro and

Hand, Baggy bounds checking: An efficient and backwards-compatible defense against out-of-bounds errors, in: USENIX Security Symposium, Vol. 10, 2009.

Aspell, http://aspell.net.

Bhatkar and

Sekar, Data space randomization, in: Detection of Intrusions and Malware, and Vulnerability Assessment: 5th International Conference, DIMVA 2008, Paris, France, July 10–11, 2008, Proceedings 5, Springer, 2008, pp. 1–22.

Bletsch,

Jiang and

Freeh, Jump-oriented programming: A new class of code-reuse attack, in: Proceedings of the 6th ACM Symposium on Information, Computer and Communications Security, 2011, pp. 30–40. doi:10.1145/1966913.1966919.

BOPC, https://github.com/HexHive/BOPC.

Caballero,

Grieco,

Marron and

Nappa, Undangle: Early detection of dangling pointers in use-after-free and double-free vulnerabilities, in: 2012 International Symposium on Software Testing and Analysis, 2012, pp. 133–143.

Cadar,

Akritidis,

Costa,

J.P.

Martin and

Castro, Data randomization, Technical Report TR-2008-120, Microsoft Research, 2008.

Chen,

Xu,

Lin,

Xu,

Mao and

Liu, A practical approach for adaptive data structure layout randomization, in: Computer Security–ESORICS 2015: 20th European Symposium on Research in Computer Security, Vienna, Austria, September 21–25, 2015, Proceedings, Part I, Vol. 20, Springer, 2015, pp. 69–89. doi:10.1007/978-3-319-24174-6_4.

Chen,

Xu,

E.C.

Sezer,

Gauriar and

K.I.

Ravishankar, Non-control-data attacks are realistic threats, in: USENIX Security Symposium, Vol. 5, 2005, p. 146.

10.

Cheng,

Ahmed,

Liljestrand,

Nyman,

Cai,

Jaeger,

Asokan and

Yao, Exploitation techniques for data-oriented attacks with existing and potential defense approaches, ACM Transactions on Privacy and Security (TOPS) 24(4) (2021), 1–36. doi:10.1145/3462699.

11.

Control-flow-integrity-cfi-clang, https://www.redhat.com/en/blog/fighting-exploits-control-flow-integrity-cfi-clang.

12.

Curl, ttps://github.com/curl/.

13.

CVE Vulnerabilities, https://cve.mitre.org/.

14.

CVE–2014–0333, https://nvd.nist.gov/vuln/detail/CVE-2014-0333.

15.

CVE–2015–0205, https://nvd.nist.gov/vuln/detail/cve-2015-0205.

16.

W.A.

Dahl,

Erdodi and

F.M.

Zennaro, Stack-based buffer overflow detection using recurrent neural networks, 2020, arXiv preprint arXiv:2012.15116.

17.

Dop Tool, https://huhong789.github.io/advanced-DOP/.

18.

G.J.

Duck and

R.H.C.

Yap, Heap bounds protection with low fat pointers, in: 25th International Conference on Compiler Construction, 2016, pp. 132–142. doi:10.1145/2892208.2892212.

19.

G.J.

Duck,

R.H.C.

Yap and

Cavallaro, Stack bounds protection with low fat pointers, in: NDSS, Vol. 17, 2017, pp. 1–15.

20.

Feng,

Huang,

Huang and

Hu, Toward taming the overhead monster for data-flow integrity, ACM Transactions on Design Automation of Electronic Systems (TODAES) 27(3) (2021), 1–24. doi:10.1145/3490176.

21.

Fuzzbenchmark, https://github.com/google/oss-fuzz/tree/master/projects.

22.

F.-J.

Gao,

Wang,

L.-Z.

Wang,

Yang and

X.-D.

Li, Automatic buffer overflow warning validation, Journal of Computer Science and Technology 35 (2020), 1406–1427. doi:10.1007/s11390-020-0525-z.

23.

Hu,

Z.L.

Chua,

Adrian,

Saxena and

Liang, Automatic generation of data-oriented exploits, in: 24th {USENIX} Security Symposium ({USENIX} Security 15), 2015, pp. 177–192.

24.

Hu,

Qian,

Yagemann,

S.P.H.

Chung,

W.R.

Harris,

Kim and

Lee, Enforcing unique code target property for control-flow integrity, in: 2018 ACM SIGSAC Conference on Computer and Communications Security, 2018, pp. 1470–1486. doi:10.1145/3243734.3243797.

25.

Hu,

Shinde,

Adrian,

Z.L.

Chua,

Saxena and

Liang, Data-oriented programming: On the expressiveness of non-control data attacks, in: 2016 IEEE Symposium on Security and Privacy (SP), IEEE, 2016, pp. 969–986. doi:10.1109/SP.2016.62.

26.

Hu,

Chen,

Zhu and

Liu, A co-design adaptive defense scheme with bounded security damages against heartbleed-like attacks, IEEE Transactions on Information Forensics and Security 16 (2021), 4691–4704. doi:10.1109/TIFS.2021.3113512.

27.

Ismail,

Yom,

Jelesnianski,

Jang and

Min, VIP: Safeguard value invariant property for thwarting critical memory corruption attacks, in: 2021 ACM SIGSAC Conference on Computer and Communications Security, 2021, pp. 1612–1626. doi:10.1145/3460120.3485376.

28.

Ispoglou,

AlBassam,

Jaeger and

Payer, Block oriented programming: Automating data-only attacks, in: 2018 ACM SIGSAC Conference on Computer and Communications Security, 2018, pp. 1868–1882. doi:10.1145/3243734.3243739.

29.

Jin,

Xiao,

Jia,

Gao,

Gu,

Zhang,

Ma and

Qian, and

Li, Annotating, tracking, and protecting cryptographic secrets with cryptompk, in: 2022 IEEE Symposium on Security and Privacy (SP), IEEE, 2022, pp. 650–665. doi:10.1109/SP46214.2022.9833650.

30.

R.W.

Jones and

P.H.

Kelly, Backwards-compatible bounds checking for arrays and pointers in C programs, in: AADEBUG, Vol. 97, 1997, pp. 13–26.

31.

Jsoncpp, https://github.com/open-source-parsers/jsoncpp.

32.

Khandaker,

Liu,

Naser,

Wang and

Yang, in: Origin-Sensitive Control Flow Integrity., in: USENIX Security Symposium, 2019, pp. 195–211.

33.

King, Symbolic execution and program testing, Communications of the ACM 19(7) (1976), 385–394. doi:10.1145/360248.360252.

34.

Kuznetzov,

Szekeres,

Payer,

Candea,

Sekar and

Song, Code-pointer integrity, in: The Continuing Arms Race: Code-Reuse Attacks and Defenses, 2018, pp. 81–116. doi:10.1145/3129743.3129748.

35.

Libarchive, http://www.libarchive.org/downloads.

36.

Libgit2, https://github.com/libgit2.

37.

Libhevc, https://gitlab.com/aosp1/platform/external/libhevc/.

38.

Libpcap, https://www.tcpdump.org/release.

39.

Libpng, http://www.libpng.org/pub/png/libpng.html.

40.

Liljestrand,

Nyman,

Wang,

C.C.

Perez,

Ekberg and

Asokan, in: PAC It up: Towards Pointer Integrity Using ARM Pointer Authentication., in: USENIX Security Symposium, 2019, pp. 177–194.

41.

Lin,

R.D.

Riley and

Xu, Polymorphing software by randomizing data structure layout, in: Detection of Intrusions and Malware, and Vulnerability Assessment: 6th International Conference, DIMVA 2009, Como, Italy, July 9–10, Proceedings, Vol. 6, Springer, 2009, pp. 107–126. doi:10.1007/978-3-642-02918-9_7.

42.

LLVM Pass, https://llvm.org/docs/WritingAnLLVMPass.html.

43.

Lu and

Wang, Data-flow bending: On the effectiveness of data-flow integrity, Computers & Security 84 (2019), 365–375. doi:10.1016/j.cose.2019.04.002.

44.

Matio, https://github.com/tbeu/matio.

45.

Nagarakatte,

M.M.K.

Martin and

Zdancewic, Everything you want to know about pointer-based checking, in: 1st Summit on Advances in Programming Languages (SNAPL 2015), Schloss Dagstuhl-Leibniz-Zentrum Fuer Informatik, 2015.

46.

Nagarakatte,

Zhao,

M.M.

Martin and

Zdancewic, SoftBound: Highly compatible and complete spatial memory safety for C, in: 30th ACM SIGPLAN Conference on Programming Language Design and Implementation, 2009, pp. 245–258. doi:10.1145/1542476.1542504.

47.

G.C.

Necula,

Condit,

Harren,

McPeak and

Weimer, CCured: Type-safe retrofitting of legacy software, ACM Transactions on Programming Languages and Systems (TOPLAS) 27(3) (2005), 477–526. doi:10.1145/1065887.1065892.

48.

Nginx, http://nginx.org/download.

49.

Openss, https://www.openssl.org/source/.

50.

Openssh, https://www.openssh.com/.

51.

P. Team, PaX address space layout randomization, 2003, http://pax.grsecurity.net/docs/aslr.txt.

52.

Palit,

Moon,

Monrose and

Polychronakis, Dynpta: Combining static and dynamic analysis for practical selective data protection, in: 2021 IEEE Symposium on Security and Privacy (SP), IEEE, 2021, pp. 1919–1937. doi:10.1109/SP40001.2021.00082.

53.

PaX, Homepage of the PaX Team, 2001, http://pax.grsecurity.net .

54.

PHP, http://cn2.php.net/get/php-7.0.8.tar.gz/from/this/mirror.

55.

Pirry,

Marco-Gisbert and

Begg, A review of memory errors exploitation in x86-64, Computers 9(2) (2020), 48. doi:10.3390/computers9020048.

56.

ProFTPD, http://www.proftpd.org/.

57.

Rajasekaran,

Crane,

Gens,

Na,

Volckaert and

Franz, CoDaRR: Continuous data space randomization against data-only attacks, in: 15th ACM Asia Conference on Computer and Communications Security, 2020, pp. 494–505. doi:10.1145/3320269.3384757.

58.

Randomize structure layout support for GCC, https://lwn.net/Articles/722293/.

59.

Randomize structure layout support for LLVM, https://reviews.llvm.org/D121556.

60.

Roemer,

Buchanan,

Shacham and

Savage, Return-oriented programming: Systems, languages, and applications, ACM Transactions on Information and System Security (TISSEC) 15(1) (2012), 1–34. doi:10.1145/2133375.2133377.

61.

M.S.

Roodsari,

Nouri,

Sheikhshoaei,

Prinetto and

Navabi, A Secure Canary-Based Hardware Approach Against ROP, 2022.

62.

Ruwase and

M.S.

Lam, A practical dynamic buffer overflow detector, in: NDSS, 2004, pp. 159–169.

63.

Sqlite, https://www.sqlite.org.

64.

Standard Performance Evaluation Corporation, SPEC, http://www.spec.org/osg/cpu2006.

65.

Sudo, https://github.com/sudo-project/sudo/releases.

66.

SVF, https://github.com/SVF-tools/SVF.

67.

Tran,

Etheridge,

Bletsch,

Jiang,

Freeh and

Ning, On the expressiveness of return-into-libc attacks, in: Recent Advances in Intrusion Detection: 14th International Symposium, RAID 2011, Menlo Park, CA, USA, September 20–21, 2011, Proceedings 14, Springer, 2011, pp. 121–141.

68.

Vorbis, https://github.com/xiph/vorbis.

69.

Wang,

Xie,

Li,

Wen,

Li,

Liu,

Qin,

Chen and

Sui, Typestate-guided fuzzer for discovering use-after-free vulnerabilities, in: Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering, 2020, pp. 999–1010.

70.

Whole-program-llvm, https://github.com/travitch/whole-program-llvm.

71.

WuFTPD, https://github.com/pmarkowsky/vulnerable-wu-ftpd-2.6.2.

72.

Zhang,

Wang,

Zhang,

Sun,

Wang and

Liu, A novel neural source code representation based on abstract syntax tree, in: 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE), IEEE, 2019, pp. 783–794. doi:10.1109/ICSE.2019.00086.

73.

Zlib, https://github.com/madler/zlib.

74.

Zstd, https://github.com/facebook/zstd.

Application	Performance overhead imposed by DSLR–

	O1	O2	O3	$O_{average}$
400.perlbench	2.9%	3.9%	1.8%	2.9%
401.bzip2	3.7%	1.9%	2.1%	2.6%
403.gcc	3.3%	2.7%	1.4%	2.5%
429.mcf	1.3%	1.0%	2.9%	1.7%
445.gobmk	3.7%	2.9%	1.1%	2.6 %
456.hmmer	1.3%	2.6%	2.4%	2.1%
458.sjeng	3.4%	1.3%	2.1%	2.3%
462.libquantum	2.6%	2.6%	1.9%	2.4%
464.h264ref	1.7%	2.0%	3.0%	2.2%
471.omnetpp	2.7%	1.5%	2.7%	2.3%
473 astar	1.7%	3.2%	1.2%	2.0%
483.xalancbmk	N/A
410.bwaves	N/A
416.gamess	N/A
433.milc	1.0%	2.1%	1.5%	1.5%
434.zeusmp	N/A
435.gromacs	N/A
436.cactusADM	N/A
437.leslie3d	N/A
444.namd	2.4%	2.8%	1.5%	2.2%
447.dealII	N/A
450.soplex	2.9%	1.7%	2.4%	2.3%
453.povray	3.0%	2.5%	1.7%	2.4%
454.calculix	N/A
459.GemsFDTD	N/A
465.tonto	N/A
470.lbm	3.5%	2.5%	1.4%	2.5%
481.wrf	N/A
482.sphinx3	2.8%	3.4%	1.1%	2.4%
Average				2.3%