Android, Google’s open platform, is liked for its versatility and the customization opportunity it offers. With great possibilities, however, come great headaches, as the same flexibility and access granted to developers and users alike, provides opportunities for malicious hackers to exploit vulnerabilities and undermine the security of more than 2.5 billion active devices (as of May 2019).

Why think about Android Security?

Smartphones and tablets are now an intrinsic part of people’s lives providing a means to access and use sensitive information (banking and other financial data, personal documents, video, photos, contacts, PINS and passwords). Although Google’s Android operating system is based on the Linux kernel, users are often concerned about whether the platform is really secure. Recently, for example, researchers from Checkpoint found that a billion smartphones were affected by a set of 400 security flaws in tested DSP chips, the Digital Signal Processor units manufactured by Qualcomm Technologies, and used on phones sold by companies including  Google, Samsung, LG and Xiaomi affecting 40% of Android phones and 90% of the U.S. market. Because of this issue, malicious hackers could have had access to photos, location data, calls, videos but also make the phone unresponsive and virtually useless. It is no surprise then that Google makes incorporating more and more security into its operating system a priority, as well as releasing timely security fixes into the latest version of Android to ensure customers’ loyalty and trust.

Android issues

Breaking out of the application sandbox

This is possible if the security of the Linux kernel is compromised. Android relies on protections to enforce the application sandbox and makes efforts to prevent single vulnerabilities from compromising the OS and other apps. In each Android version, security features have been added. SELinux mandatory access control (MAC) separation between the system and apps was introduced in Android 5.0. Limitations were introduced in Android 10, where apps had a limited raw view of the filesystem and no direct access to paths like /sdcard/DCIM. 

Memory safety issues

This problem accounts for 59% of all critical and high-severity Android security vulnerabilities and includes memory corruption and overflows. A quick look at the CVE list shows that of the 414 Android vulnerabilities identified in 2019, 150 are related to memory corruption and to the possibility of a malicious hacker being able to execute code remotely and get access to files and data without privileges.  Android provides Address Space Layout Randomization (ASLR), a memory-protection process to minimize issues and also uses “NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc and Linux mmap_min_addr to mitigate risks associated with common memory management errors.”  One of the efforts Google is concentrating on is the progressive migrating to memory-safe languages, namely Java, the JVM-compatible Kotlin and Rust. C and C++ are often used thanks to their flexibility especially when writing kernels and drivers; unfortunately, they do not offer reliable garbage collection and their manual memory management can lead to issues, such as buffer overflows and overreads. Mozilla Rust is proving to be “a happy medium between the low-level power of C and the memory safety found in higher-level languages like Java.” 

Permissions issues

These issues accounted for 21% of those addressed by Google security engineers in 2019. The Android permission system is a core component that protects data and users through access control mechanisms. This important part of the security measures devised by Google is often the target of changes and improvements at any new release of Android.  Every app that runs on the Android platform must be signed by the developer. By default, no application has permission to perform any operations that would adversely impact other applications, the operating system or the user. This includes reading or writing the user’s private data (such as contacts or emails), reading or writing another application’s files, performing network access and more.  Because the kernel sandboxes applications from each other, applications must explicitly share resources and data. They do this by declaring the permissions they need and prompt the users for consent at the time the application is installed. Some apps request more permissions than essential to their proper functioning; some are merely data collection features. Unfortunately, users often grant permissions without really understanding the implications of their choices.  Google is constantly addressing permission issues. For example, while with Android 10 users could restrict access to location info and had the option to “allow only while using the app,” Android 11 went further, allowing users to restrict access to location, microphones and cameras also on a temporary, single-use basis. Furthermore, apps that haven’t been used for long periods will see their permissions revoked. In Android 11, an app will only be able to ask a user for permissions and be denied twice; after that, the operating system automatically denies further requests.  There is much developers can do to ensure secure access to system resources by apps as well as ensuring the proper permissions are given to third-party applications. They can limit the storage of data to internal only, or, if sharing data between two apps owned by the same developer, they can use a signing key. This ensures the apps can automatically check lawful access without user interaction and possibilities of errors.

Overlay attack

This has always been a severe issue and has allowed the possibility to capture credentials by tricking users into typing them into fake online services. In Android 11, overlay needs to be allowed by the user who is not taken directly to the authentication screen but to a step before where he or she can choose to proceed.

Data storage issues

The storing of data is always a concern. Android users see their data placed in internal and external storage as well as in content providers.  External storage is useful for large, non-sensitive files as well as for data that are meant to be shared with other apps. Data in external storage like SD cards, however, are removable and can be accessed in other contexts. Sensitive info should be, instead, encrypted in internal storage to be accessed only by the app that created that data.    To share with other apps, rather than using modes like MODE_WORLD_WRITEABLE or MODE_WORLD_READABLE, that provide no control over data access, it is better to use content providers with which access can be granted on a need basis, and permissions can be changed based on the true need of the apps. Access to the content provider objects should be disallowed if a developer does not intend to share data with other third-party apps.  Of course, it is also important to ensure that the storing and transmitting of sensitive data is kept at a minimum for security and compliance reasons. To prevent exposure of data, developers can consider alternatives first (transmitting the hash of an email rather than the actual address). The developer can also ensure that no privacy-covered data is unnecessarily transmitted to a server if they could be handled on the client. Logs are also a potential source of leaks with data that could indivertibly be stored there and then become available to any application with READ_LOGS permission. 

One of the issues often mentioned refers to the ability of applications to load code dynamically. This is a process that is often used for legitimate purposes but that can be exploited by malicious hackers as well. The advantage is the possibility of not having to load all libraries right away but only when needed during the use of the application. The disadvantage is that a remote code can easily avoid being caught by static analysis tools and might not be detected through the verification process as it is not actually present in the published application package APK but rather in the DEX.

Rooting

This is a procedure that users often use to get more control over their devices and break free from the operating system restrictions. Unfortunately, it is also a way to make ineffective some of the built-in security features of Android with the risk of exposing data that before were safely stored away behind layers of protective restrictions. Rooting can lead not only to security issues but also to other problems, including incompatibility of some legitimate apps and the inability to upgrade or update Android. 

Keeping the Android platform and ecosystem safe

Android takes advantage of the security of Linux kernel and security features, including a user-based permissions model, application signing and process isolation. What else has been introduced to keep this ecosystem safe?

Biometrics

An important feature in Android 11 is the possibility to choose which category of biometrics developers can request for use of their app. For access to very sensitive medical or financial data, for example, a “strong” level biometric can be requested and that would include iris or fingerprint scanning as well as 3D secure facial unlock. Other options would be weaker biometrics (like normal facial recognition) or device credentials’ (like PINs and passwords). Developers can use the BiometricPrompt API to select the type of biometric necessary to guarantee the utmost protection to the users’ data.

Scoped storage

When scoped storage was introduced with Android 10 to limit access to files and folders on a need-basis, it created issues for many apps. Android 11 fine-tuned the feature and apps with access to storage will have a read-only option set until the user manually switches it to “all files access.” Scoped access further segregates files belonging to each app and, although it makes it more difficult for developers to configure legitimate access to data between apps, it does give more security and control to users on what is accessed and shared.

Background information gathering

With Android 11, apps are no longer allowed to gather information in the background. The only time an application will be allowed to collect information is when it is running. This places users in control of when an app can collect data and information.

The flaws of Android devices

Many operating system flaws still pose a risk for potentially millions of Android devices. However, new Android developments have added important features for the safety of users’ data and devices.  Fixes for publicly known bugs are released immediately by the Google security team who continually has applicable patches available and in the monthly Android Security Bulletins. It is important for users but also developers to take advantage of the latest security updates to minimize issues and contribute to safer Android environments.  

Sources:

Android, Google Open Source Set up for Android Development, Android Security Reports, Android Android Architecture, Android Platform Architecture, Android System and kernel security, Android Android Mobile Security Threats, Kaspersky App security best practices, Android Android Security Features, Android Android Security Bulletins, Android Secure an Android Device, Android Android Security Acknowledgements, Android Android ecosystem security, Google Transparency Report Vulnerability Statistics, CVE Details Number of apps available in leading app stores 2020, Statista Research Department Achilles: Small chip, big peril.  Check Point Software Technologies Ltd. Android is on over 2.5 billion active devices, CNET Security bugs left unpatched in Android app with one billion downloads, ZDNet Google: Here’s how we’re toughening up Android security , ZDNet