CVE-2024-43089 AI-generated analysis
platform/packages/providers/MediaProvider, MediaProvider.update (file placement / rename path)
Adds an enforceCallingPermission(uri, extras, true) call before the shared `break` of the movement switch in MediaProvider.java (visible cases IMAGES_MEDIA_ID, DOWNLOADS_ID, FILES_ID), so that the caller's permissions to do placement are checked before a file rename/move through MediaProvider.update.
Root cause
In MediaProvider.java, a switch that decides whether a URI type may be "moved" (otherwise it throws IllegalArgumentException "Movement of " + uri) accepted cases including DOWNLOADS_ID and FILES_ID without checking the caller's permissions to do placement. Per the commit message, malicious apps could use MediaProvider.update to rename files in the lower file system that they had no access to. They could not update the MediaProvider DB this way. But they could create fake records in the DB and then rename the file to the same name as their record, which gave them access to the file. Per the commit message, IMAGES_MEDIA_ID, AUDIO_MEDIA_ID and VIDEO_MEDIA_ID URIs were already guarded, and this fix covers all other Media URIs.
How the fix works
- src/com/android/providers/media/MediaProvider.java, movement switch in the update path: before the `break` shared by the visible cases IMAGES_MEDIA_ID, DOWNLOADS_ID and FILES_ID, the fix adds a call to `enforceCallingPermission(uri, extras, true)`, with the comment 'Check if the caller has the required permissions to do placement'. The `default` branch still throws IllegalArgumentException for URI types that may not be moved.
Completeness
- Covers the movement switch in the update path for the case labels that share the patched `break`. Other URI types already threw in the `default` branch.
- The fix is one call site. The material does not show other rename/move entry points (e.g. FUSE-driven renames or other update sub-paths), so whether they have equivalent checks cannot be judged from the material.
- The exact semantics of the third argument (`true`) to enforceCallingPermission are not shown in the material.
Behavior changes
- MediaProvider.update requests that imply a file move/rename for the affected URI types (e.g. DOWNLOADS_ID, FILES_ID) now go through enforceCallingPermission first. If the caller lacks the required permissions, the request fails instead of renaming the file in the lower file system. The exact exception type is not shown in the material.
- Callers that pass the permission check should see no change.
Per major
- Android 14: same fix: commit 33ff6a663eea (cherry-pick of d3d22856bfd4, Change-Id I91e9966c012fe292cebc0b544f77032613516fac) merged in android-security-14.0.0_r14; 3/3 patched lines present at android-security-14.0.0_r29.
- Android 15: not affected per the bulletin; patched region present (3/3 lines) at android-security-15.0.0_r17.
- Android 16: not affected per the bulletin; patched region present (3/3 lines) at android-security-16.0.0_r8.
- Android 17: not affected per the bulletin; patched region present (3/3 lines) at android-security-17.0.0_r1.
Unknowns
- The enclosing method name of the patched switch is not shown in the hunk header (only the class is shown).
- Which case labels precede IMAGES_MEDIA_ID in the same group is not shown.
- The implementation of enforceCallingPermission, the meaning of its third boolean argument, and which exception it throws are not in the material.
- Where the existing guard for IMAGES/AUDIO/VIDEO_MEDIA_ID lives, and whether other rename entry points exist, is not shown.
- Only 'Test: Manual' is recorded; no regression test is included in the commit.