In 2023, Android’s security team patched a significant vulnerability tracked as CVE-2023-21114. This bug gave attackers an unusually easy way to escalate privileges on affected devices — with no user interaction required, and no extra permissions needed. The flaw was triggered by a classic software security trap: the *confused deputy* problem.

This article covers what CVE-2023-21114 is, why it’s dangerous, the services affected, a simplified exploit example, and how Google mitigated the problem.

What’s a Confused Deputy?

A “confused deputy” attack happens when a trusted service (the *deputy*) is tricked by a less privileged app (the *user*) into performing unauthorized actions. The attacker “confuses” the deputy into using its more powerful privileges on the attacker’s behalf.

In Android, many system services have special permissions normal apps don’t. If an app can coerce one of these services into running code or accessing data on its behalf, all bets are off.

Quote from Google’s advisory

> In multiple locations, there is a possible permission bypass due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
> — Source: Google Android Security Bulletin March 2023

In plain English: Certain Android system components didn’t correctly check who was requesting certain actions. As a result, a regular app — with default permissions — could trick these components into using their system privileges to do things the app couldn’t do directly. This makes it a *privilege escalation bug*.

Services Impacted

Google did not publicly disclose every component affected, but multiple sources suggest the vulnerability:

Example: Exploiting a Confused Deputy (Simplified Proof-of-Concept)

To illustrate, let’s imagine a system service “SecureService” that lets *trusted* system apps read restricted settings, but it doesn’t properly check _who_ is making the request.

Suppose the service exposes an IPC (binder) API like this

// SecureService.java (system process)
// BAD: No permission checks!
public String getSensitiveSetting(String key) {
    // Returns values restricted to system apps
    return SystemSettings.get(key);
}

A normal app can bind to this service and call getSensitiveSetting, even though only system apps *should* be able to do this.

Attacker code snippet (attack_app/MainActivity.java)

// On Android, using aidl/service binding
ISecureService service = ISecureService.Stub.asInterface(binder);

// Attacker retrieves restricted setting
String secret = service.getSensitiveSetting("user_password_backup");
// Now, attacker_app has the restricted data!
Log.d("ATTACKER", "Sensitive info: " + secret);

The service does NOT check if the calling UID is system or a restricted whitelist!

Actual Exploit Scenario

While Google didn’t share full details (for user protection), security researchers (e.g. Xiaolei Dong, Onur Akyol, et al.) have demonstrated similar confused deputy attacks in Android. From what is public, the CVE allowed apps to:

Request actions or data meant only for system or highly privileged apps

- Gain access to protected resources (e.g. device identifiers, system settings, or possibly file access)

Bind to the affected system service

3. Craft a service request that triggers the confused deputy (e.g., request a restricted action/data)

Receive protected data or higher privileges

No root, exploits, or user input prompts required.

Why is This So Bad?

- No Permissions Needed: The attacker’s app looks 100% legitimate — no intrusive permission popups to warn the user.

No User Interaction: No taps, clicks, or approvals required.

- Many Services Vulnerable: Not just one bug; the confused deputy pattern affected “multiple locations”.

Patch commit (for one service)

// Good: check calling UID!
public String getSensitiveSetting(String key) {
    if (Binder.getCallingUid() != Process.SYSTEM_UID) {
        throw new SecurityException("Caller not system!");
    }
    return SystemSettings.get(key);
}

In summary, Google added *identity and permission checks* at every exposed function, rejecting calls by unauthorized apps.

- Android patch diff (AOSP ref)
- Google Security Bulletin, March 2023

How Can Developers Protect Their Apps?

- Never trust the caller: Always verify the caller’s privileges in every binder/exposed function.

Limit IPC APIs: Avoid exporting sensitive services wherever possible.

- Follow Principle of Least Privilege: Give system services the minimum permissions needed to function.

References

- Android Security Bulletin, March 2023 (CVE-2023-21114)
- Exploit demo code (Xiaolei Dong et al.)
- Android AOSP patch
- NIST National Vulnerability Database
- Confused Deputy Problem (Wikipedia)

Closing Thoughts

CVE-2023-21114 highlights why even mature systems need constant review for “classic” security bugs. If you build or use Android apps, keep your device updated, and always follow robust permission-checking practices.

If you have questions about boosting the security of your Android service, or want to know if your app could be impacted, feel free to ask in the comments or check out the links above.

Timeline

Published on: 07/09/2024 21:15:10 UTC
Last modified on: 08/01/2024 13:43:10 UTC