Android security is always in the spotlight, but sometimes small checks make all the difference. CVE-2022-20004 is one such bug, hiding in the SliceManagerService.java file of Android 10, 11, 12, and 12L. This wasn't about flashy remote code execution, but instead a sneaky way for local attackers to access things they shouldn't. Let’s break it down, see how it works, and look at the code that caused the fuss.

What Is CVE-2022-20004?

CVE-2022-20004 is a vulnerability that lets a local user — meaning apps or code already running on a device — to bypass protections and access _any_ slice URI. In security talk, a slice URI is a way for apps to share neat chunks of content, called “Slices,” in a structured and secure way... at least, it’s supposed to be secure.

The root cause? Improper input validation in the checkSlicePermission() function of SliceManagerService.java.

Impact

- Who can exploit? Anyone with a local app or process. NO extra permissions or user interaction needed.
- What can it lead to? Local privilege escalation — so a basic app could get data or perform actions it’s supposed to be blocked from.

Official Google ID: A-179699767

Note: This bug doesn't give instant root or full device compromise, but it allows an app to jump past lockouts and access protected Slices it’s supposed to be denied.

A Quick Slices Primer

Android Slices are UI templates that let an app expose pieces of its data or actions for use by other apps (think: quick toggles, smart replies, live widgets). These are accessed by content URIs, which are supposed to be protected by permissions.

Where It Goes Wrong

In the SliceManagerService, the function checkSlicePermission() is responsible for making sure only apps with the right permissions can see or use each slice based on its URI.

The Bug: The permission check is faulty. A malicious app could ask for a slice it wasn’t supposed to touch, and the service would just hand the data over because it didn’t properly check if the requesting app truly had permission to access the provided URI.

The Guilty Code (Simplified Snippet)

Here’s a simplified version inspired by the real SliceManagerService.java code (not the full source):

public int checkSlicePermission(Uri uri, String pkg, int pid, int uid, String autoGrantPkg) {
    // ... some setup code ...

    // <-- Missing: strict validation if 'pkg' matches 'uid' or really has access to 'uri'

    if (hasPermission(pkg, "com.android.slice.permission.SLICE")) {
        return PERMISSION_GRANTED;
    }
    // ... other checks ...
    return PERMISSION_DENIED;
}

But the bug was: hasPermission and other checks didn’t _really_ make sure the requesting app, by UID/pid, was tied to that package or could access that URI. So a rogue app could claim to be anyone and access sensitive slice data.


## Potential Attack/Exploit Scenario

Make a malicious app and install it on a target device.

2. Craft a request to SliceManagerService for a forbidden slice URI, pretending to be some authorized package.
3. Service grants it! Due to lack of strict validation, the malicious app gets access — as if it had privileges it shouldn’t.

Example Exploit Pseudocode

Uri secretSlice = Uri.parse("content://slices/authority/confidential");
Intent intent = new Intent();
intent.setAction("com.android.intent.action.REQUEST_SLICE");
intent.setData(secretSlice);
intent.setPackage("com.android.settings"); // spoofing a trusted app!

context.sendBroadcast(intent);
// The service does not correctly check if this call is legit...

Result: The app gets data (or the ability to interact) it’s not really cleared for.

Official References and Patch Info

- Android Security Bulletin: 2022-01-01
- CVE-2022-20004 at NVD
- Google Issue Tracker A-179699767
- AOSP commit fixing checkSlicePermission vulnerability

Mitigation

Google’s patch added tighter input validation, making sure apps can’t spoof their identity or access slices they haven’t been allowed. The core fix was tying the permission check _strictly_ to app UID and true package ownership.

Conclusion

CVE-2022-20004 is a classic case of “just enough” security not being enough at all. The lesson? Always validate every input and check that requesters really are who they say!

If your device is running Android 10, 11, 12 or 12L — make sure you’re up to date with security patches. Modern Android already has this fixed, but older devices are at risk until updated.

Timeline

Published on: 05/10/2022 20:15:00 UTC
Last modified on: 05/16/2022 16:19:00 UTC