Uncovering Android AIDL/HIDL Service Vulnerabilities: Methods and Real CVE Examples

Introduction

The series continues the exploration of Android native service vulnerabilities, focusing on the remaining three categories of Binder services that rely on AIDL/HIDL interfaces rather than traditional onTransact implementations.

Information Collection

To discover AIDL services, the service list command retrieves all registered services. Since many entries are pure Java framework or vendor services running in system_server or vendor apps, filtering is required. The filtering steps are:

Use service list to obtain the full list.

Run dumpsys on a service to get its process ID.

Map the process ID to the application name.

These steps can be scripted into a tool that outputs a concise table of AIDL services.

AIDL Service Enumeration

AIDL services are managed by the Service Manager, so they appear in the service list output. After filtering out Java‑only services, the remaining entries represent native services whose interfaces are defined in AIDL files and automatically generated by the Android build system.

HIDL Service Enumeration

Unlike AIDL, HIDL does not provide a built‑in command to list services. However, the HIDL manager IServiceManager offers a list method. The article shows a snippet of the core implementation and demonstrates how to invoke it to obtain HIDL service names.

Common Vulnerability Types

Memory‑corruption bugs in Binder services usually stem from improper handling of incoming parameters. The article categorizes typical flaw patterns:

Primitive Types : integer overflow, missing signed‑range checks.

Variable‑Length Types : unchecked length leading to out‑of‑bounds reads/writes, non‑NULL‑terminated strings.

Interface Types : unsafe type casting, insufficient validation of hidl_handle, MQDescriptorSync, or generic IBinder interfaces.

Union Types : lack of strict validation causing type confusion.

Enum Types : missing min/max checks.

Custom Types : dangerous members inside structs without comprehensive safety checks.

Code Auditing – Real CVE Cases

CVE‑2023‑21008

In Pixel devices, the AIDL service android.hardware.wifi.supplicant.ISupplicant/default defines an addP2pInterface method that returns an ISupplicantP2pIface object. Its setWpsDeviceType function receives a variable‑length byte[] type but copies eight bytes unconditionally with std::copy_n, causing an out‑of‑bounds read when the array is shorter than eight bytes.

CVE‑2023‑20766

On MTK‑based Android devices, the HIDL service [email protected]::ILbs/AgpsInterface is a closed‑source component. By analyzing the automatically generated library [email protected], the article extracts all functions prefixed with BpHwLbs::_hidl_. The sendToServerWithCallback function accepts an IBinder and a hidl_vec<uint8_t> without validating the vector size before copying it into a fixed 0x4000‑byte buffer, leading to a potential out‑of‑bounds write.

Conclusion

AIDL/HIDL services are pervasive across Android devices, and the diversity of hardware implementations introduces many overlooked services. While SELinux policies often limit direct access, a complete attack chain (APP → HAL → AIDL → HIDL) can still cause serious impact. Most discovered issues rank at medium severity, but careful enumeration and code auditing can reveal critical flaws.