Introduction

Custom Android ROMs, often built upon the Android Open Source Project (AOSP), offer users unparalleled flexibility, features, and control over their devices. However, this freedom comes with an inherent security responsibility. Deviations from the stock Android security model, coupled with custom modifications, can introduce new vulnerability vectors that leave users susceptible to exploitation. This article delves into the methodologies for identifying common security weaknesses in AOSP-based custom ROMs and outlines practical strategies for patching them, ensuring a more robust and secure user experience.

The AOSP Security Landscape and Custom ROMs

Android’s security architecture is multi-layered, relying on the Linux kernel’s user-based permissions (DAC), a robust application sandbox, and Mandatory Access Control (MAC) via SELinux. Custom ROMs often introduce changes in various layers:

• Kernel: Custom kernels might include unreviewed drivers or outdated security patches.
• Framework: Modifications to core Android services or libraries can create bypasses.
• Userland: Custom apps, daemons, or modified `init` scripts can operate with elevated privileges or expose services.

Understanding these potential points of divergence is crucial for effective security analysis.

Common Vulnerability Vectors in Custom ROMs

Outdated Security Patches

One of the most frequent issues is a custom ROM lagging behind the official AOSP security patch level. This leaves the system vulnerable to exploits for which patches have already been released upstream.

adb shell getprop ro.build.version.security_patch

Compare the output (e.g., “2023-01-05”) with the latest AOSP security bulletin.

Permissive SELinux Policies

SELinux enforces MAC, limiting what processes can access. A custom ROM might ship with SELinux in `permissive` mode, or have overly broad `enforcing` policies, effectively nullifying its protection. Permissive mode logs denials but doesn’t prevent them.

adb shell sestatusadb shell cat /sys/fs/selinux/enforce

A return value of `0` for `/sys/fs/selinux/enforce` indicates permissive mode, `1` indicates enforcing. Overly broad rules are harder to spot without policy analysis.

Unsecured Custom Services and Binaries

Custom ROMs often add unique features implemented as new services or `setuid` binaries. If these are not developed with security in mind, they can become privilege escalation vectors.

• Custom Daemons: Services running as root or system user that listen on network ports or process untrusted input without validation.
• `setuid` Binaries: Programs designed to run with elevated privileges. Any vulnerability here can lead to root access.

# List all processes with their SELinux contextadb shell ps -AZ# Find setuid/setgid binaries on the system (potential escalation points)adb shell find / -perm /4000 2>/dev/null

Weaknesses in Custom Codebases

Custom ROM developers might integrate third-party libraries, implement custom cryptography, or add new apps. These additions can suffer from:

• Insecure data handling or storage.
• Improper input validation, leading to command injection or buffer overflows.
• Hardcoded credentials or cryptographic keys.
• Misconfigured permissions for custom apps or content providers.

Methodologies for Vulnerability Identification

Static Analysis: Source Code and Binary Review

Static analysis involves examining the ROM’s codebase or compiled binaries without executing them.

• `build.prop` Review: Look for `ro.debuggable=1` (enables ADB root, debug features), `ro.secure=0` (disables some security features), or `ro.build.type=userdebug` (userdebug builds have more debug features than user builds).
• `init.rc` and Service `.rc` Files: Scrutinize `init` scripts for services starting with root privileges, `on boot` commands, or open network sockets.
• SELinux Policy Analysis (`sepolicy`): Examine `vendor/sepolicy` directories for custom rules that might grant excessive permissions.
• Binary Decompilation: For custom prebuilt binaries or APKs, use tools like `apktool` for APKs and `Jadx` or `Ghidra` for `.dex` or native binaries to identify insecure code patterns.
• Kernel Source Review: If a custom kernel is used, check for backported patches, custom drivers, and known CVEs.

# Search for debug flags in key configuration filesadb shell grep -r "ro.debuggable" /system/build.prop /vendor/build.prop /init.rcadb shell grep -r "ro.secure" /system/build.prop /vendor/build.prop

Dynamic Analysis: Runtime Observation

Dynamic analysis involves monitoring the system while it’s running, often under various load conditions or inputs.

• Logcat and Dmesg: Continuously monitor `adb logcat` and `adb shell dmesg` for suspicious activity, especially `AVC denied` messages from SELinux.
• Network Scanning (`netstat`): Identify open ports and services running on the device that shouldn’t be accessible.
• Process Monitoring (`ps -AZ`, `top`): Observe processes, their privileges, and SELinux contexts. Look for unexpected processes or those consuming excessive resources.
• Tracing (`strace`, `ltrace`): Attach to suspicious processes to observe their system calls (`strace`) or library calls (`ltrace`), revealing their true actions and potential vulnerabilities.

# Monitor network connections and listening portsadb shell netstat -tunlp# Monitor kernel messages for SELinux denials or other security-related eventsadb shell dmesg | grep 'selinux'adb shell dmesg | grep 'audit'

Practical Patching Strategies

Keeping AOSP Up-to-Date

The most fundamental step is to regularly merge the latest AOSP security patches. Custom ROM maintainers should integrate these updates promptly after their public release. This involves pulling changes from the official AOSP repositories and resolving any merge conflicts introduced by custom modifications.

Hardening SELinux Policies

Transitioning SELinux to enforcing mode and refining policies is critical:

1. Enable Enforcing Mode: Ensure `sepolicy` is configured for enforcing mode.
2. Analyze AVC Denials: When SELinux is in enforcing mode or permissive with verbose logging, `dmesg` will show `avc: denied` messages. Each denial indicates an attempted access that was blocked or would have been blocked.
3. Generate Specific Rules: Use tools like `audit2allow` (often on a Linux host with a kernel build environment) to generate specific SELinux rules from audit logs. However, it’s safer to manually craft rules by understanding the service’s legitimate needs.
4. Example Policy Refinement: If a custom service `my_daemon` (type `my_daemon_t`) is attempting to write to `/data/misc/my_data/file` (type `my_data_file_t`) and getting an `avc: denied` message like `avc: denied { write } for pid=1234 comm=”my_daemon” name=”file” dev=”dm-0″ ino=5678 scontext=u:r:my_daemon_t:s0 tcontext=u:object_r:my_data_file_t:s0 tclass=file`, you would add a rule similar to this to `vendor/sepolicy/public/my_daemon.te` (or a more specific policy file):

   allow my_daemon_t my_data_file_t:file { write };

5. Define New Types: If adding new custom files or directories, define their SELinux types in `file_contexts` and ensure services interacting with them have appropriate permissions.

Auditing and Securing Custom Components

• Code Review: Conduct thorough security code reviews of all custom additions, focusing on input validation, privilege management, cryptography, and inter-process communication (IPC).
• Remove Debug Features: Ensure that features like `ro.debuggable=1` or `ro.secure=0` are not present in release builds. Disable unnecessary ADB debugging features.
• Principle of Least Privilege: Configure custom services and binaries to run with the absolute minimum necessary permissions. Avoid running custom daemons as `root` unless absolutely unavoidable, and even then, consider dropping privileges immediately after initialization.
• Secure Defaults: Implement secure defaults for all custom features. For instance, if a custom service uses network communication, ensure it uses TLS/SSL and robust authentication.

Conclusion

Securing AOSP-based custom ROMs is an ongoing and complex endeavor. It requires a deep understanding of Android’s security model, diligent vulnerability identification through both static and dynamic analysis, and a commitment to prompt and intelligent patching. By addressing common pitfalls such as outdated security patches, permissive SELinux configurations, and unsecured custom components, custom ROM developers can significantly enhance the security posture of their offerings, building trust and providing a safer experience for their user base.