A Risk Estimation Study of Native Code Vulnerabilities in Android Applications

TL;DR

Android apps frequently integrate native C/C++ libraries via the NDK, exposing a security risk that is difficult to quantify at release time. The authors introduce a fast, risk-based approach that combines lightweight library-version and vulnerable-function detection with a locally built CVE database and a CVSS-informed scoring scheme to produce app-level risk estimates. They validate the method on about $100{,}000$ APKs (with ~40% containing native code) across $15$ popular native libraries, showing meaningful exposure to known CVEs and actionable risk signals for developers. The approach supports rapid pre-release assessments and SBOM-aligned risk visibility, though it acknowledges limitations in reachability, stripping, and patch verification, and it calls for broader library coverage and integration of reachability analyses in future work.

Abstract

Android is the most used Operating System worldwide for mobile devices, with hundreds of thousands of apps downloaded daily. Although these apps are primarily written in Java and Kotlin, advanced functionalities such as graphics or cryptography are provided through native C/C++ libraries. These libraries can be affected by common vulnerabilities in C/C++ code (e.g., memory errors such as buffer overflow), through which attackers can read/modify data or execute arbitrary code. The detection and assessment of vulnerabilities in Android native code have only been recently explored by previous research work. In this paper, we propose a fast risk-based approach that provides a risk score related to the native part of an Android application. In this way, before an app is released, the developer can check if the app may contain vulnerabilities in the Native Code and, if present, patch them to publish a more secure application. To this end, we first use fast regular expressions to detect library versions and possible vulnerable functions. Then, we apply scores extracted from a vulnerability database to the analyzed application, thus obtaining a risk score representative of the whole app. We demonstrate the validity of our approach by performing a large-scale analysis on more than $100,000$ applications (but only $40\%$ contained native code) and $15$ popular libraries carrying known vulnerabilities. The attained results show that many applications contain well-known vulnerabilities that miscreants can potentially exploit, posing serious concerns about the security of the whole Android applications landscape.

Figures (6)

• Figure 1: Workflow of the approach to extract, analyse and associate native libraries, specifically in the use-case of vulnerability researchers.
• Figure 2: The pie chart shows the percentage of apps for which a risk level has been computed by only identifying $15$ products. The NONE value means that the found Native Code does not belong to any of our $15$ selected products, but it can have vulnerabilities related to other libraries.
• Figure 3: This histogram shows the risk level per year on the analyzed apps. Each year has 2 bars: red/left-bottom bar for HIGH risk, orange/left-upper bar for MEDIUM risk, and grey/right bar for NONE risk.
• Figure 4: The histograms show the vulnerability risk levels (HIGH: red/left bar; MEDIUM: orange/central bar; NONE: grey/right bar) of the apps by markets. On the left, we plotted the main markets. On the right, we can see a detail of all markets except the Google Play Store.
• Figure 5: The histogram compares the number of apps for each market in the Androzoo dataset (green/left bar) and the apps used for vulnerability detection in our dataset (blue/right bar).