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.

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.

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.