Android is positioned as the most widely used mobile operating system in the world, largely due to being an open platform. Older mobile operating systems, such as Symbian, Blackberry OS, Windows Mobile, were all closed source at the time Android joined the competition in the mid-2000s. Google managed to convince the developers by offering an open, customizable platform and free development tools.
There is an opinion that open systems are less secure. If hackers have access to the OS components source code, they don't resort to reverse engineering while looking for vulnerabilities. If user applications can control most of the hardware resources, these resources could be misused against the user's interests. Keeping Android open, while counteracting the security threats, is one of the greatest challenges for Google.
Tim Cook said at VivaTech 2021 that the number of malware-related incidents on Android was 47 times higher than on iOS. Panda Security published a similar metric in 2019 mentioning that malware issues are about 50 times more frequent on Android vs. iOS.
Actually, these numbers are not as clear as it might seem at first glance. These metrics include rooted devices and very old Android phones with minimal security. Moreover, the fact that Android is so popular among the developers means that it is also the most popular target for hackers and malware writers.
Some of the most secure operating systems belong to the BSD family: OpenBSD, NetBSD, FreeBSD.1 These operating systems are open, yet more secure than many closed-source OS.
One of the advantages of open source, regarding security, is that any security expert can study the code. This helps identifying and fixing vulnerabilities and allows detecting design patterns leading to potential vulnerabilities.2
Permissive vs. unsafe
Older Android versions had minimal security controls. The applications could access almost all the user and system data. From the developer's point of view this was a huge advantage compared to other operating systems, but at the same time it forced the phone manufacturers (Samsung, HTC, Sony ...) to start customizing Android, removing the most dangerous features or making them less accessible.
Google also began removing the most sensitive features. For example, one of the controversial changes was the removal of the sendRawPdu API in Android 2.x, without an official explanation from Google and without any workarounds, except rooting the device. This API was used to send binary SMS.
The first Android generation suffered from a conflict of interests. On one hand, Google wanted Android to become the most popular mobile platform, winning over the existing competitors. On the other hand, Google could not allow the developers to have full control of the device because it would make the commercial use unfeasible.
At this point, it becomes evident that Android's initial vulnerability was due to its permissiveness: lack of restrictions to access sensitive resources, data, or functionality. It was not due to open source. This permissiveness began to disappear in subsequent versions. The most current versions are as permissive as other operating systems, not only mobile operating systems. For example, Android 8 introduced restrictions for apps running in the background. These restrictions help saving battery, mobile data, and other resources usage by processes that are not visible to the user. Another example of permissiveness reduction are the restrictions to access the SIMcard since Android 2.x. Currently only system apps and the apps with carrier privileges can interact with the SIM.
Each new Android version introduces additional restrictions, forcing the developers to modify their codebase to adapt to the new restrictions. In some cases, it is not possible to adapt to the changes, as in the sendRawPdu example mentioned above. Therefore, any app using sensitive resources may become obsolete in a future version of Android.
Different Android flavors
For example, Samsung and Huawei phones may have the same Android version, but the platforms are not identical. As mentioned earlier, device manufacturers began customizing their own distributions, known as Custom ROM, almost since the first Android release.
The generic versions, published and maintained by Google, are known as Android Open Source Project (AOSP). These versions are used in Google-branded devices and some generic, generally low-cost, devices.
Custom versions may include cosmetic improvements, because the early generic versions were lacking attractive graphical interfaces. For example, the high-end devices manufactured by HTC featured some user interface enhancements known as Sense. Custom versions may also include kernel mods to support specific hardware. This allows improving performance and using the device resources more efficiently. Phone hardware is quite heterogeneous. The AOSP versions may not always provide compatibility with a specific piece of hardware. For example, some manufacturers include thermovisor, RFID reader, printer, among other devices uncommon in mobile phones. It may be necessary to customize Android to support these features.
Custom versions can be more secure or less secure. For example, some carriers pre-install system apps, which can install additional apps without user consent, compromising the user's privacy and security. Moreover, these automatic app installation mechanisms can be exploited to spread malware, bypassing all security restrictions.
In summary, not all Androids are the same. Therefore, it is surprising that different sources generalize the concept of Android security without making a comparative analysis of different versions and customizations.
A challenge for the developer
The Android developer can choose to restrict the app usage on rooted devices or the devices with older Android versions. Some developers for the banking and financial industry make this decision to reduce the risks of vulnerabilities. Accessing the bank account on a very old phone is like accessing from a public computer. The risk of spyware can be very high.
On the other hand, supporting a wider range of devices, including the older ones, allows expanding the user base.
In the event of fraud, the phone manufacturer, the OS provider or the mobile operator will not assume the responsibility. The developer will be the only one responsible. Therefore, it is very important to assess the risks before publishing the application.
References
- Michael W. Lucas (2013), «Absolute OpenBSD: Unix for the practical paranoid», 2nd ed, No Starch Press. ISBN 978-1-59327-476-4
- Amiangshu Bosu, Jeffrey C. Carver et al (2014). «When are OSS Developers More Likely to Introduce Vulnerable Code Changes? A Case Study», IFIP International Conference on Open Source Systems, DOI:10.1007/978-3-642-55128-4_37
