By default, Android has a strong security model and incorporates full system SELinux policies, strong app sandboxing, full verified boot, modern exploit mitigations like fine-grained, forward-edge Control Flow Integrity and ShadowCallStack, widespread use of memory-safe languages (Java / Kotlin) and more. As such, this article explains common ways in which people worsen the security model rather than criticisms of the security model itself.
Unlocking the bootloader
Unlocking the bootloader in Android is a large security risk. It disables verified boot, a fundamental part of the security model. Verified boot ensures the integrity of the base system and boot chain to prevent evil maid attacks and malware persistence.
Contrary to common assumptions, verified boot is not just important for physical security — it prevents the persistence of any tampering with your system, be it from a physical attacker or a malicious application that has managed to hook itself into the operating system. For example, if a remote attacker has managed to exploit the system and gain high privileges, verified boot would revert their changes upon reboot and ensure that they cannot persist.
Rooting your device
Rooting your device allows an attacker to easily gain extremely high privileges. Android's architecture is built upon the principle of least privilege. By default, only around 6 processes run as the root user on a typical Android device, and even those are still heavily constrained via the full system SELinux policy. Completely unrestricted root is found nowhere in the operating system; even the init system does not have unrestricted root access. Exposing privileges far greater than any other part of the OS to the application layer is not a good idea.
It does not matter if you have to whitelist apps that have root — an attacker can fake user input by, for example, clickjacking, or they can exploit vulnerabilities in apps that you have granted root to. Rooting turns huge portions of the operating system into root attack surface; vulnerabilities in the UI layer — such as in the display server, among other things — can now be abused to gain complete root access. In addition, root fundamentally breaks verified boot and other security features by placing excessive trust in persistent state. By rooting your device, you are breaking Android's security model and adding further layers of trust where it is inappropriate.
A common argument for rooting is that Linux allows root, but this does not account for the fact that the average desktop Linux system does not have a security model like Android does. On the usual Linux system, gaining root is extremely easy, hence Linux hardening procedures often involve restricting access to the root account.
Custom ROMs
The majority of custom ROMs severely weaken the security model by disabling verified boot, using userdebug builds, disabling SELinux and various other issues. Furthermore, you are also usually at the mercy of the maintainer to apply security updates properly. Certain ROMs often apply security patches late, or in some cases, not at all. The latter especially applies to firmware patches.
LineageOS
A common ROM that has many of these issues is LineageOS:
- LineageOS uses userdebug builds by default. This adds many debugging features as additional attack surface. It also weakens various SELinux polices and exposes root access via ADB, which, as previously discussed, is not a good idea.
- LineageOS requires an unlocked bootloader, therefore disabling verified boot, which is essential to verify the integrity of the operating system.
- It does not implement rollback protection. This allows an attacker to downgrade the system to an older version and then exploit already patched vulnerabilities. The default updater even allows you to downgrade versions yourself.
- Most LineageOS builds also do not include firmware updates, which prevents users from getting new patches to fix vulnerabilities. Instead, it gives a pop-up advising users to flash updates manually that most people will simply ignore.
This is a non-exhaustive list. There are more issues than just those listed above. LineageOS (and most other custom ROMs) are focused on customising the device and not privacy or security. Of course, you could build LineageOS yourself to fix many of these issues, but most users will not be capable of doing so.
MicroG / Signature Spoofing
MicroG is a common alternative to Google Play Services. It is often used to get rid of Google's tracking, but most people do not realise that this can potentially worsen security, as it requires signature spoofing support, which allows apps to request to bypass signature verification. This subverts the security model and breaks the application sandbox as an app can now masquerade itself as another app to gain access to the app's files. In a system with signature spoofing, it is impossible to know anything — there is no way to trust that an application is genuinely what it claims to be, and it is impossible to build a strong security model upon this.
Although some signature spoofing implementations can restrict access to this functionality to reduce the risk by, for example, allowing only microG to spoof the Play Services signature and nothing else.
Firewalls
Firewalls, such as AFWall+ or Netguard, are regularly used on Android to attempt blocking network access from a specific app, but these do not reliably work — apps can use IPC to bypass such restrictions. If you cut off network access to an app, it will not prevent the app from sending an intent to another app (such as the browser) for it to make the same connection. Many apps already do this unintentionally whilst using APIs such as the download manager.
The most effective way to block network access is to revoke the INTERNET permission from the app
like
GrapheneOS allows you to do. This prevents abusing OS APIs to initiate network connections, as they contain checks
for that permission, one example of which is the aforementioned download manager. You should also run the app in its
own user or work profile to ensure that it cannot abuse third party apps either.
Conclusion
- Full verified boot with support for custom signing keys — certain Android OEMs often fail to implement verified boot properly, or at the very least, neglect to include support for custom keys to be able to flash an alternative operating system without having to lose verified boot. On Pixels, verified boot is implemented securely, and alternative operating systems are often signed with custom keys to keep the security model intact.
- The Titan M chip — the Titan M is a tamper-resistant hardware security module that provides a number of security properties. It can securely store cryptographic material using the StrongBox keystore and enforces throttling upon repeated failed login attempts to mitigate bruteforcing attacks. Furthermore, it is integrated into the verified boot process, and due to its tamper-resistant nature, it is extremely difficult to extract data from the chip or bypass its security features; if any abnormal conditions are detected, such as unnatural changes in temperature, the Titan M will erase all data stored within it, thereby categorically mitigating most side-channel attacks. Even if an attacker gained access to Google's signing keys for the Titan M firmware, they would not be able to flash their own malicious firmware due to insider attack resistance, which prevents updating firmware until the valid lockscreen passcode is entered.
- Fine-grained, forward-edge kernel Control Flow Integrity (CFI) and ShadowCallStack — the Pixel kernels are compiled with custom hardening patches, which includes CFI and ShadowCallStack to mitigate code reuse attacks, among various other mitigations. While such mitigations are commonly deployed throughout user space, as briefly mentioned at the beginning of the article, it is up to the OEM to enable it in the kernel, which is uncommon outside of Pixel devices.
- Wi-Fi privacy features — devices connected to a Wi-Fi network can be tracked through a variety of different methods. Primarily, this occurs through MAC addresses, which are unique identifiers assigned to network interface controllers (NICs). Every time a device connects to a network, its MAC address is exposed. This enables adversaries to track the device and uniquely identify it on the local network. Certain mobile devices have attempted to resolve this issue by randomising the MAC address. However, many don't do this, and the ones that do often use a faulty implementation, resulting in the MAC address still being leaked. Furthermore, other Wi-Fi identifiers exist that can further enable fingerprinting or even be used to infer the MAC address, including information elements in probe requests and predictable sequence numbers. In comparison, Pixels use an effective implementation of MAC address randomisation, minimal probe requests and randomised initial sequence numbers.
Remember that GrapheneOS cannot prevent you from ruining your privacy yourself. You still have to be careful regardless of the operating system.
Go back