Search

Address space layout randomization was a great role model, being a light-weight defense technique that could prevent early return-oriented programming attacks. Simple yet effective, address space layout randomization was quickly widely adopted. Conversely, today only a trickle of defense techniques arebeing integrated or adopted mainstream. As code reuse attacks have evolved in complexity, defenses have strived to keep up. However, to do so, many have had to take unfavorable tradeoffs like using background threads or protecting only a subset of sensitive code. In reality, these tradeoffs were unavoidable steps necessary to improve the strength of the state of the art. In this article, we present Mardu , an on-demand system-wide runtime re-randomization technique capable of scalable protection of application as well as shared library code that most defenses have forgone. We achieve code sharing with diversification by implementing reactive and scalable rather than continuous or one-time diversification. Enabling code sharing further removes redundant computation like tracking and patching, along with memory overheads required by prior randomization techniques. In its baseline state, the code transformations needed for Mardu security hardening incur a reasonable performance overhead of 5.5% on SPEC and minimal degradation of 4.4% in NGINX, demonstrating its applicability to both compute-intensive and scalable real-world applications. Even when under attack, Mardu only adds from less than 1% to up to 15% depending on application size and complexity.

Operating systems adopt kernel protection methods (e.g., mandatory access control, kernel address space layout randomization, control flow integrity, and kernel page table isolation) as essential countermeasures to reduce the likelihood of kernel vulnerability attacks. However, kernel memory corruption can still occur via the execution of malicious kernel code at the kernel layer. This is because the vulnerable kernel code and the attack target kernel code or kernel data are located in the same kernel address space. To gain complete control of a host, adversaries focus on kernel code invocations, such as function pointers that rely on the starting points of the kernel protection methods. To mitigate such subversion attacks, this paper presents multiple kernel memory (MKM), which employs an alternative design for kernel address space separation. The MKM mechanism focuses on the isolation granularity of the kernel address space during each execution of the kernel code. MKM provides two kernel address spaces, namely, i) the trampoline kernel address space, which acts as the gateway feature between user and kernel modes and ii) the security kernel address space, which utilizes the localization of the kernel protection methods (i.e., kernel observation). Additionally, MKM achieves the encapsulation of the vulnerable kernel code to prevent access to the kernel code invocations of the separated kernel address space. The evaluation results demonstrated that MKM can protect the kernel code and kernel data from a proof-of-concept kernel vulnerability that could lead to kernel memory corruption. In addition, the performance results of MKM indicate that the system call overhead latency ranges from $0.020~\mu \text{s}$ to $0.5445~\mu \text{s}$ , while the web application benchmark ranges from $196.27~\mu \text{s}$ to 6, $685.73~\mu \text{s}$ for each download access of 100,000 Hypertext Transfer Protocol sessions. MKM attained a 97.65% system benchmark score and a 99.76% kernel compilation time.

With the wide deployment of security mechanisms such as Address Space Layout Randomization (ASLR), memory disclosures have become a prerequisite for critical memory-corruption attacks (e.g., code-reuse attack)—adversaries are forced to exploit memory disclosures to circumvent ASLR as the first step. As a result, the security threats of memory disclosures are now significantly aggravated—they break not only data confidentiality but also the effectiveness of security mechanisms. In this paper, we propose a general detection methodology and develop a system to stop memory disclosures. We observe that memory disclosures are not root causes but rather consequences of a variety of hard-to-detect program errors such as memory corruption and uninitialized read. We thus propose a replicated execution–based methodology to generally detect memory disclosures, regardless of their causes. We realize this methodology with Buddy : By seamlessly maintaining two identical running instances of a target program and diversifying only its target data, Buddy can accurately detects memory disclosures of the data, as doing so will result in the two instances outputting different values. Extensive evaluation results show that Buddy is reliable and efficient while stopping real memory disclosures such as the Heartbleed leak.

The state-of-the-art contributions in the area of memory forensics are centered around uncovering potentially hidden processes, control flow and code pointer integrity manipulations and detecting malicious code injections done by attackers. At the same time, deployment of memory protection mechanisms like control flow integrity, data execution prevention/no-execute, address space layout randomization and kernel address space layout randomization, have obviated the use of such attack vectors for sensitive information disclosure. Thus, attackers are now adopting various techniques to elude memory protection using memory corruption or memory disclosure attacks inside the operating system (OS). The heavy-dependence of all such advanced prevention and defense mechanisms on memory protection/memory safety attributes are luring attackers to conduct sophisticated data attacks against the OS that leaves no traces in the file system. In this paper, while assessing the security implications of such attack vectors, we propose a mechanism to capture such memory-protection-manipulation-based attack footprints at run time in the form of a utility called PageDumper. While parsing the system virtual address space and page table entries(for the process and kernel address space), it collects the in-memory data attack footprints at run time. Thus, PageDumper can supplement information(s) for the postmortem analysis of run time process and the kernel address space environment, when used in conjunction with memory snapshots taken through memory acquisition tools for a more practical and in-depth memory analysis.

Countermeasures against kernel vulnerability attacks on an operating system (OS) are highly important kernel features. Some kernels adopt several kernel protection methods such as mandatory access control, kernel address space layout randomization, control flow integrity, and kernel page table isolation; however, kernel vulnerabilities can still be exploited to execute attack codes and corrupt kernel memory. To accomplish this, adversaries subvert kernel protection methods and invoke these kernel codes to avoid administrator privileges restrictions and gain complete control of the target host. To prevent such subversion, we present Multiple Kernel Memory (MKM), which offers a novel security mechanism using an alternative design for kernel memory separation that was developed to reduce the kernel attack surface and mitigate the effects of illegal data manipulation in the kernel memory. The proposed MKM is capable of isolating kernel memory and dedicates the trampoline page table for a gateway of page table switching and the security page table for kernel protection methods. The MKM encloses the vulnerable kernel code in the kernel page table. The MKM mechanism achieves complete separation of the kernel code execution range of the virtual address space on each page table. It ensures that vulnerable kernel code does not interact with different page tables. Thus, the page table switching of the trampoline and the kernel protection methods of the security page tables are protected from vulnerable kernel code in other page tables. An evaluation of MKM indicates that it protects the kernel code and data on the trampoline and security page tables from an actual kernel vulnerabilities that lead to kernel memory corruption. In addition, the performance results show that the overhead is 0.020 \(\mu \)s to 0.5445 \(\mu \)s, in terms of the system call latency and the application overhead average is 196.27 \(\mu \)s to 6,685.73 \(\mu \)s , for each download access of 100,000 Hypertext Transfer Protocol sessions.

Presented at the 4th XoveTIC Conference, A Coruña, Spain, 7–8 October 2021 [Abstract] Memory management is one of the main tasks of an Operating System, where the data of each process running in the system is kept. In this context, there exist several types of attacks that exploit memory-related vulnerabilities, forcing Operating Systems to feature memory protection techniques that make difficult to exploit them. One of these techniques is ASLR, whose function is to introduce randomness into the virtual address space of a process. The goal of this work was to measure, analyze and compare the behavior of ASLR on the 64-bit versions of Windows 10 and Ubuntu 18.04 LTS. The results have shown that the implementation of ASLR has improved significantly on these two Operating Systems compared to previous versions. However, there are aspects, such as partial correlations or a frequency distribution that is not always uniform, so it can still be improved. We wish to acknowledge the support received from the Centro de Investigación de Galicia “CITIC”. CITIC, as Research Center accredited by Galician University System, is funded by “Consellería de Cultura, Educación e Universidade from Xunta de Galicia”, supported in an 80% through ERDF, ERDF Operational Programme Galicia 2014–2020, and the remaining 20% by “Secretaría Xeral de Universidades” (Grant ED431G 2019/01). This work was also supported by the “Consellería de Cultura, Educación e Ordenación Universitaria” via the Consolidation and Structuring of Competitive Research Units—Competitive Reference Groups (ED431C 2018/49) and the COST Action 17124 DigForAsp, supported by COST (European Cooperation in Science and Technology, www.cost.eu, (accessed on 20 July 2021)) Xunta de Galicia; ED431G 2019/01 Xunta de Galicia; ED431C 2018/49

Return Oriented Programming (ROP) chains attack has been widely used to bypass Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) protection. However, the generation technology for ROP chains is still in a state of manual coding. While, current techniques for automatically generating ROP chains are still insufficiently researched and have few successful applications. On the other hand, the existing methods are based on using Intermediate Language (IL) which is in order to translate the semantics of original instructions for symbolic execution, and then fill in a predefined gadget arrangement to automatically construct a gadget list. This kind of methods may bring following problems: (1) when converting semantics of original to IL, there is a large amount of overhead time, critical instructions may be discarded; (2) the process of populating a predetermined gadget arrangement is inflexible and may fail to construct ROP chains due to address mismatching. In this paper, we propose the Automatic ROP chains Generation (ARG) which is the first fully automatic ROP chains generation tool without using IL. Tested with data from 6 open-source international Capture The Flag (CTF) competitions and 3 Common Vulnerabilities & Exposures (CVE)s, this technology successfully generated ROP chains for all of them. According to the obtained results, our technique can automatically create ROP payloads and reduce up to 80% of ROP exploit payloads. It takes only 3-5 seconds to exploit successfully, compared to manual analysis for at least 60 minutes, as well as it can effectively bypass both Write XOR Execute (W⊕X) and ASLR.

One of the most commonly known vulnerabilities that can affect a binary executable is the stack-based buffer overflow. The buffer overflow occurs when a program, while writing data to a buffer, overruns the buffer’s boundary and overwrites adjacent memory locations. Nowadays, due to multiple protection mechanisms enforced by the operating system and on the executable level, the buffer overflow has become harder to exploit. Multiple bypassing techniques are often required to be used in order to successfully exploit the vulnerability and control the execution flow of the studied executable. One of the security features designed as protection mechanisms is Data Execution Prevention (DEP) which helps prevent code execution from the stack, heap or memory pool pages by marking all memory locations in a process as non-executable unless the location explicitly contains executable code. Another protection mechanism targeted is the Address Space Layout Randomization (ASLR), which is often used in conjunction with DEP. This security feature randomizes the location where the system executables are loaded into memory. By default, modern day operating systems have these security features implemented. However, on the executable level, they have to be explicitly enabled. Most of the protection mechanisms, like the ones mentioned above, require certain techniques in order to bypass them and many of these techniques are using some form of address memory leakage in order to leverage an exploit. By successfully exploiting a buffer overflow, the adversary can potentially obtain code execution on the affected operating system which runs the vulnerable executable. The level of privilege granted to the adversary is highly depended on the level of privilege that the binary is executed with. As such, an adversary may gain elevated privileges inside the system. Most of the times, this type of vulnerability is used for privilege escalation attacks or for gaining remote code execution on the system.

ASLR is currently an effective mean to defend against exploits based on known addresses, but in recent years, exploit codes have begun to effectively bypass the ASLR technology. Since the ASLR mechanism bypass methods are different and closely related to the target program, the current vulnerability assessments with ASLR enabled are manually completed based on the experience of manual vulnerability exploitation. Therefore, how to quickly assess software vulnerabilities, especially with the ASLR enabled, is a problem that needs to be solved in current software security. In this paper, we propose an automatic evaluation approach for binary software vulnerabilities with ASLR enabled, that can obtain key address information from the program to identify the possible ASLR bypasspaths. The approach uses an information leakage method based on a recessive output function by imitating the ASLR bypass technology commonly used among human vulnerability exploitation experts. By inputting a valid proof of concept, it first obtains the vulnerability triggering constraints of the target program, then searches for the hidden output function to leak information, and generates a final exploit that can be used to bypass ASLR. We argue that this automatic evaluation approach can reduce the reliance on manual work of ASLR-related exploits, and improves the vulnerability assessment mechanism significantly. We evaluated our approach against three CTF binary programs, and the results show that it can assess the exploitability of the vulnerability with the ASLR enabled in seconds.

To cope with ever-increasing design complexities, integrated circuit designers increase both the size of their design teams and their reliance on third-party intellectual property (IP). Both come at the expense of trust: it is computationally infeasible to exhaustively verify that a design is free of all possible malicious modifications (i.e., hardware Trojans). Making matters worse, unlike software, hardware modifications are permanent: there is no "patching" mechanism for hardware; and powerful: they serve as a foothold for subverting software that sits above.To counter this threat, prior work uses both static and dynamic analysis techniques to verify hardware designs are Trojan-free. Unfortunately, researchers continue to reveal weaknesses in these "one-size-fits-all", heuristic-based approaches. Instead of attempting to detect all possible hardware Trojans, we take the first step in addressing the hardware Trojan threat in a divide-and-conquer fashion: defining and eliminating Ticking Timebomb Trojans (TTTs), forcing attackers to implement larger Trojan designs detectable via existing verification and side-channel defenses. Like many system-level software defenses (e.g., Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP)), our goal is to systematically constrict the hardware attacker’s design space.First, we construct a definition of TTTs derived from their functional behavior. Next, we translate this definition into fundamental components required to realize TTT behavior in hardware. Using these components, we expand the set of all known TTTs to a total of six variants—including unseen variants. Leveraging our definition, we design and implement a TTT-specific dynamic verification toolchain extension, called Bomber-man. Using four real-world hardware designs, we demonstrate Bomberman’s ability to detect all TTT variants, where previous defenses fail, with

Security measurement helps identify deployment gaps and present extremely valuable research opportunities. However, such research is often deemed as not novelty by academia. I will first share my research journey designing and producing a high-precision tool CryptoGuard for scanning cryptographic vulnerabilities in large Java projects. That work led us to publish two benchmarks used for systematically assessing state-of-the-art academic and commercial solutions, as well as help Oracle Labs integrate our detection in their routine scanning. Other specific measurement and deployment cases to discuss include the Payment Card Industry Data Security Standard, which was involved in high-profile data breach incidents, and fine-grained Address Space Layout Randomization (ASLR). The talk will also point out the need for measurement in AI development in the context of code repair. Broadening research styles by accepting and encouraging deployment-related work will facilitate our field to progress towards maturity.

Address Space Layout Randomization (ASLR) is de-facto standard exploit mitigation in our daily life software. The simplest idea of unpredictably randomizing memory layout significantly raises the bar for memory exploitation due to the additionally required attack primitives such as information leakage. Ironically, although exceptional, there are rare edge cases where ASLR becomes handy for memory exploitation. In this paper, we dig into such theoretical set of cases and name it as BadASLR. To evaluate if BadASLR can be an actual plausible scenario, we look into real-world bug bounty cases, CTF/wargame challenges. Surprisingly, we found multiple vulnerabilities in commercial software where ASLR becomes handy for attacker. With BadASLR cases, we succeeded in exploiting peculiar vulnerabilities, and received total 10,000 USD as bug bounty reward including one CVE assignment.

Just-in-time return-oriented programming (JIT-ROP) allows one to dynamically discover instruction pages and launch code reuse attacks, effectively bypassing most fine-grained address space layout randomization (ASLR) protection. However, in-depth questions regarding the impact of code (re-)randomization on code reuse attacks have not been studied. For example, how would one compute the re-randomization interval effectively by considering the speed of gadget convergence to defeat JIT-ROP attacks? ; how do starting pointers in JIT-ROP impact gadget availability and gadget convergence time? ; what impact do fine-grained code randomizations have on the Turing-complete expressive power of JIT-ROP payloads? We conduct a comprehensive measurement study on the effectiveness of fine-grained code randomization schemes, with 5 tools, 20 applications including 6 browsers, 1 browser engine, and 25 dynamic libraries. We provide methodologies to measure JIT-ROP gadget availability, quality, and their Turing-complete expressiveness, as well as to empirically determine the upper bound of re-randomization intervals in re-randomization schemes using the Turing-complete (TC), priority, MOV TC, and payload gadget sets. Experiments show that the upper bound ranges from 1.5 to 3.5 seconds in our tested applications. Besides, our results show that locations of leaked pointers used in JIT-ROP attacks have no impacts on gadget availability but have an impact on how fast attackers find gadgets. Our results also show that instruction-level single-round randomization thwarts current gadget finding techniques under the JIT-ROP threat model.

The sophistication and complexity of recent exploitation techniques, which rely on memory disclosure and whole-function reuse to bypass address space layout randomization and control flow integrity, is indicative of the effect that the combination of exploit mitigations has in challenging the construction of reliable exploits. In addition to software diversification and control flow enforcement, recent efforts have focused on the complementary approach of code and API specialization to restrict further the critical operations that an attacker can perform as part of a code reuse exploit. In this paper we propose Saffire , a compiler-level defense against code reuse attacks. For each calling context of a critical function, Saffire creates a specialized and hardened replica of the function with a restricted interface that can accommodate only that particular invocation. This is achieved by applying static argument binding , to eliminate arguments with static values and concretize them within the function body, and dynamic argument binding , which applies a narrow-scope form of data flow integrity to restrict the acceptable values of arguments that cannot be statically derived. We have implemented Saffire on top of LLVM, and applied it to a set of 11 applications, including Nginx, Firefox, and Chrome. The results of our experimental evaluation with a set of 17 real-world ROP exploits and three whole-function reuse exploits demonstrate the effectiveness of Saffire in preventing these attacks while incurring a negligible runtime overhead.

Memory errors are still a serious threat affecting millions of devices worldwide. Recently, bounty programs have reached a new record, paying up to USD 2.5 million for one single vulnerability in Android and up to USD 2 million for Apple’s operating system. In almost all cases, it is common to exploit memory errors in one or more stages to fully compromise those devices. In this paper, we review and discuss the importance of memory error vulnerabilities, and more specifically stack buffer overflows to provide a full view of how memory errors are exploited. We identify the root causes that make those attacks possible on modern x86-64 architecture in the presence of modern protection techniques. We have analyzed how unsafe library functions are prone to buffer overflows, revealing that although there are secure versions of those functions, they are not actually preventing buffer overflows from happening. Using secure functions does not result in software free from vulnerabilities and it requires developers to be security-aware. To overcome this problem, we discuss the three main security protection techniques present in all modern operating system; the non-eXecutable bit (NX), the Stack Smashing Protector (SSP) and the Address Space Layout Randomization (ASLR). After discussing their effectiveness, we conclude that although they provide a strong level of protection against classical exploitation techniques, modern attacks can bypass them.

Defense techniques such as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) were role models in preventing early return-oriented programming (ROP) attacks by keeping performance and scalability in the forefront, making them widely-adopted. As code reuse attacks evolved in complexity, defenses have lost touch with pragmatic defense design to ensure security, either being narrow in scope or providing unrealistic overheads. We present MARDU, an on-demand system-wide re-randomization technique that maintains strong security guarantees while providing better overall performance and having scalability most defenses lack. We achieve code sharing with diversification by implementing reactive and scalable, rather than continuous or one-time diversification. Enabling code sharing further minimizes needed tracking, patching, and memory overheads. The evaluation of MARDU shows low performance overhead of 5.5% on SPEC and minimal degradation of 4.4% in NGINX, proving its applicability to both compute-intensive and scalable real-world applications.

Nowadays, various computing services are often hosted on cloud platforms for their availability and cost effectiveness. However, such services are frequently exposed to vulnerabilities. Therefore, many countermeasures have been invented to defend against software hacking. At the same time, more complicated attacking techniques have been created. Among them, code-reuse attacks are still an effective means of abusing software vulnerabilities. Although state-of-the-art address space layout randomization (ASLR) runtime-based solutions provide a robust way to mitigate code-reuse attacks, they have fundamental limitations; for example, the need for system modifications, and the need for recompiling source codes or restarting processes. These limitations are not appropriate for mission-critical services because a seamless operation is very important. In this paper, we propose a novel ASLR technique to provide memory rerandomization without interrupting the process execution. In addition, we describe its implementation and evaluate the results. In summary, our method provides a lightweight and seamless ASLR for critical service applications.

[EN] Cloud computing has completely changed our lives. This technology dramatically impacted on how we play, work and live. It has been widely adopted in many sectors mainly because it reduces the cost of performing tasks in a flexible, scalable and reliable way. To provide a secure cloud computing architecture, the highest possible level of protection must be applied. Unfortunately, the cloud computing paradigm introduces new scenarios where security protection techniques are weakened or disabled to obtain a better performance and resources exploitation. Kernel ASLR (KASLR) is a widely adopted protection technique present in all modern operating systems. KASLR is a very effective technique that thwarts unknown attacks but unfortunately its randomness have a significant impact on memory deduplication savings. Both techniques are very desired by the industry, the first one because of the high level of security that it provides and the latter to obtain better performance and resources exploitation. In this paper, we propose KASLR-MT, a new Linux kernel randomization approach compatible with memory deduplication. We identify why the most widely and effective technique used to mitigate attacks at kernel level, KASLR, fails to provide protection and shareability at the same time. We analyze the current Linux kernel randomization and how it affects to the shared memory of each kernel region. Then, based on the analysis, we propose KASLR-MT, the first effective and practical Kernel ASLR memory protection that maximizes the memory deduplication savings rate while providing a strong security. Our tests reveal that KASLR-MT is not intrusive, very scalable and provides strong protection without sacrificing the shareability. (C) 2019 Elsevier Inc. All rights reserved.

Kernel Address Space Layout Randomization (KASLR) has been repeatedly targeted by side-channel attacks that exploit a typical unified user/kernel address space organization to disclose randomized kernel addresses. The community has responded with kernel address space isolation techniques that separate user and kernel address spaces (and associated resources) to eradicate all existing side-channel attacks. In this paper, we show that kernel address space isolation is insufficient to harden KASLR against practical side-channel attacks on modern tagged TLB architectures. While tagged TLBs have been praised for optimizing the performance of kernel address space isolation, we show that they also silently break its original security guarantees and open up opportunities for new derandomization attacks. As a concrete demonstration, we present TagBleed, a new side-channel attack that abuses tagged TLBs and residual translation information to break KASLR even in the face of state-of-The-Art mitigations. TagBleed is practical and shows that implementing secure address space isolation requires deep partitioning of microarchitectural resources and a more generous performance budget than previously assumed.

Address Space Layout Randomization (ASLR) is de-facto standard exploit mitigation in our daily life software. The simplest idea of unpredictably randomizing memory layout significantly raises the bar for memory exploitation due to the additionally required attack primitives such as information leakage. Ironically, although exceptional, there are rare edge cases where ASLR becomes handy for memory exploitation. In this paper, we dig into such theoretical set of cases and name it as BadASLR. Based on our study, we introduce four categories of BadASLR: (i) aiding free chunk reclamation in heap spraying attack, (ii) aiding stack pivoting in frame-pointer null poisoning attack, (iii) reviving the exploitability of invalid pointer referencing bug, and (iv) introducing wild-card ROP gadgets in x86/x64 position independent code environment. To evaluate if BadASLR can be an actual plausible scenario, we look into real-world bug bounty cases, CTF/wargame challenges. Surprisingly, we found multiple vulnerabilities in commercial software where ASLR becomes handy for attacker. With BadASLR cases, we succeeded in exploiting peculiar vulnerabilities, and received total 10,000 USD as bug bounty reward including one CVE assignment.

Software vulnerabilities are a serious security threat. It is important to develop protection mechanisms preventing their exploitation, especially with a rapid increase of ROP attacks. State of the art protection mechanisms have some drawbacks that can be used by attackers. In this paper, we propose fine-grained address space layout randomization on program load that is able to protect from such kind of attacks. During the static linking stage, the executable and library files are supplemented with information about function boundaries and relocations. A system dynamic linker/loader uses this information to perform permutation of functions. The proposed method was implemented for 64-bit programs on CentOS 7 operating system. The implemented method has shown good resistance to ROP attacks evaluated by two metrics: the number of survived gadgets and the exploitability estimation of ROP chain examples. The implementation presented in this article is applicable across the entire operating system and has no compatibility problems affecting the program performance. The working capacity of proposed approach was demonstrated on real programs. The further research can cover forking randomization and finer granularity than on the function level. It also makes sense to implement the randomization of short functions placement taking into account the relationships between them. The close arrangement of functions that often call each other can improve the performance of individual programs.

Identification of operating system kernel version is essential in a large number of forensic and security applications in both cloud and local environments. Prior state-of-the-art uses complex differential analysis of several aspects of kernel implementation and knowledge of kernel data structures. In this paper, we present a working research prototype codeid-elf for ELF binaries based on its Windows counterpart codeid, which can identify kernels through relocation entries extracted from the binaries. We show that relocation-based signatures are unique and distinct and thus, can be used to accurately determine Linux kernel versions and derandomize the base address of the kernel in memory (when kernel Address Space Layout Randomization is enabled). We evaluate the effectiveness of codeid-elf on a subset of Linux kernels and find that the relocations in kernel code have nearly 100% code coverage and low similarity (uniqueness) across various kernels. Finally, we show that codeid-elf, which leverages relocations in kernel code, can detect all kernel versions in the test set with almost 100% page hit rate and nearly zero false negatives.

Address space layout randomization (ASLR) is now widely adopted in modern operating systems to thwart code reuse attacks. However, an adversary can still bypass fine-grained ASLR by exploiting memory corruption vulnerabilities and performing memory disclosure attacks. Although Execute-no-Read schemes have been proven to be an efficient solution against read-based memory disclosures, existing solutions need modifications to kernel or hypervisor. Besides, the defense of execution-based memory disclosures has been ignored. In this paper, we propose BoundShield, a self-protection scheme that provides comprehensive protection against memory disclosure attacks, especially against those based on executing arbitrary code by leveraging Intel Memory Protection Extension . BoundShield protects code memory by defending not only read-based memory disclosure attacks but also execution-based memory disclosure attacks. On one hand, read-based memory disclosures can be eliminated by hiding all code sections and code pointers in a secret region separated from the user address space. On the other hand, BoundShield prevents return addresses from being corrupted and ensures that all function pointers point to the legitimate entries whenever they are dereferenced, which significantly reduces the attack surface for execution-based memory disclosures. We have implemented a prototype of BoundShield based on a set of modifications to compiler toolchain and the standard C library. Our evaluation results show that the BoundShield can provide strong defenses against memory disclosure attacks while incurring a small performance overhead.

Recent operating systems (OSs) have adopted a defense mechanism called kernel page table isolation (KPTI) for protecting the kernel from all attacks that break the kernel address space layout randomization (KASLR) using various side-channel analysis techniques. In this paper, we demonstrate that KASLR can still be broken, even with the latest OSs where KPTI is applied. In particular, we present a novel memory-sharing-based side-channel attack that breaks the KASLR on KPTI-enabled Linux virtual machines. The proposed attack leverages the memory deduplication feature on a hypervisor, which provides a timing channel for inferring secret information regarding the victim. By conducting experiments on KVM and VMware ESXi, we show that the proposed attack can obtain the kernel address within a short amount of time. We also present several countermeasures that can prevent such an attack.

Recent code reuse attacks are able to circumvent various address space layout randomization (ASLR) techniques by exploiting memory disclosure vulnerabilities. To mitigate sophisticated code reuse attacks, we proposed a light-weight virtual machine, ReRanz, which deployed a novel continuous binary code re-randomization to mitigate memory disclosure oriented attacks. In order to meet security and performance goals, costly code randomization operations were outsourced to a separate process, called the "shuffling process". The shuffling process continuously flushed the old code and replaced it with a fine-grained randomized code variant. ReRanz repeated the process each time an adversary might obtain the information and upload a payload. Our performance evaluation shows that ReRanz Virtual Machine incurs a very low performance overhead. The security evaluation shows that ReRanz successfully protect the Nginx web server against the Blind-ROP attack.

We present a novel approach to automatically recover information about the address space layout of remote processes in the presence of Address Space Layout Randomization (ASLR). Our system, dubbed Sleak, performs static analysis and symbolic execution of binary executable programs, and identifies program paths and input parameters leading to partial (i.e., only a few bits) or complete (i.e., the whole address) information disclosure vulnerabilities, revealing addresses of known objects of the target service or application. Sleak takes, as input, the binary executable program, and generates a symbolic expression for each program output that leaks information about the addresses of objects, such as stack variables, heap structures, or function pointers. By comparing these expressions with the concrete output of a remote process executing the same binary program image, our system is able to recover from a few bits to whole addresses of objects of the target application or service. Discovering the address of a single object in the target application is often enough to guess the layout of entire sections of the address space, which can be leveraged by attackers to bypass ASLR.

The use of uninitialized variables is a common issue. It could cause kernel information leak, which defeats the widely deployed security defense, i.e., kernel address space layout randomization (KASLR). Though a recent system called Bochspwn Reloaded reported multiple memory leaks in Windows kernels, how to effectively detect this issue is still largely behind. In this paper, we propose a new technique, i.e., differential replay, that could effectively detect the use of uninitialized variables. Specifically, it records and replays a program's execution in multiple instances. One instance is with the vanilla memory, the other one changes (or poisons) values of variables allocated from the stack and the heap. Then it compares program states to find references to uninitialized variables. The idea is that if a variable is properly initialized, it will overwrite the poisoned value and program states in two running instances should be the same. After detecting the differences, our system leverages the symbolic taint analysis to further identify the location where the variable was allocated. This helps us to identify the root cause and facilitate the development of real exploits. We have implemented a prototype called TimePlayer. After applying it to both Windows 7 and Windows 10 kernels (x86/x64), it successfully identified 34 new issues and another 85 ones that had been patched (some of them were publicly unknown.) Among 34 new issues, 17 of them have been confirmed as zero-day vulnerabilities by Microsoft.

With the structure of deep neural networks (DNN) being of increasing commercial value, DNN reverse engineering attacks have become a great security concern. It has been shown that the memory access pattern of a processor running DNNs can be exploited to decipher their detailed structure. In this work, we propose a defensive memory access mechanism which utilizes oblivious shuffle, address space layout randomization, and dummy memory accesses to counter such attacks. Experiments show that our defense exponentially increases the attack complexity with asymptotically lower memory access overhead compared to generic memory obfuscation techniques such as ORAM and is scalable to larger DNNs.

At present, the network architecture is based on the TCP/IP protocol and node communications are achieved by the IP address and identifier of the node. The IP address in the network remains basically unchanged, so it is more likely to be attacked by network intruder. To this end, it is important to make periodic dynamic hopping in a specific address space possible, so that an intruder fails to obtain the internal network address and grid topological structure in real time and to continue to perform infiltration by the building of a new address space layout randomization system on the basis of SDN from the perspective of an attacker.

Kernel vulnerability attacks may allow attackers to execute arbitrary program code and achieve privilege escalation through credential overwriting, thereby avoiding security features. Major Linux protection methods include Kernel Address Space Layout Randomization, Control Flow Integrity, and Kernel Page Table Isolation. All of these mitigate kernel vulnerability affects and actual attacks. In addition, the No eXecute bit, Supervisor Mode Access Prevention, and Supervisor Mode Execution Prevention are CPU features for managing access permission and data execution in virtual memory. Although combinations of these methods can reduce the attack availability of kernel vulnerability based on the interaction between the user and kernel modes, kernel virtual memory corruption is still possible (e.g., the eBPF vulnerability executes the attack code only in the kernel mode).

Cloud computing dramatically impacted the way we play, work and live. It has been widely adopted in many sectors mainly because it reduces the cost of performing tasks in a flexible, scalable and reliable way. The highest possible level of protection must be applied in order to provide a secure cloud computing architecture. Unfortunately, the cloud computing paradigm introduces new scenarios where security protection techniques are weakened or disabled to obtain better performance and resources exploitation. An important case is the memory deduplication mechanism which is canceled by the address space layout randomization (ASLR) protection technique. In this paper, we present a precise analysis of the impact on the memory deduplication technique when kernel randomization is enabled. Our experiments show that the memory overhead to run 24 kernels is increased by 534% (from 613 MiB to 3.9 GiB) when kernel ASLR is enabled.

Buffer overflow vulnerabilities are widely found in software. Finding these vulnerabilities and identifying whether these vulnerabilities can be exploit is very important. However, it is not easy to find all of the buffer overflow vulnerabilities in software programs, and it is more difficult to find and exploit these vulnerabilities in binary programs. This paper proposes a method and a corresponding tool that automatically finds buffer overflow vulnerabilities in binary programs, and then automatically generate exploit for the vulnerability. The tool uses symbolic execution to search the target software and find potential buffer overflow vulnerabilities, then try to bypass system protection by choosing different exploiting method according to the different level of protections. Finally, the exploit of software vulnerability is generated using constraint solver. The method and tool can automatically find vulnerabilities and generate exploits for three kinds of protection: without system protection, with address space layout randomization protection, and with stack non-executable protection.

Despite decades of research on software diversification, only address space layout randomization has seen widespread adoption. Code randomization, an effective defense against return-oriented programming exploits, has remained an academic exercise mainly due to i) the lack of a transparent and streamlined deployment model that does not disrupt existing software distribution norms, and ii) the inherent incompatibility of program variants with error reporting, whitelisting, patching, and other operations that rely on code uniformity. In this work we present compiler-assisted code randomization (CCR), a hybrid approach that relies on compiler–rewriter cooperation to enable fast and robust fine-grained code randomization on end-user systems, while maintaining compatibility with existing software distribution models. The main concept behind CCR is to augment binaries with a minimal set of transformation-assisting metadata, which i) facilitate rapid fine-grained code transformation at installation or load time, and ii) form the basis for reversing any applied code transformation when needed, to maintain compatibility with existing mechanisms that rely on referencing the original code. We have implemented a prototype of this approach by extending the LLVM compiler toolchain, and developing a simple binary rewriter that leverages the embedded metadata to generate randomized variants using basic block reordering. The results of our experimental evaluation demonstrate the feasibility and practicality of CCR, as on average it incurs a modest file size increase of 11.46% and a negligible runtime overhead of 0.28%, while it is compatible with link-time optimization and control flow integrity.

Control-hijacking attacks include code injection attacks and code reuse attacks. In recent years, with the emergence of the defense mechanism data-execution prevention(DEP), code reuse attacks have become mainstream, such as return-oriented programming(ROP), Jump-Oriented Programming(JOP), and Counterfeit Object-oriented Programming(COOP). And a series of defensive measures have been proposed, such as DEP, address space layout randomization (ASLR), coarse-grained Control-Flow Integrity(CFI) and fine-grained CFI. In this paper, we propose a new attack called function-oriented programming(FOP) to construct malicious program behavior. FOP takes advantage of the existing function of the C program to induce attack. We propose concrete algorithms for FOP gadgets and build a tool to identify FOP gadgets. FOP can successfully bypass coarse-grained CFI, and FOP also can bypass some existing fine-grained CFI technologies, such as shadow stack technology. We show a real-world attack for proftpd1.3.0 server in the Linux x64 environment. We believe that the FOP attack will encourage people to come up with more effective defense measures.

Memory corruption vulnerabilities are a common problem in software implemented in C/C++. Attackers can exploit these vulnerabilities to steal sensitive data and to seize or disrupt the system on which the software is executed. Memory safety techniques can, in principle, eliminate these vulnerabilities [Nagarakatte et al. 2009, Nagarakatte et al. 2010] but are prohibitively expensive in terms of runtime overhead [Szekeres et al. 2013]. Instead, modern operating systems and compilers deploy exploit mitigations such as Address Space Layout Randomization (ASLR) [PaX Team 2004a], Data Execution Prevention (DEP, a.k.a.W.X) [PaX Team 2004b], and stack canaries [Cowan et al. 1998]. These exploit mitigations incur minimal performance overhead, but are limited in scope.often only defending against one particular type of exploit.and can be bypassed with only modest effort. Up-and-coming exploit mitigations, such as control-flow integrity [Abadi et al. 2005a, Tice et al. 2014], require more effort to bypass [Goktas et al. 2014a, Davi et al. 2014, Carlini et al. 2015e, Evans et al. 2015, Schuster et al. 2015], but, similar to the aforementioned defenses, they defend only against attacks of one particular type: code reuse. The ubiquity of multi-core processors has made Multi-Variant Execution Environments (MVEEs) an increasingly attractive option to provide strong, comprehensive protection against memory corruption exploits, while still incurring only a fraction of the runtime overhead of full memory safety. MVEEs have been shown to successfully defend against several types of attacks, including code reuse [Volckaert et al. 2015], information leakage [Koning et al. 2016], stack buffer overflows [Salamat et al. 2009], and code injection [Cox et al. 2006]. The underlying idea is to run several diversified instances of the same program, often referred to as variants or replicas, side by side on equivalent program inputs. The MVEE's main component, the monitor, feeds all variants these equivalent inputs and monitors the variants' behavior. The diversity techniques used to generate the variants ensure that the variants respond differently to malicious inputs, while leaving the behavior under normal operating conditions unaffected. The MVEE monitor detects the diverging behavior and halts the execution of the variants before they can harm the system. This implies that the variants must, to some extent, be executed in lockstep: potentially harmful operations in a variant are only executed when the consistency with the other variants has been validated. In recent years, over half a dozen systems have been proposed that match the above description. While most of them show many similarities, some authors have made radically different design choices. In this chapter, we discuss the design of MVEEs and provide implementation details about our own MVEE, the Ghent University Multi-Variant Execution Environment, orGHUMVEE, and its extensions. GHUMVEEhas been open sourced and can be downloaded from http://github.com/ stijn-volckaert/ReMon/.

Almost three decades ago, the Morris Worm infected thousands of UNIX workstations by, among other things, exploiting a buffer-overflow error in the fingerd daemon [Spafford 1989]. Buffer overflows are just one example of a larger class of memory (corruption) errors [Szekeres et al. 2013, van der Veen et al. 2012]. The root of the issue is that systems programming languages---C and its derivatives---expect programmers to access memory correctly and eschew runtime safety checks to maximize performance. There are three possible ways to address the security issues associated with memory corruption. One is to migrate away from these legacy languages that were designed four decades ago, long before computers were networked and thus exposed to remote adversaries. Another is to retrofit the legacy code with runtime safety checks. This is a great option whenever the, often substantial, cost of runtime checking is acceptable. In cases where legacy code must run at approximately the same speed, however, we must fall back to targeted mitigations, which, unlike the other remedies, do not prevent memory corruption. Instead, mitigations make it harder, i.e., more labor intensive, to turn errors into exploits. Since stack-based buffer overwrites were the basis of the first exploits, the first mitigations were focused on preventing the corresponding stack smashing exploits [Levy 1996]. The first mitigations worked by placing a canary, i.e., a random value checked before function returns, between the return address and any buffers that could overflow [Cowan et al. 1998]. Another countermeasure that is now ubiquitous makes the stack non-executable. Since then, numerous other countermeasures have appeared and the most efficient of those have made it into practice [Meer 2010]. While the common goal of countermeasures is to stop exploitation of memory corruption, their mechanisms differ widely. Generally speaking, countermeasures rely on randomization, enforcement, isolation, or a combination thereof. Address space layout randomization is the canonical example of a purely randomization-based technique. Control-Flow Integrity (CFI [Abadi et al. 2005a, Burow et al. 2016]) is a good example of an enforcement technique. Software-fault isolation, as the name implies, is a good example of an isolation scheme. Code- Pointer Integrity (CPI [Kuznetsov et al. 2014a]) is an isolation scheme focused on code pointers. While the rest of this chapter focuses on randomization-based mitigations, we stress that the best way to mitigate memory corruption vulnerabilities is to deploy multiple different mitigation techniques, as opposed to being overly reliant on any single defense.

Return-oriented programming (ROP) and jump-oriented programming (JOP) are two most common control-flow hijacking attacks. Existing defenses, such as address space layout randomization (ASLR) and control flow integrity (CFI) either are bypassed by information leakage or result in high runtime overhead. In this paper, we propose FRProtector, an effective way to mitigate these two control-flow hijacking attacks. FRProtector shuffles the functions of a given program and ensures each function is executed from the entry block by comparing the unique label for it at ret and indirect jmp. The unique label is generated by XORing the stack frame with return address instead of with a random value and it is saved in a register rather than on the stack. We implement FRProtector on LLVM 3.9 and perform extensive experiments to show FRProtector only adds on average 2% runtime overhead and 2.2% space overhead on SPEC CPU2006 benchmark programs. Our security analysis on RIPE benchmark confirms that FRProtector is effective in defending control-flow hijacking attacks.

Runtime Intrusion Prevention Evaluator (RIPE), published in 2011, is a benchmark suite for evaluating mitigation techniques against 850 attack patterns using only buffer overflow. Since RIPE is built as a single process, defense and attack routines cannot help sharing process states and address space layouts when RIPE is tested. As a result, attack routines can access the memory space for defense routines without restriction. We separate RIPE into two independent processes of defense and attacks so that mitigations based on confidentiality such as address space layout randomization are properly evaluated. In addition, we add an execution mode to test robustness against brute force attacks. Finally, we extend RIPE by adding 38 attack forms to perform format string attacks and virtual table (vtable) hijacking attacks. The revised RIPE contributes to the diversification of attack patterns and precise evaluation of the effectiveness of mitigations.

Memory corruptions are still the most prominent venue to attack otherwise secure programs. In order to make exploitation of software bugs more difficult, defenders introduced a vast number of post corruption security mitigations, such as w⊕x memory, Stack Canaries, and Address Space Layout Randomization (ASLR), to only name a few. In the following, we describe the Wiederganger1-Attack, a new attack vector that reliably allows to escalate unbounded array access vulnerabilities occurring in specifically allocated memory regions to full code execution on programs running on i386/x86_64 Linux.Wiederganger-attacks abuse determinism in Linux ASLR implementation combined with the fact that (even with protection mechanisms such as relro and glibc's pointer mangling enabled) there exist easy-to-hijack, writable (function) pointers in application memory. To discover such pointers, we use taint analysis and backwards slicing at the binary level and calculate an over-approximation of vulnerable instruction sequences.To show the relevance of Wiederganger, we exploit one of the discovered instruction sequences to perform an attack on Debian 10 (Buster) by overwriting structures used by the dynamic loader (dl) that are present in any application with glibc and the dynamic loader as dependency. In order to show generality, we solely focus on data structures dispatched at program shutdown, as this is a point that arguably all applications eventually have to reach. This results in a reliable compromise that effectively bypasses all protection mechanisms deployed on x86_64/i386 Linux to date.We believe Wiederganger to be part of an under-researched type of control flow hijacking attacks targeting internal control structures of the dynamic loader for which we propose to use the terminology Loader Oriented Programming (LOP).

This paper examines the security provided by different implementations of Address Space Layout Randomization (ASLR). ASLR is a security mechanism that increases control-flow integrity by making it more difficult for an attacker to properly execute a buffer-overflow attack, even in systems with vulnerable software. The strength of ASLR lies in the randomness of the offsets it produces in memory layouts. We compare multiple operating systems, each compiled for two different hardware architectures, and measure the amount of entropy provided to a vulnerable application. Our paper is the first publication that we are aware of that quantitatively compares the entropy of different ASLR implementations. In addition, we provide a method for remotely assessing the efficacy of a particular security feature on systems that are otherwise unavailable for analysis, and highlight the need for independent evaluation of security mechanisms.

Many modern defenses rely on address space layout randomization (ASLR) to efficiently hide security-sensitive metadata in the address space. Absent implementation flaws, an attacker can only bypass such defenses by repeatedly probing the address space for mapped (security-sensitive) regions, incurring a noisy application crash on any wrong guess. Recent work shows that modern applications contain idioms that allow the construction of crash-resistant code primitives, allowing an attacker to efficiently probe the address space without causing any visible crash. In this paper, we classify different crash-resistant primitives and show that this problem is much more prominent than previously assumed. More specifically, we show that rather than relying on labor-intensive source code inspection to find a few 'hidden' application-specific primitives, an attacker can find such primitives semi-automatically, on many classes of real-world programs, at the binary level. To support our claims, we develop methods to locate such primitives in real-world binaries. We successfully identified 29 new potential primitives and constructed proof-of-concept exploits for four of them.

Code reuse attacks exploiting memory disclosure vulnerabilities can bypass all deployed mitigations. One promising defense against this class of attacks is to enable execute-only memory (XOM) protection on top of fine-grained address space layout randomization (ASLR). However, recent works implementing XOM, despite their efficacy, only protect programs that have been (re)built with new compiler support, leaving commercial-off-the-shelf (COTS) binaries and source-unavailable programs unprotected. We present the design and implementation of NORAX, a practical system that retrofits XOM into stripped COTS binaries on AArch64 platforms. Unlike previous techniques, NORAX requires neither source code nor debugging symbols. NORAX statically transforms existing binaries so that during runtime their code sections can be loaded into XOM memory pages with embedded data relocated and data references properly updated. NORAX allows transformed binaries to leverage the new hardware-based XOM support—a feature widely available on AArch64 platforms (e.g., recent mobile devices) yet virtually unused due to the incompatibility of existing binaries. Furthermore, NORAX is designed to co-exist with other COTS binary hardening techniques, such as in-place randomization (IPR). We apply NORAX to the commonly used Android system binaries running on SAMSUNG Galaxy S6 and LG Nexus 5X devices. The results show that NORAX on average slows down the execution of transformed binaries by 1.18% and increases their memory footprint by 2.21%, suggesting NORAX is practical for real-world adoption.

Heap exploits are one of the most advanced, complex and frequent types of attack. Over the years, many effective techniques have been developed to mitigate them, such as data execution prevention, address space layout randomization and canaries. However, if both knowledge and control of the memory allocation are available, heap spraying and other attacks are still feasible. This paper presents HAIT, a memory profiler that records critical operations on the heap and shows them graphically in a clear and comprehensible format. A prototype was implemented on top of Triton, a framework for dynamic binary analysis. The experimental evaluation demonstrates that HAIT can help identifying the essential information needed to carry out heap exploits, providing valuable knowledge for an effective attack.