1 Introduction

Effective countermeasures against memory corruption are of utmost importance for the operating system (OS) kernel. Specifically, instances of privilege escalation and security-feature disabling attacks often exploit memory corruption within kernel data [5, 10].

To mitigate the risk of memory corruption attacks, kernel address space layout randomization (KASLR) randomly places kernel code and data in the kernel memory at kernel startup. KASLR makes it challenging to identify the virtual address of the kernel data to be attacked and reduces the possibility of kernel data tampering due to memory corruption. However, the virtual address of privileged information on the kernel memory is fixed in the running kernel, which poses the following question.

Research question The side-channel attack could identify the placement of privileged information or gather the partial placement of the privileged information [11].

Thus, the remaining consideration is as follows: An adversary’s user process has overwritten the virtual address corresponding to the privileged information, exploiting a vulnerability within a currently running kernel.

This exploitation allows the adversary to orchestrate a privilege escalation attack via direct memory corruptions.

Fig. 1
figure 1

Overview of the KDRM

Full size image

Research contribution This paper proposes a kernel data relocation mechanism (KDRM) that allows dynamic relocation of privileged information in the kernel memory. The KDRM introduces the relocation-only page to provide kernel resistance against the privilege escalation attack through direct memory corruption that selectively alters only the privileged information associated with kernel data residing in the kernel memory.

Figure 1 provides an overview of the proposed KDRM. The KDRM relocates privileged information of the user process to a designated relocation-only page when a system call is issued. The relocation changes the position of privileged information in the kernel memory to change its virtual address. The relocation of privileged information makes it challenging to identify the virtual address associated with it. The KDRM can be applied to a running kernel with KASLR to improve the kernel’s resistance against attacks.

Implementations The KDRM allocates an additional kernel page (4KB) that contains privileged information of a user process. Additionally, the KDRM allocates multiple relocation-only pages (4KB) for each user process in the kernel memory, then the KDRM uses them to store privileged information to be protected. When a system call is issued, the privileged information is relocated to a randomly selected relocation-only page. Additionally, the reference to privileged information is changed to the relocation-only page. Then, the additional kernel page is unmapped, and the other relocation-only pages are temporarily unmapped by KDRM to safeguard against potential tampering and to protect from memory corruption. The virtual address of privileged information in the running kernel is dynamically changed by changing the page, and protected by unmapping the page.

Suppose that a user process performing a privilege escalation attack executes vulnerable kernel code that can be used in an arbitrary memory corruption attack. In that case, an attempt to tamper with privileged information can occur. However, the KDRM makes it challenging to locate the exact virtual address of the privileged information, because the additional kernel page and non-used relocation-only pages are unmapped from the kernel memory. Therefore, tampering with privileged information occurs on the page fault. In particular, tampering fails, and privilege escalation attacks are prevented.

In the proposed approach, the difficulty in identifying the virtual address of privileged information depends on its size to be relocated and on the number of relocation-only pages. When the relocation target is 256 bytes (8 bits) and the relocation-only page (4KB, 12 bits) is set as one page, privileged information can be protected from brute force attack in the range of 4 bits (see Sect. 6.7 for details).

Summary of contributions The research contributions in this paper are as follows:

  1. 1.

    To mitigate direct memory corruption, the design of KDRM enables the dynamic relocation of privileged information when a system call is issued. The implementation of KDRM on Linux is resistant to privilege escalation attacks.

  2. 2.

    The KDRM could prevent privilege escalation against user processes that attempt privilege escalation attacks. In this regard, the impact of the KDRM on user processes and kernel operation was evaluated. The results showed that the overhead to the kernel when issuing system calls ranged from 0.10 to 11.52%, and the impact on the kernel performance score was 0.11%.

1.1 Contribution difference

This paper is based on a conference paper [18], the present paper provides the general concept, additional design, evaluation results, implementation, portability, and comparison with related works. It thoroughly examines modern kernel requirements, considering Linux kernel implementation to provide an in-depth technical analysis and discussion for KDRM novelty, privileged information management, and lock mechanism. As an evaluation result, this paper meticulously investigated actual kernel vulnerabilities, utilizing the Proof-of-Code (PoC) program with CVE-2017-16995 [24]. The conference paper adopted the mimic kernel vulnerability. The aim was to evaluate the security capabilities of KDRM for the real kernel vulnerability. Additionally, the porting work of implementation to measure the performance evaluations for the latest Linux kernel 6.1.0 from 5.18.2. These evaluations are completely different points of the conference paper [18].

From the discussion, this paper considers the comparison of KDRM that refers to the privilege information protection approaches (e.g., KASLR [30], KCoFI [3], PrivWatcher [2], PrivGuard [29], and AKO [33]). The result of the comparison clarifies the characteristic of KDRM that indicates the dynamic relocating of protected kernel data is one of the various mitigation approaches for privilege escalation attacks.

2 Kernel vulnerability

Kernel vulnerabilities are instances of improper implementation that can be exploited to compromise the kernel [1]. Table 1 lists ten distinct types of kernel vulnerabilities. Meanwhile, Table 2 provides a summary of the impacts associated with four types of attacks utilizing these kernel vulnerabilities, delineating the effects introduced by each vulnerability type.

Memory corruption attacks exploit kernel vulnerabilities by targeting pointers and variables within kernel data since this specific memory area is susceptible to being rewritten. The KDRM functions as a countermeasure against memory corruption attacks that endeavor to write to arbitrary virtual addresses within the kernel memory.

2.1 Privilege escalation attack

Privilege escalation attacks require the invocation of vulnerable kernel code to exploit a known vulnerability. A summary of available PoC codes is provided in Table 3. In the context of privilege escalation attacks of Common Vulnerabilities and Exposures (CVE), there have been reported instances of kernel vulnerabilities that exploit deficiencies in privilege management, enabling the malicious overwriting of privileged information [21,22,23,24].

For a privilege escalation attack via direct memory corruption to be successful, certain prerequisites must be met. The adversary endeavors to execute a privilege escalation attack by focusing on kernel data related to user process privileged information which, resides within the kernel memory.

  • Direct memory corruption attacks necessitate the accurate identification of the virtual address of the kernel data storing privileged information. Once this target is specified, the adversary then seeks to manipulate the virtual address of this kernel data that holds privileged information.

Therefore, the adversary gains the ability to modify the user ID of a user process to that of an administrator user through the successful direct memory corruption attack.

Table 1 Types of kernel vulnerability [1]
Full size table
Table 2 Effects of kernel vulnerability [1] (\(\checkmark \) is KDRM mitigation)
Full size table
Table 3 Exploitable Linux kernel vulnerability list
Full size table
Fig. 2
figure 2

Structures related to user ID in Linux [7]

Full size image

2.2 Privileged information definition

Figure 2 depicts the structure definition of the user ID in the Linux kernel. The focal point of the attack was the kernel data associated with privileged information.

The Linux kernel has a task_struct structure that serves as the management unit for user processes and retains privileged information. Line 5 indicates that this privileged information is stored within the cred structure that governs the attributes of the user process. The user ID is held within the variable uid of the kuid_t structure, as depicted on line 12. This kuid_t structure is encompassed within the cred structure, spanning lines 9 through 16. Additionally, the kuid_t structure contains the variable val, represented by uid_t, detailed on lines 18 through 22. In a privilege escalation attack, the variable val of the uid within the kuid_t structure is altered to the user ID (0) corresponding to the root user.

3 Threat model

Fig. 3
figure 3

Design overview of the KDRM

Full size image

This section highlights the assumed threat model for the KDRM.

3.1 Adversary environment

The threat model in this study encompasses an adversary attempting memory corruption through a kernel vulnerability. The assumed adversary environment, outlined as the threat model, is summarized as follows:

  • Adversary: An adversary initiates a user process with normal user privileges. Within the adversary’s user process executes attack code that invokes vulnerable kernel code, then endeavors to carry out a direct memory corruption attack.

  • Kernel: The kernel contains vulnerabilities exploitable for direct memory corruption attacks that enable user processes to invoke vulnerable kernel code. Apart from access control features, no additional security mechanisms are applied for user processes.

  • Kernel Vulnerability: A kernel vulnerability allows the adversary to specify an arbitrary virtual address within the kernel data and proceed to execute a memory corruption attack. The adversary obtains the virtual address and the data intended for overwriting from the user process, allowing them to tamper with the targeted kernel data.

  • Attack target: The target of the attack is kernel data residing in the kernel memory that specifically stores privileged information related to the user process.

3.2 Attack scenario

In the assumed attack scenario, the adversary initiates a memory corruption attack on the kernel.

More specifically, the adversary employs an arbitrary user process operating with normal user privileges.

The adversary’s user process triggers vulnerable kernel code, facilitating a direct memory corruption attack capable of overwriting kernel data with arbitrary information.

  • In a privilege escalation attack involving direct memory corruption an adversary identifies the position of the kernel data containing a user process’s privileged information. Subsequently, the adversary only overwrites this privileged information, changing the user ID to one with administrative privileges.

4 The approach’s design

4.1 Requirement

The KDRM dynamically relocates protected kernel data during kernel operation. Its design is aimed at fulfilling the following requirements:

  • Requirement 1: The envisaged attack involves a direct memory corruption attack through a kernel vulnerability, specifically targeting the modification of privileged information during the execution of a system call.

  • Requirement 2: The objective is to obfuscate the relocation position of privileged information, making it challenging to discern its location.

  • Requirement 3: The control of relocating protected kernel data within the kernel is transparent to user processes.

4.2 Concept

The KDRM successfully meets the requirements for safeguarding kernel data against vulnerabilities within kernel code that could potentially lead to direct memory corruptions.

The design concepts of KDRM are delineated as the following two concepts:

  • Concept 1: The handling of protected kernel data relocation is executed within the kernel. It mitigates direct memory corruptions originating from user processes, thereby adding complexity to the detection of countermeasures.

  • Concept 2: The design of KDRM focuses on mitigating attacks targeting the relocation handling of protected kernel data. It ensures both user processes and kernel operations remain unaffected.

Concept 1 of KDRM definitively entails altering the placement of protected kernel data, such as privileged information, within the kernel memory before the vulnerable kernel code associated with system calls is executed. Concept 1 unequivocally satisfies both Requirements 1 and 2.

Concept 2 of KDRM is incorporated within the kernel itself, ensuring that it remains concealed from user processes. Furthermore, KDRM operates in isolation from other kernel operations. Concept 2 satisfies Requirement 3.

4.3 Protected kernel data relocation challenge

The design overview of KDRM is illustrated in Fig. 3. To align with the design concepts of KDRM and fulfill the requirements, multiple relocation-only pages are designated as relocation destinations for safeguarding kernel data within the kernel memory. Furthermore, the KDRM maintains lists including:

  • A list of kernel data earmarked for protection.

  • A list of relocation-only pages designated as relocation destinations.

  • A list of system calls exempted from relocation handling by the KDRM.

The definitions of protected kernel data and relocation-only page are as follows:

  • Protected kernel data: Protected kernel data pertains to privileged information generated during the creation of a user process. The protected kernel data is earmarked for relocation within the kernel memory.

  • Relocation-only page: A relocation-only page is a specific kernel page to which protected kernel data is relocated. The KDRM offers multiple relocation-only pages within the kernel memory to accommodate user processes.

4.3.1 Protected kernel data relocation handling

The KDRM executes relocation handling for protected kernel data both before and after the execution of a system call.

  • Before the system call execution, the KDRM relocates protected kernel data to a designated relocation-only page. Subsequently, the KDRM proceeds to unmap the original kernel data and the other remaining relocation-only pages from the kernel memory.

  • After executing the system call, the KDRM maps the previously unmapped relocation-only pages back into the kernel memory.

In the KDRM, the relocation destination for protected kernel data is randomly selected from a list of relocation-only pages before the system call is executed. This randomization of the virtual address of protected kernel data, within a specific range, enhances security by making it challenging to pinpoint the precise virtual address.

5 Implementation

5.1 Implementation overview

The environment chosen for implementing this scheme was Linux on the x86_64 CPU architecture. Figure 4 provides an overview of the implementation process. The KDRM generates relocation-only pages and allocates them for each user process to safeguard the privileged information associated with the kernel data. As part of the implementation process, the additional kernel page containing privileged information is duplicated to a relocation-only page that is randomly selected before the execution of the system call. The KDRM alters the virtual address of the privileged information to enhance security.

Fig. 4
figure 4

Implementation overview of the KDRM

Full size image

5.2 Protected kernel data

In the implementation, KDRM introduces an additional kernel page of 4KB dedicated to storing the protected kernel data, which encompasses the privileged information of the user process. The additional kernel page is defined as a struct structure containing privileged information such as uid and gid. Refer to Table 4 for a detailed list of privileged information pertaining to the protection target.

In the KDRM implementation, the additional kernel page is generated within the Linux user process as a struct structure within task_struct. The relevant source code include/linux/sched.h is modified. During the creation of a user process, the running kernel implements KDRM, which allocates an additional kernel page of 4KB size. This page stores the uid and gid values. At this time, the user process (for instance, a kernel task) of the current refers to this additional kernel page, which is equivalent to one page size (4KB)

Consequently, throughout the operational period of the user process, relocation handling of the additional kernel page, occupying 4KB of memory, is carried out precisely upon invocation of a system call originating from the user process.

Table 4 Kernel data to be protected in the KDRM implementation
Full size table

5.3 Relocation kernel page

In the KDRM implementation, an initial set of relocation-only pages is allocated at kernel startup to alleviate the load during user process creation. The allocation of relocation-only pages is facilitated using the alloc_pages function. Specifically, a designated number of relocation-only pages, such as 10 with a size of 4KB each, are allocated upon the creation of a user process. Additionally, the remove_pagetable function is employed to unmap the additional kernel page from the kernel page table, represented by the variable pgd of the current.

By assigning multiple relocation-only pages to each user process, a defined range of virtual addresses within the kernel memory can serve as relocation destinations for privileged information. Furthermore, the randomness introduced in the selection of relocation-only pages adds complexity. It increases the challenge of identifying the precise virtual address of the relocation destination.

Fig. 5
figure 5

Relocation control flow of kernel data to be protected

Full size image

5.4 Relocation handling

Figure 5 presents a relocation control flow of KDRM. The control of relocating kernel data, which contains privileged information, is executed through the utilization of lists comprising relocation-only pages and exempted system calls, as follows:

  1. 1.

    Hooks system calls invocations by user processes.

  2. 2.

    Determines if the system call number is included in the list of exempted system calls.

  1. (a)

    For exempt system calls: privileged information is not relocated.

  2. (b)

    For nonexempt system calls: privileged information is relocated.

  1. i

    Randomly selects a relocation-only page from the list of relocation-only pages as the relocation destination for privileged information.

  2. ii

    Duplicates the kernel data storing the privileged information to the relocation-only page.

  3. iii

    Change the pointer reference of cred of task_struct to the relocation-only page (see Fig. 4).

  4. iv

    Unmaps the privileged information of the additional kernel page from the kernel page and the remaining relocation-only pages from the kernel page table.

  1. 3.

    Continues execution of the system call.

  2. 4.

    Finishes the hook of system call.

After the conclusion of system calls other than those exempted, KDRM proceeds to remap the remaining relocation-only pages and the additional kernel page to the kernel page table.

5.4.1 Relocation-only page management

The implementation of KDRM manages the list of relocation-only pages. To control the assignment of relocation-only pages, the KDRM stores the assigned information that contains the relocation-only page and user process ID for each user process. If the user process is created, the KDRM creates this information into the list of relation-only pages. Additionally, if the user process is finished, the KDRM deletes this information from the list of relation-only pages. The KDRM has the lower bound of the number relocation-only page to assure the security capability of the KDRM (see Sect. 7.3.2).

The KDRM avoids the duplication assignment of relocation-only pages based on the list of relocation-only pages. The KDRM also determines the mapping and unmapping targets utilizing the relocation-only pages with user process ID in the list of relocation-only pages at the relocation handling.

5.5 System call hook point

The implementation of KDRM requires the hook mechanism in the Linux kernel source code arch/x86/entry/common.c. The implementation has two hook points: one is the entering of system call invocations that invoke KDRM handling to relocate the privileged information, and the other is the termination of system call invocation that KDRM handles to remap the remaining relocation-only pages. To forcefully invoke the hook points for each system call, both hook points are manually implemented into the Linux kernel.

5.6 Changing of privilege reference

Implementation of KDRM creates the pointer variable of the additional kernel page that refers to privileged information in the Linux kernel. The pointer of the additional kernel page is manually replaced for all direct access of privileged information in the Linux kernel. It requires the static modification of the source code for the Linux kernel.

It is a necessary modification for the relocation handling that requires the changing of the privileged information reference for the running kernel. With this modification, the reference of the additional kernel page is set at the user process creation. Therefore, the implementation of KDRM automatically changes the reference of privileged information to the selected relocation-only page from the additional kernel page at each system call invocation with relocation handling.

5.7 Page fault handling

An unauthorized write access to manipulate kernel data containing privileged information is detected. The handle_page_fault function within the page fault handler identifies and intercepts privilege escalation attacks. The Linux kernel can determine the virtual address being referenced during a page fault.

The implementation method involves comparing the virtual address of relocation kernel pages with the additional kernel page storing privileged information before executing relocation handling. When a page fault is perceived as an illicit write, a SIGKILL signal is dispatched to the targeted user process through the force_sig_info function.

Table 5 A system call that perform authorization operation that exempts the realization method
Full size table

5.8 Protected kernel data relocation exemptions

The potential impact on both kernel and user process operations varies depending on the type of kernel data being protected, and it may result in reference or write failures due to relocation within the kernel.

Specifically, KDRM enables users to predefine exempted system calls for each protected kernel data, preventing any disruptive effects on both the kernel and user processes resulting from relocation. Additionally, KDRM leverages these predefined exempted system calls to ascertain the applicability of relocation handling. The kernel data earmarked for protection remains in its original location without being relocated when the specified exempted system call is executed.

Table 5 summarizes the system calls that operate the privileged information. In the implementation, writing to privileged information may trigger page faults. Consequently, system calls explicitly designed to write to privileged information are meticulously managed through a list of exemptions in Table 5.

6 Evaluation

Fig. 6
figure 6

Results of preventing privilege elevation attacks using the KDRM

Full size image

6.1 Evaluation purpose

The evaluation of the kernel with KDRM encompasses an analysis of its security capabilities, the impact on kernel processing overhead, and the assessment of attack complexity via kernel data relocation. The evaluation criteria are delineated as follows

  1. 1.

    Security assessment of privilege escalation attacks

    Assesses the effectiveness of the kernel with KDRM in mitigating privilege escalation attacks facilitated through direct memory corruption utilizing kernel vulnerabilities.

  2. 2.

    Performance evaluation during kernel operation

    The benchmarking software measures the performance score of the kernel with KDRM.

  3. 3.

    Performance evaluation during system call invocations

    The benchmarking software quantifies the overhead associated with relocating kernel data both before and after the execution of system calls on a kernel integrated with KDRM.

  4. 4.

    Assessment of attack difficulty with kernel data relocation

    Comparison between the granularity of virtual address randomization achieved by kernel data relocation using KDRM and KASLR.

6.2 Evaluation environment

The evaluation was conducted on a dedicated device to assess both security and performance aspects. The evaluation device utilized for this purpose was an Intel(R) Core (R) i5-13500 processor operating at 2.50 GHz, equipped with 20 cores and 64 GB of memory. The device ran Debian 12.2 and employed Linux kernel version 6.1.0.

The implementation of KDRM in Linux kernel 6.1.0 modified 248 lines of code for nine files. Furthermore, addressing kernel vulnerabilities necessitated the inclusion of 32 extra lines, which could be employed for memory corruption during the security assessment of three files. The PoC code was implemented within 134 lines.

6.2.1 Kernel file modification

The implementation of KDRM in Linux kernel 6.1.0 modified the following nine files:

  • security/Kconfig: It provides the description and config of KDRM for the Linux kernel compile configuration.

  • kernel/fork.c: The fork system call invokes the setting up of KDRM at the user process creation.

  • include/linux/kdrm.h: It contains the definitions of the function prototype for the KDRM.

  • include/linux/sched.h: It contains a task_struct with the pointer of relocation-only pages for user process.

  • arch/x86/mm/Makefile: It contains the object file of KDRM for the Linux kernel compiling.

  • arch/x86/include/asm/kdrm.h: It contains the extern definitions of the function prototype.

  • arch/x86/mm/kdrm.c: It contains the main features of KDRM. These are relocation-only page allocation, protected kernel data storing, and relocation handling.

  • arch/x86/entry/common.c: It invokes the relocation handling of KDRM for each system call invocation.

  • arch/x86/mm/fault.c: It contains the page fault handler of KDRM.

6.3 Kernel vulnerability

The following system calls were introduced to evaluate the security capability of KDRM:

  • Original system call 1: It is designed to identify the virtual address of kernel data, such as the privileged information of a user process, and subsequently return this information to the respective user process.

  • Original system call 2: It refers to CVE-2017-16995 [24], which exploits the vulnerable kernel code to overwrite the privileged information of a user process for privilege escalation through direct memory corruption. It accepts two arguments, the virtual address and data intended for overwriting. Upon execution, the objective of the original system call 2 is to overwrite kernel data located at the specified virtual address. It raises the possibility of a privilege escalation attack, specifically when the first argument corresponds to the virtual address of the user process’s privileged information, and the second argument represents the root ID (e.g., 0).

6.4 Security assessment of privilege escalation attacks

As a security assessment, the adversary’s user process employs the original system call 1 to determine the virtual address associated with privileged information. Subsequently, the process endeavors to initiate a privilege escalation attack through the utilization of the original system call 2.

Figure 6 shows the results of attack prevention by KDRM when a user process attempts a privilege escalation attack. In the adversary’s user process, line 2 displays the privileged information of the user process. The value of uid is 1,000, which confirms that the user is a normal user. In line 4, it calls the original system call 1 to specify the virtual address of the kernel data (e.g., 0xffff88001d35fe40) storing the privileged information.

In line 5, the user executes the original system call 2, a privilege escalation attack. From CVE-2017-16995 [24], the original system call 2 can overwrite kernel data using a given virtual address (e.g., 0xffff88001d35fe40) with administrator privilege (e.g., 0 is root privilege). In the kernel, line 8 shows the virtual address of the kernel data (e.g., 0xffff88001d35fe40) containing the privileged information. Lines 13 and 14 indicate the range of virtual addresses of the relocation-only page (e.g., 0xffff88001d363000). In lines 15 and 16, KDRM relocates the kernel data that stores the privileged information to the relocation-only page. The virtual address is changed before executing the original system call 2.

In line 18, an attempt is made to overwrite the virtual address specified by the original system call 2 (e.g., 0xffff88001d35fe40). A page fault with error number 2 is caught in line 19 (e.g., 0x0002 for 0xffff88001d35fe40). The page fault indicates a violation of writing to the kernel page for the virtual address. The writing target is the previous virtual address of privileged information.

Table 6 UnixBench comparison performance of implementation
Full size table

6.5 Overhead of kernel performance

To evaluate the kernel’s performance, UnixBench version 5.1.3 was run ten times on the Linux kernel before and after applying KDRM. Average values obtained in these runs were used to calculate the performance score.

Table 6 presents the UnixBench performance scores for each running kernel, evaluating numerical computation, file copy, process processing, and system calls. Elevated score values are indicative of superior performance.

Table 6 shows that KDRM had the least influence on the score, with a mere no impact on pipe throughput, and the most substantial impact on execl throughput overhead, causing an 4.46% increase. The cumulative effect on the performance score was 0.11%.

6.6 Overhead of kernel processing

In KDRM, the protection of privileged information is a priority during system call execution. In the evaluation phase, the benchmarking tool LMbench version 3.0-a9 was executed ten times on a Linux kernel both before and after the implementation of KDRM.

The computation of overhead involves the determination of the average value pertaining to system calls. Table 7 lists the results of the performance evaluation. In LMbench, the number of system call invocations differs for each evaluation item: fork+/bin/sh is 54 times, fork+execve is 4 times, fork+exit is 2 times, open/close is 2 times, and the others are once. Table 7 shows the overhead of the system call execution. The highest and lowest overheads are fork+execve with 11.52% and write with 0.10%, respectively.

Table 7 Overhead of KDRM on the Linux kernel (\(\mu \)s)
Full size table
Table 8 The comparison of randomization entropy
Full size table

6.7 Attack difficulty assessment by kernel data relocation

A comparison between KDRM and the attack difficulty of Linux KASLR [8, 19] is presented in Table 8. The granularity of virtual address randomization is expressed in terms of entropy [30]. In Linux KASLR, 32 bits are randomized in 2 MB (21 bits) units, resulting in 8 bits of entropy for 512 MB (29 bits) and 9 bits of entropy for 1 GB (30 bits). Table 8 delineates that the relocation target is 256 bytes with 8 bits, and the relocation-only pages (4KB, 12 bits) range from 1 to 4096 pages with 4, 10, and 16 bits of entropy.

The number of attack attempts required for successful memory corruption in a brute force attack is \(2^{n-1}\) for n bits of entropy if the virtual address remains unchanged during the attack attempts. However, if the virtual address can be randomized for each attack attempt, the number of attack attempts is \(2^{n}\) [30]. Since Linux KASLR randomizes virtual addresses only at startup, the resulting number of attack attempts is \({2^{n-1}}\). On the other hand, KDRM can randomize the virtual address of kernel data with each system call from the user process. Thus, the number of attack attempts becomes \(2^{n}\) for n bits of entropy.

7 Discussion

7.1 Evaluation consideration

The assessment of resistance against direct memory corruption substantiated the efficacy of KDRM in mitigating privilege escalation attacks. In the process of implementing KDRM, careful attention is directed toward securing kernel data stores privileged information. Through deliberate relocation, subsequent unmapping, and meticulous restoration procedures within the running kernel, virtual address identification pertaining to privileged information becomes notably intricate.

The outcomes of the performance evaluation demonstrate that KDRM has a marginal impact on numerical calculations and process operations. However, it imposes a notable overhead for processes creation and system call invocations, particularly operations like file copying. As a contributing factor to the overhead, the evaluation emphasizes the processing time necessary for duplicating, unmapping, and subsequently restoring a relocation-only page subsequent to the invocation of a system call. The results conclusively affirmed that the stability of kernel operations remained unaffected during the performance evaluation.

7.2 Approach consideration

7.2.1 Design and implementation

The design of KDRM is such that the relocation of protected kernel data with each system call is transparent to user processes. At the inception of the KDRM design, careful consideration was given to specifying the user process privileged information stored in the kernel data during user process creation. This focus stemmed from the recognition that privileged information represents a prime target for privilege escalation attacks through memory corruption.

In order to safeguard kernel data beyond privileged information, a thorough analysis of the write locations for each kernel data and an assessment of the associated system calls are imperative. To minimize KDRM’s impact on kernel operation, system calls that entail modifications to privileged information are deliberately excluded from the KDRM application. Moreover, in scenarios where the kernel data to be protected exceeds the page size (4KB) or entails numerous references within the kernel, a careful assessment of KDRM’s applicability is essential, considering potential performance implications.

7.2.2 Attack difficulty

In the realm of KDRM, the number of attack attempts directed at the safeguarded kernel data escalates exponentially, calculated as \(2^{n}\) for n bits of entropy. This amplification in attack cost significantly heightens the challenge associated with executing a memory corruption attack.

However, it’s important to note that the value of n in the bit entropy equation fluctuates, contingent on variables such as the size of the kernel data slated for protection and the quantity of relocated pages. Consequently, a comprehensive understanding of the entropy’s correlation with the kernel data type is crucial. This understanding aids in assessing the intricacy of identifying virtual addresses and determining the attack cost for memory corruption attacks, tailored to the specific type of kernel data in question.

7.2.3 Mathematically consideration

The security implications of KDRM must be considered. The mathematical consideration for the KDRM is expressed from two scenarios [30].

  • Scenario 1: The virtual address of privileged information is fixed during the attack. The privileged information of the user process is not relocated at the system call invocation. Scenario 1 considers the brute force attack against the vanilla kernel. The probability of the malicious user process that succeeds in the brute force attack is the following.

    $$\begin{aligned} {\frac{2^{n}-1}{2^{n}} \cdot \frac{2^{n}-2}{2^{n}-1} \dots \frac{2^{n}-(a-1)}{2^{n}-a} \cdot \frac{1}{2^{n}-(a-1)} = \frac{1}{2^{n}}} \end{aligned}$$

    where a is the count of PoC code execution and n is the number of bits of randomness. Furthermore, only 1 of a is succeeded and others are failed for privileged execution. The number of brute force attacks for scenario 1 is the following.

    $$\begin{aligned} \sum _{t=1}^{2^n}a \cdot \frac{1}{2^n} = \frac{1}{2^n} \cdot \sum _{a=1}^{2^n}a = \frac{2^{n} + 1}{2} \approx 2^{n-1} \end{aligned}$$

  • Scenario 2: The virtual address of privileged information changes with each attack. KDRM relocates the privileged information of the user process at the system call invocation. Scenario 2 considers the brute force attack against the kernel with KDRM. The probability of the malicious user process that tries the brute force attack is \(p = \frac{1}{2^{n}}\). Furthermore, n is not dependent on other attacks, the probability value p is the geometric random [30]. The number of brute force attacks is the expected value for scenario 2, which is the following.

    $$\begin{aligned} E(X) = \frac{1}{p} = 2^{n} \end{aligned}$$

The comparison of two scenarios of KDRM indicates scenario 2 requires \(\frac{2^{n}}{2^{n-1}} = 2\) times more attack than scenario 1. Therefore, the KDRM conducts the relocation of privileged information ensure the increasing attack difficulty for the malicious user process on the running kernel.

7.2.4 Optimization method

The KDRM requires the performance overhead to apply the relocation of kernel data for each user process. Two approaches are necessary to reduce the operation cost. The first approach increases the number of the exclusion system call list. The exclusion system call list extends to the inspected system calls with the assurance of no effect on kernel vulnerabilities. The KDRM inserts additional system calls to the exclusion system call list to reduce the overhead of KDRM.

The second approach optimally manages the protected kernel data on the relocation-only page. The implementation of KDRM targets the privileged information. The KDRM can create multiple relocation-only pages containing the privileged information at the user process creation. It leads that the KDRM reduces the operation cost of the copies of the privileged information to the relocation-only page at the invocation of the system call. The KDRM only selects the relocation-only page and changes the references of privileged information to it.

7.3 Limitation of KDRM

While KDRM serves to relocate protected kernel data, it does not inherently prevent vulnerable kernel code calls or unauthorized memory writes. Control Flow Integrity (CFI), on the other hand, focuses on validating the sequence of code calls, effectively deterring unauthorized code invocations. Another relevant technology is Memory Protection Key (MPK), which empowers the CPU to restrict writes on a page-by-page basis [15]. Hence, to enhance the security capabilities of the kernel, synergistic integration of CFI and MPK with KDRM can significantly enhance the kernel’s resilience against various forms of attacks.

7.3.1 Defeating consideration

The defeating method can attempt to avoid the approach of KDRM. The malicious user process tries to overwrite privileged information of other adversary’s user process through the memory corruption kernel vulnerability. In that case, the adversary might bypass the KDRM that focuses on the prevention of the malicious user process modifying its privileged information. However, it is hard to identify the virtual address of privileged information of other adversary’s user processes during the attack execution. Because the KDRM changes the virtual address of privileged information each time that another adversary’s user process invokes system calls on the running kernel.

To mitigate the defeating method, the consideration of an additional mechanism that applies the KDRM for each context switch for user processes. It makes it more difficult to identify the privileged information of other user processes from the adversary.

7.3.2 Relocation-only page consideration

The number of relocation-only page assignments must be considered for the implementation of KDRM. The relocation-only pages are allocated at the kernel startup, and this flow might lead to insufficient random relocation for numerous user processes.

Because a user process has to select remaining relocation-only pages when another user processes during system call invocation, it decreases the randomness of KDRM.

To resolve this security compromise, the KDRM has the lower bound of the number relocation-only page. If the non-used relocation-only page reaches its lower bound, KDRM automatically allocates new relocation-only pages at the user process creation.

The implementation of KDRM can keep 10 to 20 relocation-only pages for each user process. It guarantees the randomness of relocation to assure the security capability of the KDRM.

7.4 Portability

KDRM relies on a page-based approach to administer kernel memory, safeguarding both kernel data and privileged information specific to each user process.

In a comparable design, FreeBSD orchestrates the construction and supervision of kernel memory through page tables, while also associating privileged information with individual user processes [9]. Given the similarities in the underlying principles, the design and implementation of KDRM can potentially serve as a portable feature for FreeBSD, thereby enhancing its security capabilities.

7.4.1 Other Linux distribution

The implementation of KDRM is applied to Linux kernel version 6.1.0 on Debian 12.2. The Linux kernel 6.1.0 is vanilla and stable version from the Linux kernel archives [7]. Although the config of Linux kernel is used from the custom Linux kernel of Debian 12.2, it does not have any affect to the parts of the KDRM source code. Therefore, the implementation of KDRM could be applied to vanilla Linux kernel 6.1.0 on other Linux distributions (e.g., Ubuntu, Gentoo, and Arch Linux etc).

7.4.2 x64 implementation case

The x64 supports 64 bit address bus, allowing access to a much larger address space of up to 18.4 million TB of RAM. It is beneficial for the KDRM because the KDRM for x64 increases the number of relocation-only pages and the number of protected kernel data with enough memory space. It assures that an attack is more difficult for the kernel memory corruption.

However, the KDRM for x64 requires the additional overhead for the management cost of relocation-only pages, protected kernel data for the kernel page, and data relocation handling of KDRM. It considers that the portability concern occurs when the careful implementation of the Linux kernel is required to x64 from x86_64 CPU architecture.

7.5 Kernel stability consideration

7.5.1 Page fault handling

The handling of page faults is a critical aspect in maintaining the stability of the kernel. To ensure kernel stability, the implementation of KDRM compares the virtual address of the page fault with the additional kernel page and relocation-only pages. When a correct comparison is established, KDRM initiates the sending of a KILL signal to the malicious user process.

The adversary attempts to persistently overwrite privileged information. This could potentially trigger a double fault, resulting in the halting of the kernel. The implementation of KDRM should support an additional mechanism that manages the access count of the additional kernel page and relocation-only pages, and then KDRM should stop malicious user process execution by the attacker after the page faults have occurred. The ongoing emphasis remains on integrating such a mechanism within the KDRM to bolster security capabilities while preserving kernel stability for future deployments.

7.5.2 Deadlock mitigation

In the context of ensuring kernel stability, it is crucial to address potential deadlock scenarios. In the current implementation of KDRM, a KILL signal is dispatched to the malicious user process upon detection of a page fault resulting from a privilege escalation attack. However, a critical concern arises when the corresponding kernel thread obtains global locks within the running kernel, as this can precipitate a deadlock situation, ultimately leading to system panic or erratic behavior.

The Linux kernel utilizes a diverse array of global lock types, such as DEFINE_MUTEX, to manage synchronization. It is imperative to consider the potential attack scenario in which a malicious user process, executing a privilege escalation attack, acquires these global locks.

In order to attain consistent and deadlock-mitigated kernel performance, it becomes imperative to assess the status of global lock acquisition by the user process in conjunction with the kernel thread before initiating the KILL signal. The KDRM implementation facilitates this by establishing a waiting list for the sending of the KILL signal. Subsequently, the KDRM implementation periodically monitors this waiting list and triggers the KILL signal toward the relevant kernel thread only once global locks have been forcibly released. Such a mechanism is deemed necessary for future implementations to safeguard and maintain kernel stability.

8 Related work

Memory protection is an active research topic. Software and hardware-based methods are proposed, and then applied to kernel and other privileged software have to be expected [31].

Running kernel protection: KASLR is a security measure designed to mitigate attacks on the kernel memory by altering the virtual addresses of both the kernel code and data [30]. Moreover, Adelie has introduced an extension of KASLR to 64-bit systems, with a specific focus on application to device drivers, further enhancing the security posture [26]. For the microvm environment, there is a proposed methodology for implementing KASLR on a guest operating system within a virtual machine environment, enhancing security at the virtualization layer [13].

Prevention of malicious code injection: Exclusive page frame ownership is employed as a defense mechanism in the kernel, facilitating dedicated page allocation for both the kernel and user processes, thus enhancing security [16]. Additionally, Kernel Control Flow Integrity (KCoFI) presents a technique for enforcing CFI within the kernel. KCoFI treats asynchronous processing as an exception and employs code call order verification to prevent erroneous code execution, bolstering security [3]. Moreover, the hardware-based kernel control flow integrity adopts the pointer authentication of ARM architecture that verifies the integrity of pointer value with kernel contexts [34].

Kernel attack surface reduction: As an attack surface minimization technique that removes attackable areas of the kernel, kRazor adopts a per-kernel code approach to determine availability during user process execution, thereby removing potential attack vectors within the kernel [17]. Moreover, KASLR optimizes memory allocation by placing in memory only the essential kernel code and data required for the execution of user processes, further enhancing security [35]. Additionally, Hacksaw reduces the attack surface of inoperative device drivers to analyze call graph, driver dependency, and compilation unit [14].

Privileged information protection: PrivAnalyzer investigates the usage of Linux privileges for several programs, then determines the consideration of retaining various Linux privileges [4]. PrivWatcher introduces dual reference monitors that forcibly manage the writing permission of privileged information with memory protection regions to prevent privilege escalation attacks [2]. PrivGuard and AKO save the privileged information of the user process into the kernel stack to restore privileged information when privileged information is illegally modified after system call invocation [29, 33].

Memory protection and isolation: As memory protection with hardware that mitigates kernel memory corruption, xMP isolates kernel memory region and protection using MPK [28], and monolithic kernel and unikernel also protect and isolate the multiple kernel memory regions with MPK [25, 32]. To enhance the granularity of isolation, DOPE automatically protects the kernel data at the compile time for the running kernel [20], and EPK extends the protection number of MPK using Extended Page Table switching [12]. Additionally, the nested kernel with Symmetric Multi-Processing (SMP) isolates the kernel address space of each CPU [27].

Table 9 Comparison of kernel data protection methods and types of target vulnerability (C. code execution, M. memory corruption, P.E. privilege escalation) [6](\(\checkmark \) is supported; \(\triangle \) is partially supported)
Full size table

8.1 Comparison

Table 9 presents a comparative analysis of the proposed method with previous studies [2, 3, 29, 30, 33].

Unlike KASLR, which perturbs virtual addresses used for kernel data access and kernel code execution with each kernel boot to augment the complexity of potential attacks [30]. KDRM maintains a consistent mapping of virtual addresses for kernel code and kernel data throughout the kernel’s initialization process. KASLR constancy introduces a potential security vulnerability as attackers may exploit side-channel attacks to deduce these fixed virtual addresses and potentially employ them for malicious activities [11]. In contrast, KDRM employs a strategy involving multiple relocation-only pages, each of which occupies a 4KB memory region, to facilitate the relocation of kernel data. Notably, KDRM is operable in a live kernel environment and, when employed alongside KASLR, serves to bolster the kernel’s resistance against a spectrum of potential attacks.

KCoFI operates at the architecture level, enabling the verification of call sequences related to asynchronous processing [3]. CFI is an effective mechanism for preventing unauthorized code calls; however, applying CFI comprehensively to all kernel code calls increases system overhead. In the context of the KDRM, the primary focus is on relocating kernel data rather than inhibiting attacks. KDRM, in conjunction with CFI, can effectively thwart attacks, especially in cases where CFI measures are bypassed.

PrivWatcher handles the write permission of privileged information for the running kernel with the dual reference monitors [2]. PrivWatcher is an effective approach to preventing direct memory corruption. However, PrivWatcher has to correctly adjust and monitor write protection handling placements in the entire kernel’s behavior. The kernel data relocation of KDRM does not conflict with PrivWatcher. The relocation and write protection of kernel data improve kernel security capability. KDRM provides a mitigation feature, and PrivWatcher provides a prevention feature against direct memory corruption to reduce the success cases of attacks on the running kernel.

PrivGuard and AKO achieve the restoration of privileged information into the kernel stack after a privilege escalation attack from a malicious user process [29, 33]. The malicious user process does not acquire root privileges on the running kernel when PrivGuard and AKO can detect illegal modification. However, PrivGuard and AKO do not focus on the mitigation of direct memory corruption. If the malicious user process identifies the position of stored privileged information in the kernel stack, which is also potentially illegally modified through a kernel vulnerability. The kernel data relocation of KDRM can be potentially applied to the kernel with PrivGuard and AKO to achieve the challenge of identifying restored privileged information. The combination of PrivGuard, AKO, and KDRM increases the attack difficulty for the running kernel.

8.2 Attack difficulty

The attack difficulty between PrivGuard, AKO, and KDRM must be considered. PrivGuard and AKO store the privilege information of the user process to the kernel stack at the system call invocation [29, 33]. Although the modification of privilege information is available for Privilege and AKO, the privilege escalation fails because the comparison of stored privilege information and user process privilege information is detected. PrivGuard and AKO replicate the attack targets to increase the attack difficulty of running the kernel. The malicious user process needs to additionally overwrite the stored privilege information of the kernel stack while the system calls execution. Therefore, the malicious user process requires multiple kernel vulnerabilities containing kernel memory corruption and kernel stack overflow.

KDRM relocates the privilege information that achieves the random changing of virtual address at the system call invocation. Although KDRM does not replicate the attack targets, the malicious user process needs to identify the virtual address of privileged information on the relocation-only page for the privilege escalation with the kernel vulnerability of kernel memory corruption. The attack difficulty of KDRM relies on the number and allocated placement of relocation-only pages on the kernel memory. It is the different point of increasing the attack difficulty from PrivGuard and AKO.

8.3 Security comparison

The security comparison between PrivWatcher and KDRM must be considered. PrivWatcher provides dual reference monitors that support two aspects of security capabilities. First is the isolation of privileged information on the safe region from the kernel. Another is the guarantee of privileged information read and write consistency in the kernel [2]. The safe region of PrivWatcher depends on the combination of the memory management unit (MMU) and the kernel memory allocator to reserve the read-only dedicated memory space. Additionally, the read and write consistency relies on the pointer reference of the safe region and the page table value of the CPU register (e.g., CR3 of x86 and TTBR of ARM).

KDRM provides the relocation-only page and the relocation handling that achieves the randomization of virtual addresses for privileged information. The randomization range relies on the number of relocation-only pages. KDRM applies the randomization timing at the system call invocations that achieve the attack difficulty for the kernel from the malicious user process.

The security capability difference between PrivWatcher and KDRM indicates that PrivWatcher allows the malicious user process to identify the virtual address of privileged information. It is still the remaining weak point of the running kernel. KDRM increases the identification difficulty for the virtual address of privileged information. The malicious user process requires the estimation of the virtual address of privileged information to accomplish the privileged escalation. This kernel hardening achieves additional security capability of KDRM.

9 Conclusion

This paper proposes a KDRM, a novel system aimed at mitigating direct memory corruption attacks by relocating privileged information within the kernel memory. The KDRM incorporates multiple relocation-only pages, allowing privileged information to be relocated to a randomly selected relocation-only page. The dynamic approach of KDRM ensures that the placement of privileged information is in constant flux, providing enhanced protection against privilege escalation attempts. KDRM can seamlessly complement KASLR within a running kernel, presenting a robust defense against direct memory corruption attacks. By combining both mechanisms, the identification of privileged information and subsequent privilege escalation attempts become notably more challenging, enhancing the overall security posture of the system.

The evaluation results conclusively demonstrated the efficacy of KDRM in preventing privilege escalation attacks initiated by user processes. During the overhead evaluation, the kernel load while issuing system calls varied between 0.10 and 11.52%, resulting in an overall kernel performance score impact of 0.11%. Furthermore, in the attack difficulty evaluation of kernel data relocation using KDRM, it was evident that this approach demanded a significantly higher number of attack attempts compared to utilizing KASLR, underlining the robustness of KDRM in enhancing security.