CVE-2024-31316 AI-generated analysis
platform/frameworks/base, services/core AccountManagerService (accounts)
Adds a second checkKeyIntent() check of the result Bundle returned by the authenticator in two result-handling paths of AccountManagerService. The check runs after the Bundle has been modified (KEY_AUTHTOKEN removed) and rejects the response with ERROR_CODE_INVALID_RESPONSE if the intent fails it.
Root cause
In AccountManagerService.java, result handlers receive a result Bundle from an account authenticator and modify it before forwarding it to the caller's response. Both paths remove KEY_AUTHTOKEN; the first path also removes KEY_PASSWORD when !mIsPasswordForwardingAllowed. The commit message says another verification is needed after Bundle modification: checkKeyIntent() was not run again after these modifications. The location of the original checkKeyIntent call is not in the material.
How the fix works
- services/core/java/com/android/server/accounts/AccountManagerService.java, first result handler (around line 3612 in the fix, line 3727 at android-security-14.0.0_r29). This handler later processes KEY_ACCOUNT_SESSION_BUNDLE. Right after result.remove(AccountManager.KEY_AUTHTOKEN), the fix adds `if (!checkKeyIntent(Binder.getCallingUid(), result))`. On failure it calls onError(AccountManager.ERROR_CODE_INVALID_RESPONSE, "invalid intent in bundle returned") and returns, so the result is not forwarded.
- Same file, second result handler (around line 5201): inside the `if (mStripAuthTokenFromResult)` branch, right after result.remove(AccountManager.KEY_AUTHTOKEN), the fix adds the same checkKeyIntent() guard with the same onError and return on failure.
- Both changes are pure additions (10 lines). checkKeyIntent itself and the earlier validation are not changed.
Completeness
- Covers the two paths where KEY_AUTHTOKEN is removed from the result Bundle before forwarding. In each path the new check sits directly after the modification.
- In the second path the new check is only inside the `if (mStripAuthTokenFromResult)` branch. When mStripAuthTokenFromResult is false, no new check is added. The rest of the surrounding code is not shown.
- In the first path, the check comes before the later handling of the nested KEY_ACCOUNT_SESSION_BUNDLE (putString of KEY_ACCOUNT_TYPE and encryption at r29 lines 3742-3754). In the shown context the top-level result is not modified again after the check.
- The checkKeyIntent() implementation and the original validation site are not in the material, so it cannot be judged whether other forwarding paths lack a check after modification.
Behavior changes
- If an authenticator response's KEY_INTENT fails checkKeyIntent() after the auth token is removed, the caller now gets onError(ERROR_CODE_INVALID_RESPONSE, "invalid intent in bundle returned") instead of the result.
- No change for responses without an intent or with an intent that passes checkKeyIntent().
Per major
- Android 14: same fix: commit 3c59b877099d in android-security-14.0.0_r9 (cherry-pick of 36db8a1d61a8, Change-Id I9e45d758a2320328da5664b6341eafe6f285f297); all 7/7 patched lines present at android-security-14.0.0_r29.
- Android 15: not affected (not listed by the bulletin); patched region present (7/7 lines) at android-security-15.0.0_r17.
- Android 16: not affected (not listed by the bulletin); patched region present (7/7 lines) at android-security-16.0.0_r8.
- Android 17: not affected (not listed by the bulletin); patched region present (7/7 lines) at android-security-17.0.0_r1.
Unknowns
- Where the original checkKeyIntent() call is and what it does, and the body of checkKeyIntent() itself.
- Why modifying the Bundle makes the earlier check invalid: the commit message states it but the mechanism is not shown.
- Whether and how the fix was applied to the Android 12, 12L and 13 branches.
- Names of the classes and methods that contain the two patched code paths.