Exploiting Android Share Targets: The Dirty Stream Attack

TLDR: The Dirty Stream attack exploits insecure file-sharing mechanisms in Android apps by manipulating Content Providers and File Providers to achieve arbitrary file read/write and remote code execution. Attackers can force a target application to overwrite its own critical files or expose sensitive data by sending malicious intents. Security researchers and pentesters should focus on auditing how applications handle incoming file paths and display names from external sources to prevent these unauthorized file operations.

Android’s sandboxing model is often treated as a silver bullet, but the reality is that inter-app communication remains a massive, often overlooked, attack surface. The Dirty Stream attack is a perfect example of how a seemingly benign feature—sharing files between applications—can be weaponized to bypass the very security boundaries that developers rely on. This isn't a theoretical edge case; it is a fundamental flaw in how many high-install-base applications handle data from external sources.

The Mechanics of the Dirty Stream

At its core, the Dirty Stream attack exploits the trust relationship between a "Share Target" and the data it receives. Android applications often use Content Providers to share data. When an application acts as a Share Target, it essentially opens its doors to receive data or files from other apps. The vulnerability arises when the target application fails to properly validate the file paths or the display names provided in the incoming intent.

The attack flow is straightforward but devastating. An attacker crafts a malicious Android application that, when installed on the same device as the target, initiates a share operation. By manipulating the Intent data, the attacker can perform path traversal. If the target application blindly trusts the display_name or the file path provided in the intent, it may inadvertently overwrite its own critical files—such as native libraries, DEX files, or configuration files—with malicious payloads provided by the attacker.

Consider the following scenario. A target application expects a file to be shared. The attacker’s app sends an intent that points to a sensitive location within the target's private data directory. If the target application uses a standard copy operation without sanitizing the destination path, it will write the attacker's file into its own sandbox. Once that file is overwritten, the target application might load it during its next execution, leading to arbitrary code execution within the context of the target app.

Technical Deep Dive: Path Traversal and Overwrites

The vulnerability often manifests in the query or openFile methods of a custom ContentProvider. Developers frequently implement these methods to handle incoming data streams. A common, yet dangerous, pattern looks like this:

// Vulnerable implementation pattern
public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) {
    String fileName = getFileNameFromUri(uri); // Unsafe extraction
    // ... logic that uses fileName to open or write a file
}

When the fileName is extracted directly from the URI without validation, an attacker can inject path traversal sequences like ../../. If the application then uses this path to save a file to its internal storage, it effectively escapes its intended directory.

The OWASP Mobile Top 10 highlights M1: Improper Platform Usage as a primary concern, and Dirty Stream is a textbook example of this. The lack of strict input validation on the display_name parameter—which is often used to construct the final file path—allows an attacker to control the destination of the file operation.

Real-World Applicability for Pentesters

During a mobile penetration test, you should prioritize auditing any application that registers itself as a share target. Look for intent-filter declarations in the AndroidManifest.xml that handle ACTION_SEND or ACTION_SEND_MULTIPLE. Once you identify these, use Ghidra to decompile the application and trace how the Intent data is processed.

Specifically, look for:

1. Custom Content Providers: Are they implementing openFile or query?
2. Path Sanitization: Is there any logic that checks if the resolved file path is within the expected directory?
3. File Overwrites: Does the app perform any file operations based on the display_name or other metadata provided by the sender?

If you find that an application caches incoming files to a shared directory or uses the display_name to save files, you have a high-probability path to exploitation. The impact is significant: you can potentially replace legitimate assets with malicious ones, leading to full application compromise.

Defensive Strategies

Defending against this requires a shift in mindset: treat all data originating from outside your application's private sphere as untrusted. If you must support file sharing, never use the display_name or any path provided by the sender to construct a file path on your local storage. Instead, generate a unique, random filename for every incoming file and store it in a dedicated, isolated cache directory.

Furthermore, always validate the canonical path of any file operation. Ensure that the final destination is strictly within your application's designated cache folder. If you are using FileProvider, ensure your provider_paths.xml is configured correctly and does not expose sensitive directories.

The Dirty Stream attack serves as a stark reminder that even well-architected applications can be undermined by simple, insecure inter-app communication patterns. As researchers, we need to keep digging into these IPC mechanisms. The next time you are testing an Android app, don't just look for API keys or hardcoded credentials; look at how the app talks to the rest of the system. You might find that the most dangerous path is the one the developer thought was safe.