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.

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.

Dynamic taint analysis (DTA) tracks how sensitive data flows through a program at runtime, enabling the detection of security violations such as information leaks and injection attacks. However, most DTA systems assume that memory layouts are type-safe and structurally consistent—an assumption that can be violated by vulnerabilities such as type confusion. While type confusion has been studied in the context of sandbox escape, its ability to silently bypass taint tracking without altering program behavior remains unexplored. In this paper, we present ConfuseTaint, a technique that leverages type confusion vulnerabilities to corrupt taint metadata without modifying program semantics or the analysis tool. ConfuseTaint uses wide memory overwrites enabled by type confusion to corrupt taint tags, breaking the assumptions of taint tracking mechanisms that rely on shadow memory.We evaluate ConfuseTaint on two widely used taint tracking frameworks: Phosphor for the JVM and TaintDroid for Android. In both cases, ConfuseTaint successfully bypasses taint tracking, allowing sensitive data to reach designated sinks without detection. These results reveal a structural weakness in current DTA designs: their reliance on type-safe memory layouts leaves them vulnerable to low-level reinterpretation. Overall, our work reveals that runtime-level memory reinterpretation is an overlooked threat, calling for taint tracking architectures that do not rely on fragile assumptions about type and memory layout.

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 ( \( \lt \) 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.

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

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.

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.

Android is present in more than 85% of mobile devices, making it a prime target for malware. Malicious code is becoming increasingly sophisticated and relies onlogic bombsto hide itself from dynamic analysis. In this article, we perform a large scale study ofTSOpen, our open-source implementation of the state-of-the-art static logic bomb scannerTriggerScope, on more than 500k Android applications. Results indicate that the approach scales. Moreover, we investigate the discrepancies and show that the approach can reach a very low false-positive rate, 0.3%, but at a particular cost, e.g., removing 90% of sensitive methods. Therefore, it might not be realistic to rely on such an approach to automatically detectalllogic bombs in large datasets. However, it could be used to speed up the location of malicious code, for instance, while reverse engineering applications. We also presentTrigDBa database of 68 Android applications containing trigger-based behavior as a ground-truth to the research community.

Inter-Component Communication (ICC) is a key mechanism in Android. It enables developers to compose rich functionalities and explore reuse within and across apps. Unfortunately, as reported by a large body of literature, ICC is rather "complex and largely unconstrained", leaving room to a lack of precision in apps modeling. To address the challenge of tracking ICCs within apps, state of the art static approaches such as EPICC, ICCTA and AMANDROID have focused on the documented framework ICC methods (e.g., startActivity) to build their approaches. In this work we show that ICC models inferred in these state of the art tools may actually be incomplete: the framework provides other atypical ways of performing ICCs. To address this limitation in the state of the art, we propose RAICC a static approach for modeling new ICC links and thus boosting previous analysis tasks such as ICC vulnerability detection, privacy leaks detection, malware detection, etc. We have evaluated RAICC on 20 benchmark apps, demonstrating that it improves the precision and recall of uncovered leaks in state of the art tools. We have also performed a large empirical investigation showing that Atypical ICC methods are largely used in Android apps, although not necessarily for data transfer. We also show that RAICC increases the number of ICC links found by 61.6% on a dataset of real-world malicious apps, and that RAICC enables the detection of new ICC vulnerabilities.

Current Java Virtual Machine (JVM) fuzzers aim at generating syntactically valid Java programs, without targeting any particular use of the standard Java library. While effective, such fuzzers fail to discover specific kinds of bugs or vulnerabilities, such as type confusion, that are related to the standard API usage. To deal with this issue, we introduce a mutation-based feedback-guided black-box JVM fuzzer, called Confuzzion. Confuzzion, as the name suggests, targets security-relevant object-oriented flaws with a particular focus on type confusion vulnerabilities. We show that in less than 4 hours, on commodity hardware and without any predefined initialization seed, Confuzzion automatically generates Java programs that reveal JVM vulnerabilities, i.e., the Common Vulnerabilities and Exposures CVE-2017-3272. We also show that state-of-the-art fuzzers or even traditional automatic testing techniques are not capable of detecting such faults, even after 48 hours of execution in the same environment. To the best of our knowledge, Confuzzion is the first fuzzer able to detect JVM type confusion vulnerabilities.

Billions of users rely on the security of the Android platform to protect phones, tablets, and many different types of consumer electronics. While Android's permission model is well studied, the enforcement of the protection policy has received relatively little attention. Much of this enforcement is spread across system services, taking the form of hard-coded checks within their implementations. In this paper, we propose Authorization Check Miner (ACMiner), a framework for evaluating the correctness of Android's access control enforcement through consistency analysis of authorization checks. ACMiner combines program and text analysis techniques to generate a rich set of authorization checks, mines the corresponding protection policy for each service entry point, and uses association rule mining at a service granularity to identify inconsistencies that may correspond to vulnerabilities. We used ACMiner to study the AOSP version of Android 7.1.1 to identify 28 vulnerabilities relating to missing authorization checks. In doing so, we demonstrate ACMiner's ability to help domain experts process thousands of authorization checks scattered across millions of lines of code.

Invalid object initialization vulnerabilities have been identified since the 1990s by a research group at Princeton University.These vulnerabilities are critical since they can be used to totally compromise the security of a Java virtual machine (JVM).Recently, such a vulnerability identified as CVE-2017-3289 has been found again in the bytecode verifier of the JVM and affects more than 40 versions of the JVM.In this paper, we present a runtime solution called MUSTI to detect and prevent attacks leveraging this kind of critical vulnerabilities.We optimize MUSTI to have a runtime overhead below 0.5% and a memory overhead below 0.42%.Compared with state of the art, MUSTI is completely automated and does not require to manually annotate the code.

When created, the Java platform was among the first runtimes designed with security in mind. Yet, numerous Java versions were shown to contain far-reaching vulnerabilities, permitting denial-of-service attacks or even worse allowing intruders to bypass the runtime's sandbox mechanisms, opening the host system up to many kinds of further attacks.

Static analysis has been successfully used in many areas, from verifying mission-critical software to malware detection. Unfortunately, static analysis often produces false positives, which require significant manual effort to resolve. In this paper, we show how to overlay a probabilistic model, trained using domain knowledge, on top of static analysis results, in order to triage static analysis results. We apply this idea to analyzing mobile applications. Android application components can communicate with each other, both within single applications and between different applications. Unfortunately, techniques to statically infer Inter-Component Communication (ICC) yield many potential inter-component and inter-application links, most of which are false positives. At large scales, scrutinizing all potential links is simply not feasible. We therefore overlay a probabilistic model of ICC on top of static analysis results. Since computing the inter-component links is a prerequisite to inter-component analysis, we introduce a formalism for inferring ICC links based on set constraints. We design an efficient algorithm for performing link resolution. We compute all potential links in a corpus of 11,267 applications in 30 minutes and triage them using our probabilistic approach. We find that over 95.1% of all 636 million potential links are associated with probability values below 0.01 and are thus likely unfeasible links. Thus, it is possible to consider only a small subset of all links without significant loss of information. This work is the first significant step in making static inter-application analysis more tractable, even at large scales.

Shake Them All is a popular "Wallpaper" application exceeding millions of downloads on Google Play. At installation, this application is given permission to (1) access the Internet (for updating wallpapers) and (2) use the device microphone (to change background following noise changes). With these permissions, the application could silently record user conversations and upload them remotely. To give more confidence about how Shake Them All actually processes what it records, it is necessary to build a precise analysis tool that tracks the flow of any sensitive data from its source point to any sink, especially if those are in different components. Since Android applications may leak private data carelessly or maliciously, we propose IccTA, a static taint analyzer to detect privacy leaks among components in Android applications. IccTA goes beyond state-of-the-art approaches by supporting inter- component detection. By propagating context information among components, IccTA improves the precision of the analysis. IccTA outperforms existing tools on two benchmarks for ICC-leak detectors: DroidBench and ICC-Bench. Moreover, our approach detects 534 ICC leaks in 108 apps from MalGenome and 2,395 ICC leaks in 337 apps in a set of 15,000 Google Play apps.

We discuss the capability of a new feature set for malware detection based on potential component leaks (PCLs). PCLs are defined as sensitive data-flows that involve Android inter-component communications. We show that PCLs are common in Android apps and that malicious applications indeed manipulate significantly more PCLs than benign apps. Then, we evaluate a machine learning-based approach relying on PCLs. Experimental validations show high performance for identifying malware, demonstrating that PCLs can be used for discriminating malicious apps from benign apps.

Today's smartphones are a ubiquitous source of private and confidential data. At the same time, smartphone users are plagued by carelessly programmed apps that leak important data by accident, and by malicious apps that exploit their given privileges to copy such data intentionally. While existing static taint-analysis approaches have the potential of detecting such data leaks ahead of time, all approaches for Android use a number of coarse-grain approximations that can yield high numbers of missed leaks and false alarms.

We present PCLeaks, a tool based on inter-component communication (ICC) vulnerabilities to perform data-flow analysis on Android applications to find potential component leaks that could potentially be exploited by other components. To evaluate our approach, we run PCLeaks on 2000 apps randomly selected from the Google Play store. PCLeaks reports 986 potential component leaks in 185 apps. For each leak reported by PCLeaks, PCLeaksValidator automatically generates an Android app which tries to exploit the leak. By manually running a subset of the generated apps, we find that 75% of the reported leaks are exploitable leaks.

A common security architecture is based on the protection of certain resources by permission checks (used e.g., in Android and Blackberry). It has some limitations, for instance, when applications are granted more permissions than they actually need, which facilitates all kinds of malicious usage (e.g., through code injection). The analysis of permission-based framework requires a precise mapping between API methods of the framework and the permissions they require. In this paper, we show that naive static analysis fails miserably when applied with off-the-shelf components on the Android framework. We then present an advanced class-hierarchy and field-sensitive set of analyses to extract this mapping. Those static analyses are capable of analyzing the Android framework. They use novel domain specific optimizations dedicated to Android.

In the permission-based security model (used e.g. in Android and Blackberry), applications can be granted more permissions than they actually need, what we call a “permission gap”. Malware can leverage the unused permissions for achieving their malicious goals, for instance using code injection. In this paper, we present an approach to detecting permission gaps using static analysis. Using our tool on a dataset of Android applications, we found out that a non negligible part of applications suffers from permission gaps, i.e. does not use all the permissions they declare.