Umeå University's logo

Fuzzing is a well-established technique for detecting bugs and vulnerabilities. With the surge of fuzzers and fuzzer platforms being developed such as AFL and OSSFuzz rises the necessity to benchmark these tools' performance. A common problem is that vulnerability benchmarks are based on bugs in old software releases. For this very reason, Magma introduced the notion of forward-porting to reintroduce vulnerable code in current software releases. While their results are promising, the state-of-the-art lacks an update on the maintainability of this approach over time. Indeed, adding the vulnerable code to a recent software version might either break its functionality or make the vulnerable code no longer reachable. We characterise the challenges with forward-porting by reassessing the portability of Magma's CVEs four years after its release and manually reintroducing the vulnerabilities in the current software versions. We find the straightforward process efficient for 17 of the 32 CVEs in our study. We further investigate why a trivial forward-porting process fails in the 15 other CVEs. This involves identifying the commits breaking the forward-porting process and reverting them in addition to the bug fix. While we manage to complete the process for nine of these CVEs, we provide an update on all 15 and explain the challenges we have been confronted with in this process. Thereby, we give the basis for future work towards a sustainable forward-ported fuzzing benchmark.

While multiple recent publications on detecting Java Deserialization Vulnerabilities highlight an increasing relevance of the topic, until now no proper benchmark has been established to evaluate the individual approaches. Hence, it has become increasingly difficult to show improvements over previous tools and trade-offs that were made. In this work, we synthesize the main challenges in gadget chain detection. More specifically, this unveils the constraints program analysis faces in the context of gadget chain detection. From there, we develop Gleipner: the first synthetic, large-scale and systematic benchmark to validate the effectiveness of algorithms for detecting gadget chains in the Java programming language. We then benchmark seven previous publications in the field using Gleipner. As a result, it shows, that (1) our benchmark provides a transparent, qualitative, and sound measurement for the maturity of gadget chain detecting tools, (2) Gleipner alleviates severe benchmarking flaws which were previously common in the field and (3) state-of-the-art tools still struggle with most challenges in gadget chain detection.

Java deserialization gadget chains are a well-researched critical software weakness. The vast majority of known gadget chains rely on gadgets from software dependencies. Furthermore, it has been shown that small code changes in dependencies have enabled these gadget chains. This makes gadget chain detection a purely reactive endeavor. Even if one dependency's deployment pipeline employs gadget chain detection, a gadget chain can still result from gadgets in other dependencies. In this work, we assess how likely small code changes are to enable a gadget chain. These changes could either be accidental or intentional as part of a supply chain attack. Specifically, we show that class serializability is a strongly fluctuating property over a dependency's evolution. Then, we investigate three change patterns by which an attacker could stealthily introduce gadgets into a dependency. We apply these patterns to 533 dependencies and run three state-of-the-art gadget chain detectors both on the original and the modified dependencies. The tools detect that applying the modification patterns can activate/inject gadget chains in 26.08% of the dependencies we selected. Finally, we verify the newly detected chains. As such, we identify dormant gadget chains in 53 dependencies that could be added through minor code modifications. This both shows that Java deserialization gadget chains are a broad liability to software and proves dormant gadget chains as a lucrative supply chain attack vector.

Memory corruption vulnerabilities remain one of the most severe threats to software security. They often allow attackers to achieve arbitrary code execution by redirecting a vulnerable program’s control flow. While Control Flow Integrity (CFI) has gained traction to mitigate this exploitation path, developers are not provided with any direction on how to apply CFI to real-world software. In this work, we establish a taxonomy mapping LLVM’s forward-edge CFI variants to memory corruption vulnerability classes, offering actionable guidance for developers seeking to deploy CFI incrementally in existing codebases. Based on the Top 10 Known Exploited Vulnerabilities (KEV) list, we identify four high-impact vulnerability categories and select one representative CVE for each. We evaluate LLVM’s CFI against each CVE and explain why CFI blocks exploitation in two cases while failing in the other two, illustrating its potential and current limitations. Our findings support informed deployment decisions and provide a foundation for improving the practical use of CFI in production systems.

Memory corruption vulnerabilities still allow compromising computers through software written in a memory-unsafe language such as C/C++. This highlights that mitigation techniques to prevent such exploitations are not all widely deployed. In this article, we introduce SeeCFI, a tool to detect the presence of a memory corruption mitigation technique called Control Flow Integrity (CFI). We leverage SeeCFI to investigate to what extent the mitigation has been deployed in complex software systems such as Android and specific Linux distributions (Ubuntu and Debian). Our results indicate that the overall adoption of CFI (forward- and backward-edge) is increasing across Android versions (∼30% in Android 13) but remains the same low (1%) throughout different Linux versions. Our tool, SeeCFI, offers the possibility to identify which binaries in a system were compiled using the CFI option. This can be deployed by external security researchers to efficiently decide which binaries to prioritize when fixing vulnerabilities and how to fix them. Therefore, SeeCFI can help to make software systems more secure.

Smartphone users rely on Apps for their daily lives but simultaneously struggle to protect their privacy and device security from potentially harmful and malicious Apps. However, scientific literature lacks in-depth studies mapping user struggles, factors undermining their efforts, and implications. We cover this gap by engaging 24 smartphone users in 44 interview sessions. We observe them performing different App acquisition and management tasks, seek explanations, and analyze collected data to make the following contributions. First, we develop a theoretical App acquisition and management model describing different phenomena involved in App acquisition and management in Android smartphones. Causal conditions of these phenomena and contexts, and intervening conditions influencing user strategies are discovered grounded in the data acquired through the interview sessions. It shows the challenges they face, the strategies they develop and use to deal with the faced challenges, and their consequences. Second, we systematically discover and relate different App acquisition and management concepts in 34 subcategories related to user struggles. None of the existing studies discovers, explains, and relates actual user behaviors involving this many factors in one place. Third, this research discovers six problems unaddressed by the literature: the usage of untrusted App repositories, mandatory and forced installations, the installation process changes, the Settings App complexities, the void contracts problem, and the psychological consequences of failure to protect privacy in Android phones. Finally, we provide general guidelines for users, App stores, developers, and regulators to assist them in enhancing privacy and security protection in the Android ecosystem.

We analyze known deserialization exploits targeting applications developed in the Java programming language. As previous research implies, fully comprehending this type of vulnerability is no easy task due to the complexity of exploitation, mostly relying on so-called gadget chains. Even considering known gadget chains, knowledge about their prerequisites is rather limited. In particular, the full range of external library versions, adding exploitable gadgets to the Java classpath was formerly only partially examined. We contribute an in-depth analysis of publicly available Java deserialization vulnerabilities. Specifically, we experimentally assess the prerequisites for exploitation, using 46 different gadget chains on 244 JDK and 5,455 Java dependency versions. Previous research only covered 19 of these gadget chains. Furthermore, we develop a command line tool, Gadgecy, for lightweight detection of whether a given Java project contains dependency combinations that enable gadget chains. Using this tool, we conduct an analysis of 2,211 projects from the Apache Distribution directory and 400 well-known Github repositories. The outcome reveals that (1) deserialization exploits apply to recent JDK and library versions, (2) these gadget chains are not being fully reported, and (3) are frequently present in popular Java projects (such as Apache Kafka or Hadoop).

This research explores integrating LLVM's Control Flow Integrity (CFI) into the OpenJDK Java Virtual Machine (JVM) to mitigate memory corruption vulnerabilities. We present a manual approach to CFI integration that offers a solution applicable to various real-world projects. Using the DaCapo benchmark suite, we conduct a thorough performance evaluation of the CFI-integrated JVM version. Our work reveals that introducing CFI results in an average performance overhead of approximately 11.5% and a 34% increase in binary size. Remarkably, we identify specific CFI subcategories that, when implemented individually, induce performance improvements for the JVM. This finding highlights CFI's potential to enhance security and performance in Java and general applications. Our research advances the understanding of CFI integration in complex software such as the JVM, shedding light on the challenges and opportunities in securing software systems against memory corruption attacks.

Android is an operating system widely deployed especially on devices such as smartphones. In this paper, we study the evolution of OpenJDK Java Class Library (JCL) versions used as the basis of the Dalvik Virtual Machine (DVM) and the Android Runtime (ART). We also identify vulnerabilities impacting OpenJDK JCL versions and analyze their impact on Android. Our results indicate that the complexity of the Android JCL code imported from OpenJDK increases because:(1) there is an increase in the number of classes imported from OpenJDK,(2) there is an increase in the fragmentation of the JCL code in Android as code is increasingly imported from multiple OpenJDK versions at the same time, and (3) there is an increase in the distance between the JCL code in Android and OpenJDK as, for instance, Android developer introduce customizations to the imported code. We also observe that most OpenJDK vulnerabilities (80%) are not impacting Android because the vulnerable classes are not imported in Android. Nevertheless, Android does import vulnerable code and little is done to patch this vulnerable code which is only” patched” when a newer version of the vulnerable code is imported. This means that the code can stay vulnerable in Android for years. Most of the vulnerabilities impacting Android (77%) have a security impact on the availability of the system. By developing a proof-of-concept, we show that OpenJDK vulnerabilities imported in Android do have a security impact. We suggest to seriously take into account public information available about OpenJDK vulnerabilities to increase the security of the Android development pipeline.

Nowadays, an increasing number of applications use deserialization. This technique, based on rebuilding the instance of objects from serialized byte streams, can be dangerous since it can open the application to attacks such as remote code execution (RCE) if the data to deserialize is originating from an untrusted source. Deserialization vulnerabilities are so critical that they are in OWASP's list of top 10 security risks for web applications. This is mainly caused by faults in the development process of applications and by flaws in their dependencies, i.e., flaws in the libraries used by these applications. No previous work has studied deserialization attacks in-depth: How are they performed? How are weaknesses introduced and patched? And for how long are vulnerabilities present in the codebase? To yield a deeper understanding of this important kind of vulnerability, we perform two main analyses: one on attack gadgets, i.e., exploitable pieces of code, present in Java libraries, and one on vulnerabilities present in Java applications. For the first analysis, we conduct an exploratory large-scale study by running 256515 experiments in which we vary the versions of libraries for each of the 19 publicly available exploits. Such attacks rely on a combination of gadgets present in one or multiple Java libraries. A gadget is a method which is using objects or fields that can be attacker-controlled. Our goal is to precisely identify library versions containing gadgets and to understand how gadgets have been introduced and how they have been patched. We observe that the modification of one innocent-looking detail in a class - such as making it public - can already introduce a gadget. Furthermore, we noticed that among the studied libraries, 37.5% are not patched, leaving gadgets available for future attacks.For the second analysis, we manually analyze 104 deserialization vulnerabilities CVEs to understand how vulnerabilities are introduced and patched in real-life Java applications. Results indicate that the vulnerabilities are not always completely patched or that a workaround solution is proposed. With a workaround solution, applications are still vulnerable since the code itself is unchanged.