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.

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).

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.