Uncovering Android Socket Service Vulnerabilities: Techniques and Case Study

Overview

Over the past year, the Amber Lab team has focused on vulnerability research of Android local services, submitting hundreds of reports to vendors and obtaining dozens of CVE identifiers. This series shares technical findings from that work.

Scope

The analysis assumes the reader has binary vulnerability exploitation experience on Android or Linux, possesses reverse‑engineering skills, and works on a rooted device.

The article does not cover access‑control analysis, application‑scenario analysis, or full exploit chain construction.

Fundamentals

A local service runs in the background, listening for client requests via mechanisms such as sockets or Binder. Typical characteristics include auto‑start on boot, high privileges, and automatic restart after crashes.

Based on IPC type, local services fall into two major categories: Linux‑socket‑based services and Android‑Binder‑based services. Socket services further divide into File System Socket and Abstract Socket; Binder services include Origin, AIDL, HIDL, and Vendor Binder variants.

Collecting Active Socket Services

Using netstap -ap | LISTENING quickly lists most relevant information: type (STREAM|DGRAM|SEQPACKET), state, PID, process name, and path. Filtering for LISTENING services isolates active sockets. Paths starting with “@” denote Abstract Sockets, while regular file paths denote File System Sockets. In practice, both are treated similarly for vulnerability research.

Common Vulnerability Types

Typical socket service flaws include misconfigured permissions (e.g., SELinux policies), command injection, directory traversal, business‑logic errors, information leakage, denial‑of‑service, and memory corruption. This article focuses on vulnerabilities arising from data handling.

Locating Data‑Processing Functions

Android’s libcutils library provides socket‑related APIs such as android_get_control_socket, socket_local_server, and socket_local_server_bind. Vendors may also invoke the raw system call: int socket(int domain, int type, int protocol); After identifying socket creation, the call chain socket → bind → listen → accept → read/recvfrom leads to the server’s data‑receiving routine.

Manual Auditing Example (CVE‑2023‑35694)

Using netstap, the /vendor/bin/dmd binary was found listening on TCP port 50002. Reverse‑engineering revealed the socket handling functions. The call chain socket → bind → listen resides in sub_18d20, which is invoked by sub_18f50. After binding, accept is called, followed by a loop using select and recvfrom to read client data into a 0x10000‑byte heap buffer, then passed to sub_1AB40 for processing.

In sub_1AB40, the code extracts a length field with v4 = *(unsigned __int16 *)(v3 + 1) + 2LL. Because v4 is unchecked and can be as large as 0x10001, it can be crafted to cause out‑of‑bounds reads, leading to memory‑corruption vulnerabilities.

Summary

Socket service vulnerability research is relatively low‑effort compared to other targets, relying mainly on manual reverse‑engineering and data‑flow tracing. Misconfiguration bugs require SELinux rule inspection, while memory‑corruption bugs need careful analysis of data‑handling code. The number of socket services varies widely across vendors; Google devices expose few, whereas Qualcomm and MediaTek expose many due to cross‑platform compatibility.

Because socket services typically communicate only with the HAL layer and enforce strict SELinux policies, they are inaccessible to regular apps or shells, making exploitation difficult and often resulting in low‑severity ratings.

References

https://www.blackhat.com/asia-22/briefings/schedule/#unix-domain-socket-a-hidden-door-leading-to-privilege-escalation-in-the-android-ecosystem-25774

https://source.android.com/docs/security/bulletin/pixel/2023-07-01