CVE-2024-49724 AI-generated analysis

platform/frameworks/base, services/core AccountManagerService (accounts)

AI-generated: written from the bulletin and the fixing diffs by claude-fable-5-1, then checked against the code by claude-opus-5-5 (7 corrections). Verify against the commit before relying on it.

Hardens AccountManagerService's validation of an authenticator-supplied KEY_INTENT. After the target activity passes the signature/exported-system check, the intent is explicitly pinned to the resolved component and written back into the result bundle. The exact Intent class check in checkKeyIntentParceledCorrectly now applies to both the original and the re-parceled intent.

Root cause

In AccountManagerService checkKeyIntent, the KEY_INTENT was resolved via pm.resolveActivityAsUser(intent, 0, mAccounts.userId) and the resolved ActivityInfo was checked (isExportedSystemActivity or hasSignatureCapability with authUid, CertCapabilities.AUTH). On success the method returned true but left the intent in the bundle unchanged, so the delivered intent was not pinned to the component that had been validated. Separately, in checkKeyIntentParceledCorrectly only the original intent was required to be exactly Intent.class. The re-parceled simulateIntent was only compared via filterEquals, so an Intent subclass on the re-parceled side was not rejected.

How the fix works

• services/core/java/com/android/server/accounts/AccountManagerService.java:checkKeyIntent: after the targetActivityInfo check passes, the fix calls intent.setComponent(targetActivityInfo.getComponentName()) and bundle.putParcelable(AccountManager.KEY_INTENT, intent) before returning true. The bundle therefore carries an explicit intent targeting the validated activity.
• services/core/java/com/android/server/accounts/AccountManagerService.java:checkKeyIntentParceledCorrectly: the early `intent != null && intent.getClass() != Intent.class` check is removed. After the null handling (`intent == null` returns `simulateIntent == null`), a new check returns false if either intent.getClass() or simulateIntent.getClass() is not exactly Intent.class, before the filterEquals comparison.

Completeness

• Covers both the pinning of the validated component into the delivered intent and the symmetric class check on the re-parceled intent, within the single file touched.
• The existing checks in checkKeyIntent are unchanged by this fix: null intent accepted, empty ClipData set, null resolveInfo rejected, "content" scheme rejected, and an exported system activity or AUTH signature capability required.
• The new check in checkKeyIntentParceledCorrectly dereferences simulateIntent without a null check. If intent is non-null and simulateIntent is null, this now throws NullPointerException where the old code fell through to intent.filterEquals(simulateIntent). Whether that state is reachable is not shown in the material.
• Only the KEY_INTENT path in AccountManagerService is touched; the material shows no other paths.

Behavior changes

• Result bundles validated by checkKeyIntent now contain an explicit-component intent (component set to the resolved activity) instead of whatever component the authenticator supplied.
• checkKeyIntentParceledCorrectly now returns false when the re-parceled intent is an Intent subclass, not only when the original is.
• Potential NullPointerException in checkKeyIntentParceledCorrectly if the original intent is non-null but the re-parceled one is null (previously that case reached filterEquals).

Per major

• Android 14: same fix: platform/frameworks/base 985bdc676ac5 in android-security-14.0.0_r16 (cherry-pick, Change-Id Ied7961c73299681aa5b523cf3f00fd905893116f). At android-security-14.0.0_r29 the setComponent/putParcelable lines are present (7/8 patched-region lines present).
• Android 15: same fix: platform/frameworks/base 5018e2273cb3 in android-security-15.0.0_r4, identical hunks at shifted line numbers; 7/8 patched-region lines present at android-security-15.0.0_r17.
• Android 16: not affected (not listed by the bulletin); 7/8 lines of the patched region present at android-security-16.0.0_r8.
• Android 17: not affected (not listed by the bulletin); 7/8 lines of the patched region present at android-security-17.0.0_r1.

Unknowns

• Which callers of checkKeyIntent/checkKeyIntentParceledCorrectly are involved; the material does not show them.
• Why 7/8 rather than 8/8 patched-region lines match in the latest tags.
• Whether the simulateIntent-null state in checkKeyIntentParceledCorrectly is reachable in practice.
• How the pre-fix behavior could be abused; the bulletin only states EoP, High.
• The state of this code on Android 12, 12L and 13, which the bulletin lists as affected.

Back to January 2025 · Findings