Umeå University's logo

Control Flow Integrity (CFI) is a well-established mitigation against control-flow hijacking attacks arising from memory corruption vulnerabilities. Over the past two decades, numerous CFI mechanisms have been proposed and integrated into modern compilers and software ecosystems. Despite this progress, CFI remains difficult to adopt in practice, and deployment decisions, compatibility constraints, and engineering overhead strongly influence its real-world security impact. 

This dissertation investigates Control Flow Integrity from the perspective of practical adoption and deployability. Rather than treating CFI as a purely theoretical protection, it examines how CFI is selected, integrated, and maintained in real-world software systems, and why these steps often fall short of idealized designs. The dissertation is structured around four complementary studies that together trace the path from measurement to guidance, to deployment experience, and finally to automated enforcement. 

The first study presents a large-scale empirical analysis of deployed binaries to assess the current state of LLVM-CFI adoption across major software platforms. It shows that while CFI deployment is increasing in some ecosystems, it remains uneven and limited, leaving substantial portions of the attack surface unprotected. The second study addresses the lack of practical guidance for developers by introducing a systematic taxonomy that maps LLVM-CFI variants to common classes of memory corruption vulnerabilities. This taxonomy provides actionable recommendations to support incremental, informed adoption of CFI in existing codebases.

The third study examines the practical challenges of deploying CFI in a complex, production-grade runtime. Through a detailed case study of integrating LLVM-CFI into a modern Java Virtual Machine, it demonstrates that compatibility issues, manual exclusions, and maintenance effort are central obstacles to effective enforcement, even when strong CFI mechanisms are available. These findings highlight the gap between CFI as designed and CFI as deployed. 

Building on these insights, the dissertation introduces an automated framework for CFI policy generation and enforcement. By reducing manual effort and mitigating compatibility barriers, this approach enables more consistent and scalable CFI deployment across large and evolving software systems.

Overall, the dissertation shows that the effectiveness of Control Flow Integrity in practice is shaped less by the availability of CFI mechanisms than by the feasibility of adopting them. By combining empirical measurement, practical guidance, deployment experience, and automation, this work contributes toward a more realistic and actionable understanding of CFI and provides concrete support for improving its deployment in real-world software systems.

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.

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.

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.

Cryptocurrencies are gaining prominence among individuals and companies alike, resulting in the growing adoption of so-called cryptocurrency wallet applications, as these simplify transactions. These wallets are available in a myriad of different forms and specifications. All of them are susceptible to various ways the attacker can exploit the vulnerabilities and steal money from victims. Cryptocurrency wallets create a unique field as they combine features of password managers, banking applications, and the need to keep their users and their transactions anonymous. We collect the findings from previous literature to provide an overview of the different attack surfaces, possible countermeasures, and further research. Existing literature focused on one of the features mentioned before, while we considered all of them. Our systematic study shows that there is a considerable variety of attack vectors, which we have divided into six subcategories, (i) Memory and Storage, (ii) Operating Systems, (iii) Software Layer, (iv) Network Layer, (v) Blockchain Protocol, and (vi) Others. We have found a large gap between the possible countermeasures and their actual adoption. Therefore, we provide a list of possible directions for future research to tackle this gap.

Every year an increasing number of users face stalkerware on their phones [84]. Many of them are victims of intimate partner surveillance (IPS) who are unsure how to identify or remove stalkerware from their phones [49]. An intuitive approach would be to choose anti-stalkerware from the app store. However, a mismatch between user expectations and the technical capabilities can produce an illusion of security and risk compensation behavior (i.e., the Peltzmann effect). We compare users' perceptions of anti-stalkerware with the technical reality. First, we applied thematic analysis to app reviews to analyze user perceptions. Then, we performed a cognitive walkthrough of two prominent anti-stalkerware apps available on the Google Play Store and reverse-engineered them to understand their detection features. Our results suggest that users base their trust on the look and feel of the app, the number and type of alerts, and the apps' affordances. We also found that app capabilities do not correspond to the users' perceptions and expectations, impacting their practical effectiveness. We discuss different stakeholders' options to remedy these challenges and better align user perceptions with the technical reality.

Compiler-based Control-Flow Integrity (CFI) offers strong forward-edge protection but remains challenging to deploy in large C/C++ software due to visibility mismatches, type inconsistencies, and unintended behavioral failures. We present CFIghter, the first fully automated system that enables strict, type-based CFI in real-world projects by detecting, classifying, and repairing unintended policy violations exposed by the test suite. CFIghter integrates whole-program analysis with guided runtime monitoring and iteratively applies the minimal necessary adjustments to CFI enforcement only where required, stopping once all tests pass or remaining failures are deemed unresolvable.

We evaluate CFIghter on four GNU projects. It resolves all visibility-related build errors and automatically repairs 95.8% of unintended CFI violations in the large, multi-library util-linux codebase, while retaining strict enforcement at over 89% of indirect control-flow sites. Across all subjects, CFIghter preserves strict type-based CFI for the majority of the codebase without requiring manual source-code changes, relying only on automatically generated visibility adjustments and localized enforcement scopes where necessary. These results show that automated compatibility repair makes strict compiler CFI practically deployable in mature, modular C software.