The open-source nature of the Android Open Source Project (AOSP) allows Original Equipment Manufacturers (OEMs) to customize the Android operating system, contributing to what is known as Android fragmentation. Google has implemented the Compatibility Definition Document (CDD) and the Compatibility Test Suite (CTS) to ensure the integrity and security of the Android ecosystem. However, the effectiveness of these policies and measures in warranting OEM compliance remains uncertain. This paper empirically studies for the first time the nature of OEM customizations in the Android TLS protocol stack, and their security implications on user-installed mobile apps across thousands of Android models. We find that approximately 80% of the analyzed Android models deviate from the standard AOSP TLS codebase and that OEM customizations often involve code changes in functions used by app developers for enhancing TLS security like end-point and certificate verification. Our analysis suggests that these customizations are likely influenced by factors such as manufacturers’ supply chain dynamics and patching prioritization tactics, including the need to support legacy components. We conclude by identifying potential root causes and emphasizing the need for stricter policy enforcement, better supply chain controls, and improved patching processes across the ecosystem.

Android implements a permission system to regulate apps' access to system resources and sensitive user data. One salient feature of this system is its extensibility: apps can define their own custom permissions to expose features and data to other apps. However, little is known about how widespread the usage of custom permissions is, and what is the impact that these permissions can have on users' privacy and security. In this paper, we empirically study the usage of custom permissions at large scale, using a dataset of 2.2M pre-installed and app-store-downloaded apps. We find the usage of custom permissions to be widespread, and seemingly growing over time. Despite this prevalence, we find that custom permissions are virtually invisible to end users, and their purpose mostly undocumented. This lack of transparency can lead to serious security and privacy problems: we show that custom permissions can facilitate access to permission-protected system resources to apps that lack those permissions without user awareness. To detect this practice, we design and implement two static analysis tools, and highlight multiple concerning cases spotted in the wild. We conclude this study with a discussion of potential solutions to mitigate the privacy and security risks of custom permissions.

Given the widespread prevalence of vulnerabilities, remediation is a critical phase that every software project has to go through. When comparing the studies on understanding the security vulnerabilities in software, such as vulnerability discovery and patterns, there is a lack of studies on the vulnerability remediation phase. To address this, we have done a timeline analysis for 130 of the most dependent upon open source projects written in JavaScript language, hosted on GitHub to understand the nature and the lifetime of the vulnerabilities in those projects. We used a static code analyzer on 501K commits from the repositories to identify commits that introduced new vulnerabilities to the code and fixed existing vulnerabilities in the code. In 90% of the projects, we identified that a commit that fixed an existing vulnerability had introduced one or more new vulnerabilities into the code. On average, 16% of the commits intended to fix vulnerabilities have introduced one or more new vulnerabilities from the analyzed projects. We also found that 18% of the total vulnerabilities found in those projects have originated from a commit meant to fix an existing vulnerability, and 78% of those vulnerabilities could have been avoided of introduction if the developers were to use proper internal testing. Here, we demonstrate Sequza, a visualization tool to help organizations detect such instances at the earliest possible.

While there is a large body of work on understanding vulnerabilities in the wild, little has been done to understand the dynamics of the remediation phase of the development cycle. To this end, we have done a timeline analysis on 118K commits from 53 of the most used JavaScript projects from GitHub to understand the provenance and prevalence of vulnerabilities in those projects. We used a vulnerability detector (CodeQL) to filter commits that introduced vulnerabilities and the commits that fixed a prior vulnerability. We found that in 82% of the projects, a commit fixing a prior vulnerability, in turn, introduced one or more new vulnerabilities. Among those projects, on average, 18% of the commits intended to fix vulnerabilities, in turn, introduced one or more new vulnerabilities. We also found that 50% of the total vulnerabilities found in those projects originated from a commit meant to fix a prior vulnerability, and 78% of those vulnerabilities could have been avoided if they were to use proper internal testing. We provide critical insights into how proper internal testing can avoid a significant portion of vulnerabilities, increasing organizations' security posture.