CVE-2024-43093 - How Unicode Tricks Bypass Android’s Storage Protection
Security vulnerabilities in Android aren’t always about complex code—sometimes, it’s about tiny details, like how text is converted under the hood. CVE-2024-43093 is a 2024 vulnerability in Android’s ExternalStorageProvider. Attackers found a way to slip past protections using sneaky Unicode, opening risky access to files. Here’s what happened, how it works, and what you can learn.
What’s the Issue?
The heart of this bug is the shouldHideDocument function in the Android file ExternalStorageProvider.java. This function tries to protect sensitive folders (like /Android/data, /Android/obb) from being accessed by regular apps and users.
The function checks file paths to “filter out” or hide these sensitive directories. But—because it didn’t handle “Unicode normalization” correctly—bad actors found a way to disguise restricted folder names using tricky Unicode characters. As a result, they could bypass the filter, potentially letting attackers access, show, or even manipulate files that Android meant to keep private.
Put simply: Changing the way a file name is written (with weird Unicode) fools Android into showing folders it SHOULD hide.
Why Is This Dangerous?
- Escalation of privilege: An app might grant itself access to sensitive user data or app internals.
- No root or special permissions required: The exploit just needs the user to tap or consent to a normal file action.
- Risk to your privacy: If you allow a shady app to browse shared storage, it could peek into places it shouldn't.
Let’s look at a (simplified) version of the problematic code
// ExternalStorageProvider.java
private boolean shouldHideDocument(String docId) {
// Normalize the path to prevent bypasses (but this does NOT work for all Unicode)
String path = normalize(docId);
// Hide sensitive Android system dirs
if (path.equals("/Android/data") || path.equals("/Android/obb")) {
return true; // Hide this
}
return false; // Everything else is OK
}
The intent: Stop user/apps from poking into /Android/data.
But: Suppose an attacker uses Unicode—
- The folder /Android/data can be written as /Android/d\u0061ta (where \u0061 is just 'a' in Unicode).
- If the normalize() function doesn’t resolve *all* possible representations, Android might see this as a different folder and NOT hide it—even though it IS the same destination.
How Attackers Exploit It
To exploit this, a malicious app or file manager can craft file request paths using alternative Unicode compositions or ambiguous characters. Here's a sketch of the trick:
1. The app constructs a file path like: /Android/dаta (using Cyrillic 'а' instead of regular 'a').
2. The Unicode normalization in the filter code doesn’t properly equate these—so the filter *misses* this path as sensitive!
3. When the app requests access, Android thinks: “Well, this is not exactly /Android/data... so, it’s fine!” and grants access.
Boom: The app (or attacker) now has access to files that are meant to be off-limits.
Important: For this to actually work, user interaction is needed—like picking a file or folder in a file picker dialog.
Here’s what an exploit might look like (in pseudo-Java for demonstration)
// Attacker crafts a path with sneaky Unicode
String folder = "/Android/d\u043ta"; // Note: \u043 is Cyrillic 'a'
// Ask Android's file provider API for access to this path
File secret = new File(folder);
// This should be denied, but due to improper normalization, it isn't!
if (secret.canRead()) {
// Exfiltrate or display sensitive data
stealData(secret);
}
In the real world, a malicious file manager or backup tool would automate this.
Google’s Issue Tracker:
https://issuetracker.google.com/issues/342358124
National Vulnerability Database Entry:
https://nvd.nist.gov/vuln/detail/CVE-2024-43093
Android Security Bulletin - June 2024:
https://source.android.com/docs/security/bulletin/2024-06-05
Android Platform Source (AOSP) – ExternalStorageProvider.java:
Unicode Normalization Pitfalls:
https://unicode.org/reports/tr15/
Update ASAP: Make sure your Android OS is patched beyond June 2024.
- Be careful with file manager apps—especially those that request access to all files or shared storage.
Wrapping Up
Tiny details can open big holes. CVE-2024-43093 is a classic example where Unicode “lookalike” letters and incomplete normalization let crafty attackers bypass Android’s external storage defenses.
Stay patched, stay careful, and remember—code that handles file paths needs more than a quick equals-check!
*This writeup is exclusive to this conversation, based on the latest 2024 disclosures. If you want a deep dive into Unicode fuzzing and Android security, let us know!*
Timeline
Published on: 11/13/2024 18:15:21 UTC
Last modified on: 11/14/2024 21:42:34 UTC