Bundle， 是 Android 用于数据传递的一种特殊的键值对容器类型，通常用于 Android 进程间通信。

Bundle Mismatch 则利用序列化和反序列化不一致的差异绕过系统校验，获取以系统权限启动任意 Activity 的能力（LaunchAnyWhere）。

为了彻底解决 Bundle Mismatch 问题，Google 设计了一套名为 Lazy Bundle 的补丁。该补丁调整了不定长类型的序列化结构，在类型之后、具体数据之前，增加了一个数据块的长度字段。

AOSP 的源码注释中标注了相应的数据结构和 LazyValue 的参数以便人们理解，其中 mPosition 和 mLength 即 LazyValue 记录的偏移和长度。

Lazy Bundle 于 2022 年推出的 Android 13 中实装。

如此一来，即使某个类型存在 Mismatch，Bundle 其他键值对的内容也不会受影响，缓解了 Bundle Mismatch 的利用。

Bundle Mismatch 利用的作者是 Michal Bednarski（@BednarTildeOne）。自 2017 年起，他在 GitHub 上分享了多种 Android 反序列化漏洞的利用和 writeup。

这一次，他不仅找到了 LazyValue 实现中存在的 UAF 漏洞，随后更是发现了一个可以绕过 Lazy Bundle 缓解措施的漏洞 "TheLastBundleMismatch (CVE-2023-21098、CVE-2023-45777)" ，在 Android 13 和 14 上成功重现了 LaunchAnyWhere 攻击。

通过分析 CVE-2023-45777 的补丁容易发现，TheLastBundleMismatch 漏洞在于 AccountManagerService 读取 intent 字段时并没有显式指定 getParcelable 的类型参数。

diff --git a/services/core/java/com/android/server/accounts/AccountManagerService.java b/services/core/java/com/android/server/accounts/AccountManagerService.java
index 7a19d034c2c8..5238595fe2a2 100644
--- a/services/core/java/com/android/server/accounts/AccountManagerService.java
+++ b/services/core/java/com/android/server/accounts/AccountManagerService.java
@@ -4923,7 +4923,7 @@ public class AccountManagerService
             p.setDataPosition(0);
             Bundle simulateBundle = p.readBundle();
             p.recycle();
-            Intent intent = bundle.getParcelable(AccountManager.KEY_INTENT);
+            Intent intent = bundle.getParcelable(AccountManager.KEY_INTENT, Intent.class);
             if (intent != null && intent.getClass() != Intent.class) {
                 return false;
             }

该漏洞的利用和 LazyValue 的实现弱点有关。

当一个 Bundle 重新序列化时，尚未被读出的 LazyValue 会使用 appendFrom直接将其指向的对应数据块（包括开头的 type 和 length 两个字段）复制到新的 parcel 中。

乍一看，这种处理方式似乎没有什么不妥之处，但如果攻击者有能力修改旧 parcel 中 type 和 length 两处数据，让 LazyValue 复制改动后的数据，事情就变得不一样了：

在 Bundle 下一次被反序列化时，修改的 type 可以让这个 LazyValue 不再 “lazy”，从而改变读取后续键值对的位置，读出原本不存在的键，实现 Lazy Bundle 的绕过；修改 length 也可以达到同样的效果。

那么问题就转化为，是否存在这样一个 Parcelable 类型，其在反序列化的过程中会修改原始 parcel 的数据？

这种类型（至少在 AOSP 中）并不存在。

不过 @BednarTildeOne 找到了一个等效的组合：android.os.PooledStringWriter 和 android.content.pm.PackageParser$Activity。

• 前者并非 Parcelable 类型，但是却可以接受 Parcel 类型作为构造函数的参数。作为一个 “writer”，它向传入的 parcel 调用了 writeInt(0) 的写入操作。

• 后者是一个 Parcelable，在反序列化时可以使用反射调用任意类型的构造函数，并传入 parcel 对象，实现了和 PooledStringWriter 的串联。

如果构造数据让写入的 0 覆盖 LazyValue 的 type，就能让 Bundle 下一次反序列化时将这个 LazyValue 解释成字符串类型，绕过缓解措施。

美中不足的是，PackageParser$Activity 会将反射构造的结果转换为 IntentInfo 类型，不可避免地导致类型转换异常。因此需要寻找另一个包含异常处理的 Parcelable，在它反序列化的 try-catch 流程中进行 PackageParser$Activity 和 PooledStringWriter 的反序列化。

这一次 AOSP 既不存在这样的 Parcelable，也不存在其他的等效组合。这可能要归功于上文提到的 Android 13 新增限制类型的 Parcel 方法，即使有少数几个 Parcelable 使用了异常处理，也无法控制它们去反序列化我们想要的类型。

AOSP 中不存在，不代表其他厂商 OEM 系统中不存在。

在 2022 年度最“不可赦”的漏洞利用 中，我们介绍了一个三星 OEM 的漏洞利用链。这次 @BednarTildeOne 也是在三星中发现了 SemImageClipData 类型完美满足利用要求。

事情结束了吗？

还差最后一小步。 

如果直接在 intent 字段放一个 SemImageClipData 类型，反序列化的结果会被 AccountManagerService 强制转换为 Intent，再次出现异常。bundle.getParcelable 内部实际上有一层类型转换的错误处理，只要把 SemImageClipData 套一层数组成为 Parcelable[]，函数最终就可返回null。

至此，整个攻击利用链大功告成，其复杂程度和精妙程度令人叹为观止。

只可惜 SemImageClipData 这种类型不可多得。DARKNAVY 在尝试对国内品牌的旗舰机型复现漏洞时，并不能找到相似的替代品。

考虑到漏洞的核心在于反序列化时对 parcel 的修改操作，我们放弃 PooledStringWriter 和 PackageParser$Activity 的组合拳，去寻找反序列化时直接修改 parcel、并且不会触发异常的类型。

最终我们找到一个 Parcelable，直接调用 unmarshall 修改了整个 parcel 的数据，借此成功完成了复现。

在复现中，我们利用漏洞分别启动了修改密码的页面和 Android 14 的彩蛋页面。这两个页面分别是设置应用和安卓系统本身的未导出 Activity。

该机型最新版本上已经修复此漏洞。值得一提的是，我们利用的这个 Parcelable 并非第一次出现在该品牌的手机中。在其他机型的 Android 12 上，我们就发现过它的存在。

而，TheLastBundleMismatch 在 Android 12 及之前并不能被利用：

原本 parcel 的读取是线性的，如果读取的途中修改了 parcel 数据，也只能在新旧数据之间二选一读到。LazyValue 的出现改变了这种线性，也让这个潜藏多年的类型能够被利用。

明日，请继续关注《深蓝洞察 | 2023 年度安全报告》第六篇。