CVE-2024-40676 AI-generated analysis
platform/frameworks/base, services/core AccountManagerService (account authenticator KEY_INTENT validation)
AccountManagerService.checkKeyIntent now rejects authenticator-supplied KEY_INTENT Intents whose data URI scheme is "content", returning false before the resolved activity is accepted.
Root cause
checkKeyIntent(int authUid, Bundle bundle) in services/core/java/com/android/server/accounts/AccountManagerService.java is the policy gate for Intents that an account authenticator supplies under AccountManager.KEY_INTENT. Its doc comment says the goal is to stop an authenticator from tricking users into launching arbitrary intents. Before the fix, the method checked the parcel shape (checkKeyIntentParceledCorrectly), set an empty ClipData so that no URIs inside it would be promoted for grants, resolved the activity, and required the target to be either an exported system activity or signature-compatible with the authenticator. It never inspected the Intent's own data URI. An Intent with a "content" scheme data URI therefore passed the check and was stored back into the bundle (bundle.putParcelable(KEY_INTENT, intent)) with its component pinned to the resolved activity.
How the fix works
- services/core/java/com/android/server/accounts/AccountManagerService.java:checkKeyIntent: three lines are added after the pm.resolveActivityAsUser(...) null check and before resolveInfo.activityInfo is read: if ("content".equals(intent.getScheme())) return false;. Any KEY_INTENT whose data URI scheme is content is now rejected, whichever activity it resolves to and whether or not the target shares a signature with the authenticator.
- No other code is changed. The existing ClipData reset, activity resolution, isExportedSystemActivity / hasSignatureCapability checks and component pinning stay as they were.
Completeness
- The check is a single exact string comparison on intent.getScheme(), so only the data URI scheme is examined. Intents with no data URI, or with any other scheme, are unaffected and still go through the existing target-activity checks.
- The check sits after resolveActivityAsUser. An Intent that does not resolve already returned false, so the new rule only adds a rejection for resolvable content-scheme Intents.
- Only checkKeyIntent is modified. The material does not show whether every consumer of KEY_INTENT in AccountManagerService goes through checkKeyIntent.
- The parceling check just above the new code writes an EventLog 0x534e4554 entry when it rejects. The new rejection writes no log or event.
Behavior changes
- checkKeyIntent now returns false for a KEY_INTENT carrying a content:// data URI, even when the target activity is a system activity or shares the authenticator's signature.
- The new rejection path adds no log, exception or error code.
Per major
- Android 14: same fix: commit e8a53246607b (cherry-pick of c1e79495a49b, Change-Id I8b23191d3d60036ca7ddf0ef7dcba6b38fb27b3c) in android-security-14.0.0_r13. At android-security-14.0.0_r29, 4/4 lines of the patched region are present.
- Android 15: not affected (per the bulletin). At android-security-15.0.0_r17, 4/4 lines of the patched region are present.
- Android 16: not affected (per the bulletin). At android-security-16.0.0_r8, 4/4 lines of the patched region are present.
- Android 17: not affected (per the bulletin). At android-security-17.0.0_r1, 3/4 lines of the patched region are present. The material does not show which line differs or why.
Unknowns
- What a content-scheme KEY_INTENT specifically allowed when launched. The bulletin gives only High / EoP, and the commit message only says 'Block intents with content data scheme'.
- What callers do when checkKeyIntent returns false, which callers in AccountManagerService consume KEY_INTENT, and whether all of them go through checkKeyIntent.
- Which line of the patched region differs at android-security-17.0.0_r1, and why.
- Whether Android 12, 12L and 13 (listed as affected by the bulletin) received the same change. The material only covers Android 14 and later.