The Hidden Risks of Third Party Dialers and Exported Android Components

Executive Summary

Actuator Security has observed a recurring vulnerability class in third party dialers and call related applications: exported components that initiate calls without enforcing caller identity or permission checks. The result is a confused deputy condition where a zero permission application can induce a privileged dialer to place a call.

This post explains the underlying mechanism, highlights the discrepancy between platform documentation and application behavior, and cites publicly tracked cases and research tooling.

Index

• Introduction
• Threat Model
• Exported Components Explained
• Why Dialers Are High Risk
• What the Android Documentation Says
• The Gap Between Documentation and Reality
• Attack Flow
• Real World CVEs
• Actuator Security Research and pSlip
• Defensive Guidance
• References

Introduction

Third party dialers, call screen customization apps, and theming utilities are common across Android ecosystems. These apps often expose call handling flows, UI layers, and convenience features that sit directly on sensitive trust boundaries. In multiple real world cases, exported components within these apps were reachable by untrusted callers and performed privileged actions.

Threat Model

The attacker model is intentionally simple:

• A malicious app is installed on the device
• The malicious app requests no permissions
• The target device has a vulnerable dialer or call related app installed
• The malicious app sends an explicit intent to an exported component in the dialer

The security impact depends on the dialer behavior. In the vulnerable pattern, the dialer initiates a call without user interaction. This enables unauthorized premium calls, silent calls to attacker controlled numbers, and call forwarding or MMI behavior in some cases.

Exported Components Explained

Android components such as activities, services, and broadcast receivers are callable across application boundaries when exported. A component can be exported explicitly via android:exported="true" or implicitly via intent filters. Exporting a component makes it part of the app public attack surface.

The unsafe pattern is consistent:

• An exported component accepts an explicit intent
• The component trusts unvalidated intent data such as tel: URIs
• The component performs privileged behavior like placing a call
• The component does not require a signature permission or validate the caller

Why Dialers Are High Risk

Dialers often hold CALL_PHONE or equivalent capabilities through platform roles or privileged pathways. When a dialer exposes an exported entry point that directly places calls, it becomes a confused deputy: a lower privileged app can trigger actions that would otherwise be blocked by the platform permission model.

What the Android Documentation Says

The Android developer documentation for Intent.ACTION_CALL includes warnings and restrictions: most apps should use ACTION_DIAL, attempting to call without the required permission can raise a SecurityException, and additional restrictions apply for emergency numbers and call forwarding codes. These restrictions describe the platform behavior for callers of ACTION_CALL.

Reference: Official Android documentation for Intent.ACTION_CALL
https://developer.android.com/reference/android/content/Intent#ACTION_CALL

The Gap Between Documentation and Reality

In the vulnerable pattern, the attacker does not invoke ACTION_CALL directly. Instead, the attacker targets an exported component inside an app that already has the ability to place calls. From the platform point of view, the privileged app initiates the call, so the platform restrictions do not prevent it. This is an application design flaw, not a platform permission failure.

Attack Flow

Evidence in the Wild

>Actuator Security Research and pSlip

This work is part of ongoing research conducted by Actuator Security into escalation paths created by exported components. pSlip is a static analysis toolkit designed to find potentially vulnerable escalation paths by analyzing exported components, intent filters, provider permissions, and cryptographic misuse.

A public technical talk titled The Permission Slip Attack was delivered at ShmooCon and presents this class of issues, including case studies and detection strategies grounded in real applications.

Research, tooling, and slides are available here:
https://github.com/actuator/pSlip

Defensive Guidance

• Default to android:exported="false" and only export when there is a clear external contract
• For any exported component, validate the caller and enforce permissions inside the component
• Harden intent parsing. Treat extras and URIs as attacker controlled input
• Separate UI navigation from privileged actions. Avoid call placement in UI entry points
• Audit third party SDK components. Treat them as part of your exported surface until proven otherwise
• Continuously scan for escalation paths as part of release processes

References

• Android developer documentation for Intent.ACTION_CALL: developer.android.com
• Actuator Security pSlip toolkit and ShmooCon slide deck: github.com/actuator/pSlip