序列化和反序列化是指將內(nèi)存數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換為字節(jié)流，通過網(wǎng)絡(luò)傳輸或者保存到磁盤，然后再將字節(jié)流恢復(fù)為內(nèi)存對象的過程。在 Web 安全領(lǐng)域，出現(xiàn)過很多反序列化漏洞，比如 PHP 反序列化、Java 反序列化等。由于在反序列化的過程中觸發(fā)了非預(yù)期的程序邏輯，從而被攻擊者用精心構(gòu)造的字節(jié)流觸發(fā)并利用漏洞從而最終實現(xiàn)任意代碼執(zhí)行等目的。

Android 中除了傳統(tǒng)的 Java 序列化機制，還有一個特殊的序列化方法，即?Parcel[1]。根據(jù)官方文檔的介紹，Parcelable 和 Bundle 對象主要的作用是用于跨進程邊界的數(shù)據(jù)傳輸(IPC/Binder)，但 Parcel 并不是一個通用的序列化方法，因此不建議開發(fā)者將 Parcel 數(shù)據(jù)保存到磁盤或者通過網(wǎng)絡(luò)傳輸。

作為 IPC 傳輸?shù)臄?shù)據(jù)結(jié)構(gòu)，Parcel 的設(shè)計初衷是輕量和高效，因此缺乏完善的安全校驗。這就引發(fā)了歷史上出現(xiàn)過多次的 Android 反序列化漏洞，本文就按照時間線對其進行簡單的分析和梳理。

注: 本文中所展現(xiàn)的 AOSP 示例代碼，如無特殊說明則都來自文章發(fā)表時的 master 分支。

Parcel 101

在介紹漏洞之前，我們還是按照慣例先來了解下基礎(chǔ)知識。對于有過 Android 開發(fā)或者逆向分析經(jīng)驗的同學應(yīng)該對 Parcel 都不陌生，但通常也很少直接使用該類去序列化/反序列化數(shù)據(jù)然后進行 IPC 通信，而是通過 AIDL 等方法去自動生成模版，然后集成實現(xiàn)對應(yīng)接口。

AIDL

關(guān)于 AIDL 開發(fā)的示例可以參考?Android 進程間通信與逆向分析[2]?一文，簡單來說，假設(shè)有以下 AIDL 文件:

package?com.evilpan;

interface?IFooService?{
????parcelable?Person?{
????????String?name;
????????int?age;
????????boolean?gender;
????}
????String?foo(int?a,?String?b,?in?Person?c);
}

那么生成的(Java)模版大致結(jié)構(gòu)如下:

public?interface?IFooService?extends?android.os.IInterface?{

????public?java.lang.String?foo(int?a,?java.lang.String?b,?com.evilpan.IFooService.Person?c)?throws?android.os.RemoteException;
????public?static?class?Person?implements?android.os.Parcelable?{?/*?...?*/?}

????public?static?abstract?class?Stub?extends?android.os.Binder?implements?com.evilpan.IFooService?{
????????@Override?public?boolean?onTransact(int?code,?android.os.Parcel?data,?android.os.Parcel?reply,?int?flags)?throws?android.os.RemoteException?{
????????????data.enforceInterface(descriptor);
????????????//?...
????????????switch(code)?{
????????????????case?TRANSACTION_foo?{
????????????????????int?_arg0;
????????????????????_arg0?=?data.readInt();
????????????????????java.lang.String?_arg1;
????????????????????_arg1?=?data.readString();
????????????????????com.evilpan.IFooService.Person?_arg2;
????????????????????_arg2?=?_Parcel.readTypedObject(data,?com.evilpan.IFooService.Person.CREATOR);
????????????????????java.lang.String?_result?=?this.foo(_arg0,?_arg1,?_arg2);
????????????????????reply.writeNoException();
????????????????????reply.writeString(_result);
????????????????????break;
????????????????}
????????????}
????????}
????}

????private?static?class?Proxy?implements?com.evilpan.IFooService?{
????????@Override?public?java.lang.String?foo(int?a,?java.lang.String?b,?com.evilpan.IFooService.Person?c)?throws?android.os.RemoteException
????????{
????????????android.os.Parcel?_data?=?android.os.Parcel.obtain();
????????????android.os.Parcel?_reply?=?android.os.Parcel.obtain();
????????????java.lang.String?_result;
????????????try?{
????????????_data.writeInterfaceToken(DESCRIPTOR);
????????????_data.writeInt(a);
????????????_data.writeString(b);
????????????_Parcel.writeTypedObject(_data,?c,?0);
????????????boolean?_status?=?mRemote.transact(Stub.TRANSACTION_foo,?_data,?_reply,?0);
????????????_reply.readException();
????????????_result?=?_reply.readString();
????????????}
????????????finally?{
????????????_reply.recycle();
????????????_data.recycle();
????????????}
????????????return?_result;
????????}
????}
????//?...
}

其中?IFooService.Stub?類是本地的 IPC 實現(xiàn)，即服務(wù)端代碼通過繼承至該類并實現(xiàn)其?foo?方法；而?Proxy?則是客戶端的的輔助類，客戶端可以通過調(diào)用?Proxy.foo?方法間接地調(diào)用服務(wù)端的對應(yīng)代碼。數(shù)據(jù)傳輸?shù)倪^程通過?transact?方法實現(xiàn)，其底層是 Android 的 Binder IPC；而數(shù)據(jù)的封裝過程則通過 Parcel 實現(xiàn)。

可以看到上面模版代碼中客戶端分別調(diào)用了?writeInterfaceToken、writeInt、writeString?和?writeTypedObject?來填充傳輸?shù)?_data，而 Stub 類的 onTransact 中以同樣的順序分別調(diào)用了?enforceInterface、readInt、readString、readTypedObject?來獲取?_data?中的數(shù)據(jù)。

Parcelable

在上面的 AIDL 中，我們還定義了一個數(shù)據(jù)結(jié)構(gòu) Person，該結(jié)構(gòu)同樣會由 AIDL 生成對應(yīng)的模版類:

public?static?class?Person?implements?android.os.Parcelable
{
??public?java.lang.String?name;
??public?int?age?=?0;
??public?boolean?gender?=?false;
??public?static?final?android.os.Parcelable.Creator?CREATOR?=?new?android.os.Parcelable.Creator()?{
????@Override
????public?Person?createFromParcel(android.os.Parcel?_aidl_source)?{
??????Person?_aidl_out?=?new?Person();
??????_aidl_out.readFromParcel(_aidl_source);
??????return?_aidl_out;
????}
????@Override
????public?Person[]?newArray(int?_aidl_size)?{
??????return?new?Person[_aidl_size];
????}
??};
??@Override?public?final?void?writeToParcel(android.os.Parcel?_aidl_parcel,?int?_aidl_flag)
??{
????int?_aidl_start_pos?=?_aidl_parcel.dataPosition();
????_aidl_parcel.writeInt(0);
????_aidl_parcel.writeString(name);
????_aidl_parcel.writeInt(age);
????_aidl_parcel.writeInt(((gender)?(1):(0)));
????int?_aidl_end_pos?=?_aidl_parcel.dataPosition();
????_aidl_parcel.setDataPosition(_aidl_start_pos);
????_aidl_parcel.writeInt(_aidl_end_pos?-?_aidl_start_pos);
????_aidl_parcel.setDataPosition(_aidl_end_pos);
??}
??public?final?void?readFromParcel(android.os.Parcel?_aidl_parcel)
??{
????int?_aidl_start_pos?=?_aidl_parcel.dataPosition();
????int?_aidl_parcelable_size?=?_aidl_parcel.readInt();
????try?{
??????if?(_aidl_parcelable_size?=?_aidl_parcelable_size)?return;
??????name?=?_aidl_parcel.readString();
??????if?(_aidl_parcel.dataPosition()?-?_aidl_start_pos?>=?_aidl_parcelable_size)?return;
??????age?=?_aidl_parcel.readInt();
??????if?(_aidl_parcel.dataPosition()?-?_aidl_start_pos?>=?_aidl_parcelable_size)?return;
??????gender?=?(0!=_aidl_parcel.readInt());
????}?finally?{
??????if?(_aidl_start_pos?>?(Integer.MAX_VALUE?-?_aidl_parcelable_size))?{
????????throw?new?android.os.BadParcelableException("Overflow?in?the?size?of?parcelable");
??????}
??????_aidl_parcel.setDataPosition(_aidl_start_pos?+?_aidl_parcelable_size);
????}
??}
??@Override
??public?int?describeContents()?{
????int?_mask?=?0;
????return?_mask;
??}
}

其中關(guān)鍵的是 writeToParcel 和?CREATOR.createFromParcel?方法，分別填充了該自定義結(jié)構(gòu)序列化和反序列化的實現(xiàn)，當然我們也可以自己繼承?Parcelable?去實現(xiàn)自己的可序列化數(shù)據(jù)結(jié)構(gòu)。

內(nèi)存布局

從接口上看，Parcel 可以支持按照一定順序?qū)懭牒妥x取 int、long 等原子數(shù)據(jù)，也支持 String、IBinder、和 FileDescriptor 這些復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。為了理解后文介紹的漏洞，還需要了解在二進制層面這些數(shù)據(jù)的存儲方式。

Parcel 的代碼接口實現(xiàn)在?android/os/Parcel.java?中，但大部分方法最終都會調(diào)用到其中的 native 方法，其 JNI 定義在?frameworks/base/core/jni/android_os_Parcel.cpp?文件里，最終的實現(xiàn)則是在?frameworks/native/libs/binder/Parcel.cpp?中。

以?Parcel.writeInt?為例，其 Java 實現(xiàn)很簡單，直接轉(zhuǎn)到 native 方法:

private?static?native?int?nativeWriteInt(long?nativePtr,?int?val);
public?final?void?writeInt(int?val)?{
????int?err?=?nativeWriteInt(mNativePtr,?val);
????if?(err?!=?OK)?{
????????nativeSignalExceptionForError(err);
????}
}

C++ 中的 JNI 實現(xiàn)則是先將 nativePtr 轉(zhuǎn)換為 Parcel 指針，而后直接調(diào)用?writeInt32?方法:

static?int?android_os_Parcel_writeInt(jlong?nativePtr,?jint?val)?{
????Parcel*?parcel?=?reinterpret_cast(nativePtr);
????return?(parcel?!=?NULL)???parcel->writeInt32(val)?:?OK;
}

接下來就是最終實際的實現(xiàn)了:

status_t?Parcel::writeInt32(int32_t?val)
{
????return?writeAligned(val);
}

template
status_t?Parcel::writeAligned(T?val)?{
????static_assert(PAD_SIZE_UNSAFE(sizeof(T))?==?sizeof(T));
????static_assert(std::is_trivially_copyable_v);

????if?((mDataPos+sizeof(val))?<=?mDataCapacity)?{
restart_write:
????????memcpy(mData?+?mDataPos,?&val,?sizeof(val));
????????return?finishWrite(sizeof(val));
????}

????status_t?err?=?growData(sizeof(val));
????if?(err?==?NO_ERROR)?goto?restart_write;
????return?err;
}

writeAligned?是個模版函數(shù)，用于寫入基礎(chǔ)的 C++ 數(shù)據(jù)類型，即 int、float、double 等，也可以寫入指針數(shù)據(jù)。實現(xiàn)也相對簡單，這里面就涉及到了 Parcel 內(nèi)部的幾個重要數(shù)據(jù)結(jié)構(gòu):

??mData: 序列化數(shù)據(jù)內(nèi)存緩沖區(qū)的內(nèi)存起始地址(指針)；

??mDataPos: 序列化數(shù)據(jù)當前解析到的相對位置；

??mDataCapacity: 緩沖區(qū)的總大??；

還有一個字段 mDataSize 表示當前序列化數(shù)據(jù)的大小，其實這個字段基本上和 mDataPos 的值是一致的，二者都在 finishWrite 函數(shù)中進行更新:

status_t?Parcel::finishWrite(size_t?len)
{
????if?(len?>?INT32_MAX)?{
????????//?don't?accept?size_t?values?which?may?have?come?from?an
????????//?inadvertent?conversion?from?a?negative?int.
????????return?BAD_VALUE;
????}

????//printf("Finish?write?of?%d
",?len);
????mDataPos?+=?len;
????ALOGV("finishWrite?Setting?data?pos?of?%p?to?%zu",?this,?mDataPos);
????if?(mDataPos?>?mDataSize)?{
????????mDataSize?=?mDataPos;
????????ALOGV("finishWrite?Setting?data?size?of?%p?to?%zu",?this,?mDataSize);
????}
????//printf("New?pos=%d,?size=%d
",?mDataPos,?mDataSize);
????return?NO_ERROR;
}

而如果當前緩沖區(qū)的內(nèi)存不足，則會使用 growData 方法進行更新:

status_t?Parcel::growData(size_t?len)
{
????if?(len?>?INT32_MAX)?{
????????//?don't?accept?size_t?values?which?may?have?come?from?an
????????//?inadvertent?conversion?from?a?negative?int.
????????return?BAD_VALUE;
????}

????if?(len?>?SIZE_MAX?-?mDataSize)?return?NO_MEMORY;?//?overflow
????if?(mDataSize?+?len?>?SIZE_MAX?/?3)?return?NO_MEMORY;?//?overflow
????size_t?newSize?=?((mDataSize+len)*3)/2;
????return?(newSize?<=?mDataSize)
??????????????(status_t)?NO_MEMORY
????????????:?continueWrite(std::max(newSize,?(size_t)?128));
}

continueWrite?方法的實現(xiàn)比較復(fù)雜，因為其中還支持傳入小于 mDataSize 的參數(shù)去縮小 Parcel 內(nèi)存，不過在我們這里的上下文中僅用于增長內(nèi)存，因此實際上最終只是通過?realloc?或者?malloc?去分配更多的內(nèi)存:

if?(desired?>?mDataCapacity)?{
????uint8_t*?data?=?reallocZeroFree(mData,?mDataCapacity,?desired,?mDeallocZero);
????if?(data)?{
????????LOG_ALLOC("Parcel?%p:?continue?from?%zu?to?%zu?capacity",?this,?mDataCapacity,
????????????????desired);
????????gParcelGlobalAllocSize?+=?desired;
????????gParcelGlobalAllocSize?-=?mDataCapacity;
????????mData?=?data;
????????mDataCapacity?=?desired;
????}?else?{
????????mError?=?NO_MEMORY;
????????return?NO_MEMORY;
????}
}

這部分目前只需要了解即可，我們關(guān)注的還是前面寫入數(shù)據(jù)的邏輯，回顧一下是在 writeAligned 方法中，直接通過?memcpy?去寫入的數(shù)據(jù)，因此對于基礎(chǔ)數(shù)字類型是沒有額外開銷的，且序列化的字節(jié)序就是當前機器的字節(jié)序。這也是為什么 Parcel 只適合在同一設(shè)備中實現(xiàn) IPC，如果對于不同設(shè)備中可能會出現(xiàn)字節(jié)序的問題。

String

說完了 Int 我們接著看常用的 String 類型，JNI 的定義和實現(xiàn)如下:

static?void?android_os_Parcel_writeString16(JNIEnv?*env,?jclass?clazz,?jlong?nativePtr,
????????jstring?val)?{
????Parcel*?parcel?=?reinterpret_cast(nativePtr);
????if?(parcel?!=?nullptr)?{
????????status_t?err?=?NO_ERROR;
????????if?(val)?{
????????????//?NOTE:?Keep?this?logic?in?sync?with?Parcel.cpp
????????????const?size_t?len?=?env->GetStringLength(val);
????????????const?size_t?allocLen?=?len?*?sizeof(char16_t);
????????????err?=?parcel->writeInt32(len);
????????????char?*data?=?reinterpret_cast(parcel->writeInplace(allocLen?+?sizeof(char16_t)));
????????????if?(data?!=?nullptr)?{
????????????????env->GetStringRegion(val,?0,?len,?reinterpret_cast(data));
????????????????*reinterpret_cast(data?+?allocLen)?=?0;
????????????}?else?{
????????????????err?=?NO_MEMORY;
????????????}
????????}?else?{
????????????err?=?parcel->writeString16(nullptr,?0);
????????}
????????if?(err?!=?NO_ERROR)?{
????????????signalExceptionForError(env,?clazz,?err);
????????}
????}
}

和之前差別不大，值得注意的是?Parcel::writeInplace?返回的是待寫入的內(nèi)存地址，直接用了?JNIEnv::GetStringRegion?去進行寫入。如果 Java 傳入的字符串是?null，則使用?writeString16(nullptr)?去寫入，其內(nèi)部實現(xiàn)是寫入特殊的整數(shù)?-1:

GetStringRegion[3]?返回的是 Unicode 字符，因此每個字符占 2 字節(jié)；

status_t?Parcel::writeString16(const?char16_t*?str,?size_t?len)
{
????if?(str?==?nullptr)?return?writeInt32(-1);
????//?...
}

因此對于字符串結(jié)構(gòu)，Parcel 的序列化也是無開銷順序?qū)懭氲摹?/p>

Array

數(shù)組也是個常用的數(shù)據(jù)類型，但不同的數(shù)組傳輸格式有所不同。對于 char/int/long 等原始類型而言，傳輸數(shù)組實際上就是逐個寫入每個元素，并且在前面寫入數(shù)組的大小:

public?final?void?writeIntArray(@Nullable?int[]?val)?{
????if?(val?!=?null)?{
????????int?N?=?val.length;
????????writeInt(N);
????????for?(int?i=0;?i

	但是 wirteByteArray 有所優(yōu)化:
public?final?void?writeByteArray(@Nullable?byte[]?b,?int?offset,?int?len)?{
????if?(b?==?null)?{
????????writeInt(-1);
????????return;
????}
????ArrayUtils.throwsIfOutOfBounds(b.length,?offset,?len);
????nativeWriteByteArray(mNativePtr,?b,?offset,?len);
}

	JNI 中直接使用 memcpy 去寫入:
static?void?android_os_Parcel_writeByteArray(JNIEnv*?env,?jclass?clazz,?jlong?nativePtr,
?????????????????????????????????????????????jobject?data,?jint?offset,?jint?length)
{
????Parcel*?parcel?=?reinterpret_cast(nativePtr);
????parcel->writeInt32(length);
????void*?dest?=?parcel->writeInplace(length);
????jbyte*?ar?=?(jbyte*)env->GetPrimitiveArrayCritical((jarray)data,?0);
????if?(ar)?{
????????memcpy(dest,?ar?+?offset,?length);
????????env->ReleasePrimitiveArrayCritical((jarray)data,?ar,?0);
????}
}

	Parcelable

	對于?Parcelable?類型的數(shù)據(jù)，使用 writeParcelable 方法進行寫入:
public?final?void?writeParcelable(@Nullable?Parcelable?p,?int?parcelableFlags)?{
????if?(p?==?null)?{
????????writeString(null);
????????return;
????}
????writeParcelableCreator(p);
????p.writeToParcel(this,?parcelableFlags);
}

public?final?void?writeParcelableCreator(@NonNull?Parcelable?p)?{
????String?name?=?p.getClass().getName();
????writeString(name);
}

	其中需要注意的是在調(diào)用?Parcelable.writeToParcel?之前，會先獲取 Parcelable 實際的類名，并以字符串的方式寫入。

	FileDescriptor

	Andorid IPC 的一個特點是可以支持傳輸文件句柄，其 JNI 實現(xiàn)如下:
static?void?android_os_Parcel_writeFileDescriptor(JNIEnv*?env,?jclass?clazz,?jlong?nativePtr,?jobject?object)
{
????Parcel*?parcel?=?reinterpret_cast(nativePtr);
????if?(parcel?!=?NULL)?{
????????const?status_t?err?=
????????????????parcel->writeDupFileDescriptor(jniGetFDFromFileDescriptor(env,?object));
????????if?(err?!=?NO_ERROR)?{
????????????signalExceptionForError(env,?clazz,?err);
????????}
????}
}

	object 為?FileDescriptor?對象，這里的實現(xiàn)就是獲取?FileDescriptor.fd，即?open(2)?返回的，int 格式的文件描述符，進行?fcntl(oldFd, F_DUPFD_CLOEXEC, 0)?復(fù)制后進行寫入。

	Binder 的系統(tǒng)調(diào)用本身就支持傳輸文件類型的數(shù)據(jù)，因此這里 Parcel 的實現(xiàn)只需要做好上層的封裝:
status_t?Parcel::writeFileDescriptor(int?fd,?bool?takeOwnership)?{
????//?...
????switch?(rpcFields->mSession->getFileDescriptorTransportMode())?{
????????case?RpcSession:
????????case?RpcSession:?{
????????????if?(status_t?err?=?writeInt32(RpcFields::TYPE_NATIVE_FILE_DESCRIPTOR);?err?!=?OK)?{
????????????????return?err;
????????????}
????????????if?(status_t?err?=?writeInt32(rpcFields->mFds->size());?err?!=?OK)?{
????????????????return?err;
????????????}
????????}
????}
????flat_binder_object?obj;
????obj.hdr.type?=?BINDER_TYPE_FD;
????obj.flags?=?0;
????obj.binder?=?0;?/*?Don't?pass?uninitialized?stack?data?to?a?remote?process?*/
????obj.handle?=?fd;
????obj.cookie?=?takeOwnership???1?:?0;
????return?writeObject(obj,?true);
}

	值得一提的是，writeObject 中寫入數(shù)據(jù)除了更新上面提到的 mData 等字段，還需要更新?kernelFields，如?mObjects?字段，作為內(nèi)核參數(shù)的記錄。

	Binder

	在 Android IPC 中一個重要的參數(shù)類型就是回調(diào)，即客戶端發(fā)送一個 IBinder 類型的對象給服務(wù)端，然后服務(wù)端可以調(diào)用其 onTransact 方法實現(xiàn)反向異步的數(shù)據(jù)傳輸。對于這種類型的數(shù)據(jù)，主要通過 writeStrongBinder 方法:
public?final?void?writeStrongBinder(IBinder?val)?{
????nativeWriteStrongBinder(mNativePtr,?val);
}

	JNI 實現(xiàn)和傳輸文件類似:
static?void?android_os_Parcel_writeStrongBinder(JNIEnv*?env,?jclass?clazz,?jlong?nativePtr,?jobject?object)
{
????Parcel*?parcel?=?reinterpret_cast(nativePtr);
????if?(parcel?!=?NULL)?{
????????const?status_t?err?=?parcel->writeStrongBinder(ibinderForJavaObject(env,?object));
????????if?(err?!=?NO_ERROR)?{
????????????signalExceptionForError(env,?clazz,?err);
????????}
????}
}

	主要分為兩步，第一步取出 IBinder Java 對象的 Native 指針，即?IBinder.mObject，然后將其轉(zhuǎn)為 C++ 的 IBinder 指針傳入:
status_t?Parcel::writeStrongBinder(const?sp&?val)
{
????return?flattenBinder(val);
}

	傳輸 IBinder 類型的數(shù)據(jù)同樣需要更新 mObjects 緩存。

	其他

	除了上面介紹的這些，Parcel 實現(xiàn)中還有許多值得關(guān)注的細節(jié)，比如 writeBlob 同樣也是寫入?byte[]，但對于過大的數(shù)據(jù)會選擇用共享內(nèi)存的方式去進行傳輸。但根據(jù)上面的簡單分析，我們也能大致看出 Parcel 的一些問題，即序列化和反序列化純屬手工操作，并且在某些操作中沒有嚴格的類型檢查等，下面我們就來逐一探討。

	Bundle

	在 Andorid 中，Bundle 類是一個類似 HashMap 的數(shù)據(jù)結(jié)構(gòu)，但其是為了在 Parcel 序列化/反序列化的使用中而高度優(yōu)化的。因此理解 Bundle 本身的序列化過程對我們理解后面的內(nèi)容也至關(guān)重要。

	序列化

	Bundle 的序列化過程調(diào)用鏈路如下:

	??Bundle.writeToParcel

	??BaseBundle.writeToParcelInner

	??parcel.writeArrayMapInternal

	writeToParcelInner 中主要負責寫入 Bundle 相關(guān)的頭部字段:
void?writeToParcelInner(Parcel?parcel,?int?flags)?{
????//?Keep?implementation?in?sync?with?writeToParcel()?in
????//?frameworks/native/libs/binder/PersistableBundle.cpp.
????final?ArrayMap?map;
????synchronized?(this)?{
????????//?...
????}

????//?Special?case?for?empty?bundles.
????if?(map?==?null?||?map.size()?<=?0)?{
????????parcel.writeInt(0);
????????return;
????}
????int?lengthPos?=?parcel.dataPosition();
????parcel.writeInt(-1);?//?dummy,?will?hold?length
????parcel.writeInt(BUNDLE_MAGIC);

????int?startPos?=?parcel.dataPosition();
????parcel.writeArrayMapInternal(map);
????int?endPos?=?parcel.dataPosition();

????//?Backpatch?length
????parcel.setDataPosition(lengthPos);
????int?length?=?endPos?-?startPos;
????parcel.writeInt(length);
????parcel.setDataPosition(endPos);
}

	writeArrayMapInternal 則主要實現(xiàn) Bundle 內(nèi)部字典數(shù)據(jù)的寫入:
void?writeArrayMapInternal(@Nullable?ArrayMap?val)?{
????if?(val?==?null)?{
????????writeInt(-1);
????????return;
????}
????//?Keep?the?format?of?this?Parcel?in?sync?with?writeToParcelInner()?in
????//?frameworks/native/libs/binder/PersistableBundle.cpp.
????final?int?N?=?val.size();
????writeInt(N);
????int?startPos;
????for?(int?i=0;?i

	可以看到序列化 Bundle 的過程是和 序列化 ArrayMap 一致的，即先寫入整型的 size，然后依次寫入每個 key 和 value。這里值得注意的是 wirteValue 的實現(xiàn):
public?final?void?writeValue(@Nullable?Object?v)?{
????if?(v?==?null)?{
????????writeInt(VAL_NULL);
????}?else?if?(v?instanceof?String)?{
????????writeInt(VAL_STRING);
????????writeString((String)?v);
????}?else?if?(v?instanceof?Integer)?{
????????writeInt(VAL_INTEGER);
????????writeInt((Integer)?v);
????}?else?if?(v?instanceof?Map)?{
????????writeInt(VAL_MAP);
????????writeMap((Map)?v);
????}?//?....?
????else?{
????????Class?clazz?=?v.getClass();
????????if?(clazz.isArray()?&&?clazz.getComponentType()?==?Object.class)?{
????????????//?Only?pure?Object[]?are?written?here,?Other?arrays?of?non-primitive?types?are
????????????//?handled?by?serialization?as?this?does?not?record?the?component?type.
????????????writeInt(VAL_OBJECTARRAY);
????????????writeArray((Object[])?v);
????????}?else?if?(v?instanceof?Serializable)?{
????????????//?Must?be?last
????????????writeInt(VAL_SERIALIZABLE);
????????????writeSerializable((Serializable)?v);
????????}?else?{
????????????throw?new?RuntimeException("Parcel:?unable?to?marshal?value?"?+?v);
????????}
????}
}

	注意，為了便于按照時間線理解歷史漏洞，這里代碼使用的是?Android 8.0 中的版本[4]。

	writeValue?會根據(jù)對象類型分別寫入一個代表類型的整數(shù)以及具體的數(shù)據(jù)。所支持的類型如下所示:
//?Keep?in?sync?with?frameworks/native/include/private/binder/ParcelValTypes.h.
private?static?final?int?VAL_NULL?=?-1;
private?static?final?int?VAL_STRING?=?0;
private?static?final?int?VAL_INTEGER?=?1;
private?static?final?int?VAL_MAP?=?2;
private?static?final?int?VAL_BUNDLE?=?3;
private?static?final?int?VAL_PARCELABLE?=?4;
private?static?final?int?VAL_SHORT?=?5;
private?static?final?int?VAL_LONG?=?6;
private?static?final?int?VAL_FLOAT?=?7;
private?static?final?int?VAL_DOUBLE?=?8;
private?static?final?int?VAL_BOOLEAN?=?9;
private?static?final?int?VAL_CHARSEQUENCE?=?10;
private?static?final?int?VAL_LIST??=?11;
private?static?final?int?VAL_SPARSEARRAY?=?12;
private?static?final?int?VAL_BYTEARRAY?=?13;
private?static?final?int?VAL_STRINGARRAY?=?14;
private?static?final?int?VAL_IBINDER?=?15;
private?static?final?int?VAL_PARCELABLEARRAY?=?16;
private?static?final?int?VAL_OBJECTARRAY?=?17;
private?static?final?int?VAL_INTARRAY?=?18;
private?static?final?int?VAL_LONGARRAY?=?19;
private?static?final?int?VAL_BYTE?=?20;
private?static?final?int?VAL_SERIALIZABLE?=?21;
private?static?final?int?VAL_SPARSEBOOLEANARRAY?=?22;
private?static?final?int?VAL_BOOLEANARRAY?=?23;
private?static?final?int?VAL_CHARSEQUENCEARRAY?=?24;
private?static?final?int?VAL_PERSISTABLEBUNDLE?=?25;
private?static?final?int?VAL_SIZE?=?26;
private?static?final?int?VAL_SIZEF?=?27;
private?static?final?int?VAL_DOUBLEARRAY?=?28;

	可以看到其中支持大部分基礎(chǔ)類型以及 Parcelable、IBinder 等 Parcel 本身所支持的類型。

	綜上所述，我們可以大致得出 Bundle 的內(nèi)存布局:

				size
			

				type
			

				value
		

				4
			

				Int
			

				length
		

				4
			

				Int
			

				BUNDLE_MAGIC (0x4C444E42)
		

				4
			

				Int
			

				map.size()
		

				xxx
			

				String
			

				key[0]
		

				xxx
			

				Dynamic
			

				val[0]
		

				...
			

				...
			

				...
		

				xxx
			

				String
			

				key[map.size() - 1]
		

				xxx
			

				Dynamic
			

				val[map.size() - 1]
		

	其中 key 因為是 String 類型，因此內(nèi)部是長度 + String16 的布局，而 value 則根據(jù)類型不同使用不同的結(jié)構(gòu)。

	key:

	??length Int32

	??data String16

	value:

	??VAL_XXX Int32

	??data writeInt/writeString/...

	下面是在一個 Bundle 序列化的示例，原始內(nèi)容為:
Bundle?A?=?Bundle()
A.putInt("key1",?0x1337)
A.putString("key2",?"hello")
A.putLong("key33",?0x0123456789)

	使用 Parcel 序列化后的二進制數(shù)據(jù)如下:

	

	bin.png

	其中有幾個需要注意的細節(jié):

	??length 字段是不包括 length+magic 部分的，因此實際上序列化數(shù)據(jù)的總大小會比頭部的結(jié)果大 8 字節(jié)即 100；

	??String 數(shù)據(jù)是 4 字節(jié)對齊的(如 key33)；如果本身已經(jīng)對齊，也會在后面進行特殊拓展，如(key1/key2)；特殊拓展的值為?Parcel::writeInplace?中的 padMask，對于已經(jīng) 4 字節(jié)對齊的 mask 正好是 0；

	存儲

	Bundle 雖然內(nèi)部是 ArrayMap 結(jié)構(gòu)，但實際存儲的時候還有一點優(yōu)化。在平時開發(fā)中細心的朋友可能會發(fā)現(xiàn)，有時候在獲取遠程的 Bundle 比如 CotentResolver.call 的結(jié)果時候，直接打印輸出會是?Bundle[mParcelledData.dataSize=xxx]?的結(jié)果。但是對于自己構(gòu)建的 Bundle，卻可以打印出完整的 Map 元素。

	這其實可以從 Bundle 的源碼中看出來:
@Override
public?synchronized?String?toString()?{
????if?(mParcelledData?!=?null)?{
????????if?(isEmptyParcel())?{
????????????return?"Bundle[EMPTY_PARCEL]";
????????}?else?{
????????????return?"Bundle[mParcelledData.dataSize="?+
????????????????????mParcelledData.dataSize()?+?"]";
????????}
????}
????return?"Bundle["?+?mMap.toString()?+?"]";
}

	關(guān)鍵就是這個?mParcelledData?字段，該字段定義在父類即 BaseBundle 中，為 Parcel 類型。由于 Bundle 經(jīng)常在進程間進行傳輸，因此設(shè)計上認為可以不要到對端的時候馬上就反序列化出所有的 ArrayMap，而是等需要用到時再進行解析，這也可以認為是一種懶加載的技術(shù)。對于一些收到 Bundle 后馬上又傳輸給其他服務(wù)的場景，這種設(shè)計可以直接傳輸未解析的 Parcel 數(shù)據(jù)而不需要來回的序列化。

	因此對于 Bundle 而言，對于一些需要獲取內(nèi)部元素的調(diào)用時才會進行反序列，比如 size 和 isEmpty 的實現(xiàn):
public?int?size()?{
????unparcel();
????return?mMap.size();
}

public?boolean?isEmpty()?{
????unparcel();
????return?mMap.isEmpty();
}

	值得注意的是，在 Bundle 內(nèi)部，ArrayMap(mMap) 和 Parcel(mParcelledData) 同一時間只能存在一個，反序列化后會填充 mMap 把 mParcelledData 回收并置為 null。

	反序列化與 Bundle 風水

	最早提交 Android 反序列化漏洞的是 @BednarTildeOne 在 2014 年提交的 ParceledListSlice 漏洞，但第一次引起公眾關(guān)注的應(yīng)該是 CVE-2017-0806。也是同樣的作者，不過給出了詳細的分析以及漏洞 POC 代碼，這才得以引起關(guān)注。

	該漏洞的原理已經(jīng)有很多師傅分析過了，就不再贅述，這里直接給出一個簡化的版本。假設(shè)有這么一個 Parcelable 數(shù)據(jù)結(jié)構(gòu)，請問是否存在漏洞？漏洞如何利用？
public?class?Vulnerable?implements?Parcelable?{
????private?long?mData;

????protected?Vulnerable(Parcel?in)?{
????????mData?=?m.readInt();
????}

????@Override
????public?void?writeToParcel(Parcel?parcel,?int?flags)?{
????????parcel.writeLong(mData)
????}
????//?...
}

	問題很明顯，可以看到其中序列化使用了 writeLong，但是反序列化過程卻用了 readInt，二者不匹配，這可能會導(dǎo)致一些數(shù)據(jù)錯誤，但這能算得上一個漏洞嗎？

	回想 LunchAnywhere 漏洞以及對應(yīng)的?patch[5]，實際上是用戶可控的 Intent 數(shù)據(jù)中帶有?KEY_INTENT?extra 導(dǎo)致的啟動任意 Activity 的問題。修復(fù)過程是判斷用戶提供的 Intent 是否帶有該 extra，如果有則校驗調(diào)用者的簽名。當時的修復(fù)可以說沒什么問題，但如果配合上述的漏洞，就有可能出現(xiàn)繞過。

	這里還是以測試代碼舉例，假設(shè)我們的校驗函數(shù)如下:
@Override
public?void?onResult(Bundle?result)?{
????Intent?intent?=?result.getParcelable(AccountManager.KEY_INTENT)
????if?(intent?!=?null)?{
????????checkCallingSignature()
????}
????//?...
????send(result)
}

public?void?send(Bundle?result);?//?AIDL

	校驗時如果 intent 不為空則進行簽名校驗，隨后會調(diào)用 AIDL 的客戶端方法?send，該方法將 bundle 再次序列化然后發(fā)送給服務(wù)端，而服務(wù)端的實現(xiàn)如下:
class?Server?extends?IServer.Stub?{
????@Override
????public?void?send(Bundle?result)?{
????????Intent?intent?=?bundle.getParcelable(KEY_INTENT);
????????if?(intent?!=?null)?{
????????????mContext.startActivity(intent)
????????}
????}
}

	因為客戶端進行了校驗，所以服務(wù)就不需要再次校驗而是直接信任該 Bundle 并使用了。這里其實有個經(jīng)典的漏洞模式即 TOCTOU 問題，一般情況下這個邏輯是沒問題的，即 bundle 檢查完后不會被再次修改。但在我們的漏洞場景中，就有可能會出現(xiàn)不同的 bundle，即?Self-Changing Bundle。

	自修改 Bundle

	Bundle 自修改，主要還是針對上面的這種 IPC 場景，一端對 Bundle 進行了校驗，發(fā)現(xiàn)沒問題后使用 IPC 發(fā)送給另一端，且對方不加校驗就直接使用。即 Bundle 在序列化+反序列化的過程中進行了改變。

	假設(shè)服務(wù)端 B 接收我們的 Bundle 數(shù)據(jù)進行反序列化后再次序列化發(fā)送給服務(wù)端 C，而我們的 bundle 中帶有一個類型為 Vunerable 的 key，那在 B 接收到數(shù)據(jù)后再發(fā)出去的數(shù)據(jù)會如下圖右邊所示，其中本該是 Int 的字段被寫成了 Long，導(dǎo)致 C 再次反序列化時候?qū)罄m(xù)數(shù)據(jù)的解析出現(xiàn)異常:

	

	Bundle

	通過精心構(gòu)造發(fā)送給 B 的數(shù)據(jù)，我們可以令 B 和 C 都能正常序列化出 Bundle 對象，甚至讓這兩個 Bundle 含有不同的 key！

	漏洞利用

	該漏洞如何利用呢？前文中我們已知 Bundle 序列化數(shù)據(jù)的頭部后面每個元素都是 key+value 的組合，那利用思路應(yīng)該就是將多出來的 4 字節(jié)進行類型混淆。這種場景類似于二進制的緩沖區(qū)溢出，我們需要做的就是布局好數(shù)據(jù)使得同時滿足下述條件:

	1.?類型混淆前后，Bundle 的 length 和 items 字段保持一致；

	2.?兩次反序列化得到的對象都需要是合法對象；

	3.?第二次反序列化要能夠出現(xiàn)一個前面沒有的 Bundle key；

	溢出的 4 個字節(jié)會作為后面一個 key 的一部分，而 key 的類型是 String，根據(jù)前面的介紹，其內(nèi)存是長度(Int32) + String16。其中 String16 是 unicode，使用 2 字節(jié)保存一個字符。因此，如果 map 元素足夠的話，這 4 個字節(jié)會形成下一個 key 的長度。

	在大部分情況下，溢出的部分是 Long 數(shù)據(jù)的高有效位，因此會是 0，如果此時第二次反序列化處理到這里，會認為這有個 key 長度為 0 的元素，查看讀取字符串相關(guān)的代碼，如下所示:
const?char16_t*?Parcel::readString16Inplace(size_t*?outLen)?const
{
????int32_t?size?=?readInt32();
????//?watch?for?potential?int?overflow?from?size+1
????if?(size?>=?0?&&?size?

	考慮到 padding 的存在，即便 size 為 0，還是會讀出?(0+1)x2?即 2 字節(jié)的?x00。readInplace?中還會對齊，因此最終讀出的是 4 字節(jié)數(shù)據(jù)。因此，后續(xù)的反序列化都會在原來的基礎(chǔ)上后移 4 字節(jié)。

	這樣一來利用思路就比較清晰了:

	1.?構(gòu)造一個惡意 Bundle，其中包含兩個元素 A0 和 A1，其中 A0 為 Vunlerable，在 A1 中布置 payload；

	2.?反序列化+序列化后，數(shù)據(jù)多出 4 字節(jié)，且下個元素的解析從 A1 的 key 內(nèi)容開始；

	3.?構(gòu)造 A1 的 key 和 value，使得第 2 步中解析出新的 key；

	還是以前面的 Vulnerable 類為例，POC 代碼如下:
val?p?=?Parcel.obtain()

val?lengthPos?=?p.dataPosition()
//?header
p.writeInt(-1)?//?length,?back-patch?later
p.writeInt(0x4C444E42)?//?magic
val?startPos?=?p.dataPosition();
p.writeInt(3)?//?numItem

//?A0
p.writeString("A")
p.writeInt(Type.VAL_PARCELABLE.value)
p.writeString("com.evilpan.poc.Vulnerable")
p.writeInt(666)?//?mData

//?A1
p.writeString("u000du0000u0008")?//?0d00?0000?0800
p.writeInt(Type.VAL_BYTEARRAY.value)
p.writeInt(28)
p.writeString("intent")??????????????//?4?+?padSize((6?+?1)?*?2)?=?4+16?=?20
p.writeInt(Type.VAL_INTEGER.value)???//?=?4
p.writeInt(0x1337)???????????????????//?=?4

//?A2
p.writeString("BBB")
p.writeInt(Type.VAL_NULL.value)

//?Back-patch?length?&&?reset?position

val?A?=?unparcel(p)
Log.i("A?=?"?+?inspect(A))
Log.i("A.containsKey:?"?+?A.containsKey("intent"))

val?B?=?unparcel(parcel(A))
Log.i("B?=?"?+?inspect(B))
Log.i("B.containsKey:?"?+?B.containsKey("intent"))

	在上述 POC 中，我們明面上構(gòu)造了一個含有 3 個元素的 Bundle，分別是:

	??A0: Parcelable 類型，元素為我們帶有漏洞的 Parcelable；

	??A1: ByteArray 類型，長度為 28 字節(jié)，ByteArray 的內(nèi)容為隱藏的 Intent 元素，即 20+4+4；

	??A2: NULL 類型；

	其中關(guān)鍵的是 A1 的 key，在觸發(fā)漏洞后，會被解析為第二個元素的元素類型和長度，即解析出來的內(nèi)容為:

	??0d000000: 解析為元素類型，等于 VAL_BYTEARRAY(13)；

	??08000000: 解析為 ByteArray 長度，即 8 字節(jié)；注意這里額外的 0 是字符串寫入時候 pad 出來的。

	之所以是 8 字節(jié)，是為了把后面的長度字段吞掉，使得解析下一個元素可以直接到我們隱藏的 intent 中。

	第三個元素 A2 只是用于占位，在第一次序列化時候有用，第二次時直接被我們隱藏的 intent 替代了。上述代碼的運行結(jié)果如下:
[INFO]:?A?=?Bundle(item?=?3)?length:?144
[INFO]:???=>?41000000?=?VAL_PARCELABLE:com.evilpan.poc.Vulnerable{mData=666}
[INFO]:???=>?0d00000008000000?=?VAL_BYTEARRAY:0600000069006e00740065006e007400000000000100000037130000
[INFO]:???=>?4200420042000000?=?VAL_NULL:null
[INFO]:?A.containsKey:?false
[INFO]:?===?writeToParcel?===
[INFO]:?B?=?Bundle(item?=?3)?length:?148
[INFO]:???=>?41000000?=?VAL_PARCELABLE:com.evilpan.poc.Vulnerable{mData=666}
[INFO]:???=>?03000000?=?VAL_BYTEARRAY:0d0000001c000000
[INFO]:???=>?69006e00740065006e00740000000000?=?VAL_INTEGER:1337
[INFO]:?B.containsKey:?true

	可以看到第一次反序列化出來的 Bundle A 包含三個 key，其中并沒有 intent 字段，但經(jīng)過序列化再反序列化后的 Bundle B 已經(jīng)修改了，第二個元素的變成了長度為 8 字節(jié)的 ByteArray，實際上其 key 長度為；第三個元素則是我們偽造的 intent 元素，值為 0x1337，因此我們成功地繞過了第一次 containsKey 的校驗，而在第二次中進行觸發(fā)！

	上述例子在 Android 12 中進行測試，理論上之前的版本也類似。

	實際上的漏洞與這個例子大同小異，由于 Android 系統(tǒng)對 IPC 的大量使用，許多操作都會在?system_server、Settings 應(yīng)用、用戶應(yīng)用中來回穿梭，也就造成了許多上述 TOCTOU 的問題。對其中細節(jié)感興趣的可以參考下面的分析文章:

	??ReparcelBug - PoC for CVE-2017-0806[6]

	??CVE-2017-0806 原理分析[7]

	??Bundle風水——Android序列化與反序列化不匹配漏洞詳解[8]

	漏洞修復(fù)

	上述漏洞的修復(fù)似乎很直觀，只需要把 Vulnerable 類中不匹配的讀寫修復(fù)就行了。但實際上這類漏洞并不是個例，歷史上由于代碼編寫人員的粗心大意，曾經(jīng)出現(xiàn)過許多因為讀寫不匹配導(dǎo)致的提權(quán)漏洞，包括但不限于:

	??CVE-2017-0806 GateKeeperResponse

	??CVE-2017-0664 AccessibilityNodelnfo

	??CVE-2017-13288 PeriodicAdvertisingReport

	??CVE-2017-13289 ParcelableRttResults

	??CVE-2017-13286 OutputConfiguration

	??CVE-2017-13287 VerifyCredentialResponse

	??CVE-2017-13310 ViewPager's SavedState

	??CVE-2017-13315 DcParamObject

	??CVE-2017-13312 ParcelableCasData

	??CVE-2017-13311 ProcessStats

	??CVE-2018-9431 OSUInfo

	??CVE-2018-9471 NanoAppFilter

	??CVE-2018-9474 MediaPlayerTrackInfo

	??CVE-2018-9522 StatsLogEventWrapper

	??CVE-2018-9523 Parcel.wnteMapInternal0

	??CVE-2021-0748 ParsingPackagelmpl

	??CVE-2021-0928 OutputConfiguration

	??CVE-2021-0685 ParsedIntentInfol

	??CVE-2021-0921 ParsingPackagelmpl

	??CVE-2021-0970 GpsNavigationMessage

	??CVE-2021-39676 AndroidFuture

	??CVE-2022-20135 GateKeeperResponse

	??...

	另一個修復(fù)思路是修復(fù) TOCTOU 漏洞本身，即確保檢查和使用的反序列化對象是相同的，但這種修復(fù)方案也是治標不治本，同樣可能會被攻擊者找到其他的攻擊路徑并繞過。

	因此，為了徹底解決這類層出不窮的問題，Google 提出了一種簡單粗暴的緩釋方案，即直接從 Bundle 類中下手。雖然 Bundle 本身是 ArrayMap 結(jié)構(gòu)，但在反序列化時候即便只需要獲取其中一個 key，也需要把整個 Bundle 反序列化一遍。這其中的主要原因在于序列化數(shù)據(jù)中每個元素的大小是不固定的，且由元素的類型決定，如果不解析完前面的所有數(shù)據(jù)，就不知道目標元素在什么地方。

	為此在 21 年左右，AOSP 中針對 Bundle 提交了一個稱為?LazyBundle(9ca6a5)[9]?的 patch。其主要思想為針對一些長度不固定的自定義類型，比如 Parcelable、Serializable、List 等結(jié)構(gòu)或容器，會在序列化時將對應(yīng)數(shù)據(jù)的大小添加到頭部。這樣在反序列化時遇到這些類型的數(shù)據(jù)，可以僅通過檢查頭部去選擇性跳過這些元素的解析，而此時 sMap 中對應(yīng)元素的值會設(shè)置為 LazyValue，在實際用到這些值的時候再去對特定數(shù)據(jù)進行反序列化。

	這個 patch 可以在一定程度上緩釋針對 Bundle 風水的攻擊，而且在提升系統(tǒng)健壯性也有所助益，因為即便對于損壞的 Parcel 數(shù)據(jù)，如果接收方?jīng)]有使用到對應(yīng)的字段，就可以避免異常的發(fā)生。對于之前的 Bundle 解析策略，哪怕只調(diào)用了?size?方法，也會觸發(fā)所有元素的解析從而導(dǎo)致異常。 在這個 patch 中?unparcel?還增加了一個 boolean 參數(shù)?itemwise，如果為 true 則按照傳統(tǒng)方式解析每個元素，否則就會跳過 LazyValue 的解析。

	CVE-2021-0928

	在前面反序列化的示例中，漏洞主要出在一個自定義的 Vulnerable 類中，即手工編寫的 readFromParcel/writeToParcel 不匹配問題。在現(xiàn)實中，這種出現(xiàn)問題的類通常只在進程間使用而幾乎不用于跨進程，否則在正常 IPC 調(diào)用時候就會出現(xiàn)明顯的數(shù)據(jù)錯誤。但也還有一種情況，比如在 readFromParcel 方法調(diào)用的過程中出現(xiàn)異常，但是上級進行了“優(yōu)雅”的?try-catch，從而程序并不會報錯，但異常發(fā)生后 Parcel 中還有剩余數(shù)據(jù)并未消費，因此會被后續(xù)的解析錯誤使用，比如在 AIDL 調(diào)用時候就會被后續(xù)的參數(shù)用到。

	CVE-2021-0928?就是這么一個經(jīng)典的漏洞。漏洞本身只存在于 Andorid 12 beta3 的短暫時間窗口中，因此我們并不需要太過于關(guān)注細節(jié)，此外漏洞的作者也已經(jīng)在 Github 上公開了該漏洞的詳細介紹以及 POC 代碼。作為歷史漏洞研究，筆者這里只做簡單的介紹，并重點關(guān)注一些值得學習的漏洞利用思路和漏洞模式。完整的漏洞細節(jié)分析和 POC 可以參考原作者的分享:

	??CVE-2021-0928, writeToParcel/createFromParcel serialization mismatch in android.hardware.camera2.params.OutputConfiguration[10]

	漏洞介紹

	主要出現(xiàn)漏洞的類為?android.hardware.camera2.params.OutputConfiguration，其代碼片段如下所示:
package?android.hardware.camera2.params;

public?final?class?OutputConfiguration?implements?Parcelable?{
????private?OutputConfiguration(@NonNull?Parcel?source)?{
????????int?rotation?=?source.readInt();
????????int?surfaceSetId?=?source.readInt();
????????//?...
????????boolean?isMultiResolution?=?source.readInt()?==?1;?//?New?in?Android?12
????????ArrayList?sensorPixelModesUsed?=?new?ArrayList();?//?New?in?Android?12
????????source.readList(sensorPixelModesUsed,?Integer.class.getClassLoader());?//?New?in?Android?12
????????//?...
????}

????public?static?final?@android.annotation.NonNull?Parcelable.Creator?CREATOR?=
????????????new?Parcelable.Creator()?{
????????@Override
????????public?OutputConfiguration?createFromParcel(Parcel?source)?{
????????????try?{
????????????????OutputConfiguration?outputConfiguration?=?new?OutputConfiguration(source);
????????????????return?outputConfiguration;
????????????}?catch?(Exception?e)?{
????????????????Log.e(TAG,?"Exception?creating?OutputConfiguration?from?parcel",?e);
????????????????return?null;
????????????}
????????}
????};
}

	其中在?createFromParcel?中對構(gòu)造函數(shù)進行了異常捕捉，但是對于異常僅僅是打印并返回，這導(dǎo)致 Parcel 數(shù)據(jù)殘留從而影響后續(xù)的數(shù)據(jù)解析。

	該漏洞本身并不復(fù)雜，是個很常見的 Parcel 序列化/反序列化不匹配問題，關(guān)鍵是這個漏洞如何利用？由于漏洞的本質(zhì)是序列化數(shù)據(jù)殘留，因此我們可以主要關(guān)注一些 AIDL 調(diào)用場景的參數(shù)，這樣解析下一個參數(shù)時其內(nèi)容也就會被我們所污染的數(shù)據(jù)控制。其中一個漏洞觸發(fā)鏈路就是 sendBroadcast。

	Android 廣播

	關(guān)于 Android 廣播的發(fā)送和接收流程應(yīng)該已經(jīng)有很多其他博客介紹過了，這里將其簡化為下面的階段，假設(shè)廣播由應(yīng)用 A 發(fā)送給應(yīng)用 B；

	1.?A 調(diào)用 sendBroadcast，這實際上是個 AIDL 接口，接收方即實際實現(xiàn)為 system_server；

	2.?system_server 接收到 Intent 后進行一系列處理，判斷合法的接收方，然后調(diào)用?IApplicationThread.scheduleReceiver?發(fā)送廣播數(shù)據(jù)；這同樣是一個 AIDL 接口，由各個應(yīng)用在啟動之初通過?IActivityManager.attachApplication()?傳遞給 system_server；因此這個調(diào)用實際上會進入到應(yīng)用 B 中；

	3.?B 觸發(fā)?ActivityThread.handleMessage，進而調(diào)用?handleReceiver；

	4.?handleReceiver 中通過傳來的數(shù)據(jù)去實例化應(yīng)用上下文，獲取對應(yīng)的 receiver，最終調(diào)用開發(fā)者注冊的 onReceive 回調(diào)；

	第 2 步中 scheduleReceiver 的定義如下:

	public?final?void?scheduleReceiver(Intent?intent,?ActivityInfo?info,
????CompatibilityInfo?compatInfo,?int?resultCode,?String?data,?Bundle?extras,
????boolean?sync,?int?sendingUser,?int?processState);

	其中第一個 intent 是 A 應(yīng)用指定的 sendBroadcast 的參數(shù)，第二個參數(shù)則是 system_server 傳遞給應(yīng)用 B 的。漏洞利用思路就是通過 intent 參數(shù)的反序列化數(shù)據(jù)殘留，間接地修改 info 參數(shù)，因為應(yīng)用 B 會使用 ActivityInfo 中的數(shù)據(jù)去實例化代碼，具體來說就是:
private?void?handleReceiver(ReceiverData?data)?{
????String?component?=?data.intent.getComponent().getClassName();
????LoadedApk?packageInfo?=?getPackageInfoNoCheck(
????????????data.info.applicationInfo,?data.compatInfo);
????app?=?packageInfo.makeApplicationInner(false,?mInstrumentation);
????//?...
}

	應(yīng)用會通過傳入的 ActivityInfo 構(gòu)造 LoadedApk，其中會使用內(nèi)部的?zipPaths?創(chuàng)建 ClassLoader，攻擊者如果可以控制這個字段，就能實現(xiàn)針對應(yīng)用 B 的任意代碼執(zhí)行。

	要實現(xiàn)這個目的，還有億點細節(jié)需要解決，首先我們先來看一個 Java 語言的特性。

	Java 類型擦除

	Java 類型擦除也稱為?Type Erasure[11]，主要產(chǎn)生在 Java 的泛型代碼中。Java 虛擬機中并沒有泛型類型的概念，因此在編譯時實際類型會被替換為其限制對象或者原始對象?Object?類型，這個過程就叫做類型擦除。

	例如，下述代碼:

	public?static??void?printArray(E[]?array)?{
????for?(E?element?:?array)?{
????????System.out.printf("%s?",?element);
????}
}

	會在編譯時變成:
public?static?void?printArray(Object[]?array)?{
????for?(Object?element?:?array)?{
????????System.out.printf("%s?",?element);
????}
}

	即模版類型 E 變成了原始類型 Object。對于有限制類型的模版，比如:
public?static?>?void?printArray(E[]?array)?{
????for?(E?element?:?array)?{
????????System.out.printf("%s?",?element);
????}
}

	會在編譯時替換成其限制類型:
public?static?void?printArray(Comparable[]?array)?{
????for?(Comparable?element?:?array)?{
????????System.out.printf("%s?",?element);
????}
}

	那么，這個特性對于漏洞的利用有什么幫助呢？回顧?OutputConfiguration?類，其中有個序列化的字段?sensorPixelModesUsed?是?ArrayList?類型，在反序列化該字段時，使用的是?Parcel.readList?方法，其調(diào)用鏈路是:

	??Parcel.readList

	??Parcel.readListInternal

	??Parcel.readValue

	最終是使用 readValue 讀取 List 中每個元素的值。因此實際上可以讀出任何 readValue 支持的類型，比如 Parcelable、IBinder 等，并不局限于 Integer。

	僅僅進行反序列化并不會出現(xiàn)任何問題，只不過在使用具體的元素時，如果我們實際讀取的類型無法轉(zhuǎn)換為整數(shù)，就會出現(xiàn)?ClassCastException?異常。在這個漏洞場景中，我們并不會使用這個數(shù)組的元素，因此我們可以指定任意的序列化類。又由于我們需要使目標類在序列化/反序列化過程產(chǎn)生不匹配，那么就需要找到一個類，使得該類可以在 system_server 中成功反序列化，但是在應(yīng)用 B 中出現(xiàn)異常，比如?ClassNotFoundException。

	原作者的利用是使用了?PackageManagerException，這是一個?Serializable?類而不是?Parcelable，因為?readSerializable/ObjectInputStream 不需要指定 ClassLoader[12]。當然肯定還存在其他可用的類，感興趣的可以自行發(fā)掘。

	實際利用中由于讀取使用了帶 classLoader 的 readList，因此到 ObjectInputStream 時?latestUserDefinedLoader?會被影響，解決方案是將 Serializable 再套一層 Parcelable，使用不帶 ClassLoader 的 readList 去進行恢復(fù)。這里選用的是?WindowContainerTransaction?類。

	其他

	上面只介紹了漏洞利用的大致流程，完整的利用還有一些細節(jié)需要注意，比如:

	1.?如何將任意 Parcelable 放到 Intent 中；

	2.?精細的內(nèi)存布局；

	對于問題 1，使用 putExtras(Bundle) 并不可行，因為在 Intent 中 Bundle 會作為一個整體進行拷貝，因此 Bundle 中的反序列化錯誤并不會影響 Intent 本身。作者是用了一個在 Android 12 中加入的 Intent.ClipData 字段去實現(xiàn)的，不過目前已經(jīng)修復(fù)了就不再展開了。

	對于問題 2，有幾個關(guān)鍵點需要注意。一是在觸發(fā)異常后，并沒有直接跳到第二個參數(shù)，而是會繼續(xù)上級(解析了一半的)容器處理，因此后續(xù) payload 需要維持這部分數(shù)據(jù)的棧平衡；另外一個問題是在 Andorid 中新增了許多隱藏 API 的限制，使得我們無法通過調(diào)用這些方法去構(gòu)造 ActivityInfo 等數(shù)據(jù)，這個解決方法是參考源碼直接通過 Parcel 去寫入數(shù)據(jù)，只是過程繁瑣了一點，當然也可以用其他方式去繞過 Hidden API 的限制[13]。

	漏洞修復(fù)

	這個漏洞本身對終端用戶的影響不是很大，畢竟只在 Android 12 Preview 版本中就修復(fù)了。但通過這個漏洞，Google 引入了許多修復(fù)和緩釋方案，直接影響了后續(xù)的漏洞挖掘和利用思路。

	首先針對漏洞本身，修復(fù)方案為:

	1.?對上述類去除隱式的異常處理，修復(fù)讀寫不一致的問題；

	2.?使用 readIntArray 而不是 readList/readValue 去讀取數(shù)據(jù)，消滅類型擦除的副作用；

	3.?防止 ClipData.mActivityInfo 寫入 Parcel，除非顯式指定。這消除了向 Intent 寫入任意 Parcelable 的一個攻擊鏈路；

	另外，在 Andorid 13 中，引入了更強的反序列化緩釋方案:

	1.?新增了一個 readListInternal 方法的重載，增加額外的?Class?參數(shù)，顯式指定讀取列表的元素的類型，并且將原來的方法標記為?@Deprecated；

	2.?新增了?Parcel.enforceNoDataAvail[14]?方法，用于確保反序列化結(jié)束后，Parcel 中不再存在多余的數(shù)據(jù)；回想上一節(jié)中 Bundle 風水的利用，實際上第三個元素在第二次反序列化中是多出來的，因此這個修改會導(dǎo)致上述 Bundle 風水的失??；當然也有一些繞過的手法，比如通過更復(fù)雜的風水使得第二次反序列化能夠到 Parcel 的末尾即可；

	3.?即上文說過的 LazyBundle patch，在 LazyBundle 實現(xiàn)中，Parcelable、List 等類型會在序列化數(shù)據(jù)的元素開頭單獨存儲長度信息。不過，這個 patch 并不會影響非 Bundle 造成的反序列化漏洞，比如這個漏洞。

	LeakValue

	時間來到 2022 年，Google 推出了 Android 13，在其中正式啟用了 LazyBundle 的 patch。我們在前面 Bundle 風水中已經(jīng)簡要介紹過大致原理，這里再深入去分析其實現(xiàn)。

	深入 LazyValue

	由于 LazyValue 是在使用時才進行反序列化的，因此在讀取值時，需要預(yù)先知道它在 Parcel 中所占的數(shù)據(jù)區(qū)間，讀取后還需要修改 Parcel 結(jié)構(gòu)中對應(yīng)的偏移。這也是為什么 LazyValue 需要在序列化數(shù)據(jù)中寫入其數(shù)據(jù)長度的原因，因為對于這類數(shù)據(jù)(如 Parcelable)，無法僅通過類型得知其數(shù)據(jù)長度。

	讀取 LazyValue 的代碼實現(xiàn)如下所示:
public?Object?readLazyValue(@Nullable?ClassLoader?loader)?{
????int?start?=?dataPosition();
????int?type?=?readInt();
????if?(isLengthPrefixed(type))?{
????????int?objectLength?=?readInt();
????????if?(objectLength?

	這里面有幾個關(guān)鍵點。首先，LazyValue 中存儲的是 Parcel 的引用，以及其在 Parcel 中所占的數(shù)據(jù)區(qū)間，使用其內(nèi)部屬性 mPosition、mLength 表示，mPostion 對應(yīng)上述代碼中的?start，mLength 對應(yīng)?valueLength。其中 valueLength 是添加到序列化數(shù)據(jù)頭部的長度字段，包括長度和類型所占的空間。

	其次，在 Parcel 中構(gòu)造 LazyValue 之后，會將 dataPostion 設(shè)置到對象對應(yīng)序列化數(shù)據(jù)的尾部。在需要實際數(shù)據(jù)時，會調(diào)用?LazyValue.apply?方法進行真正的反序列化，如下所示:
@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;
}

	可以看到在反序列化時候會將原始 Parcel 的 dataPostion 保存，并設(shè)置指向到 LazyValue 中的位置，然后調(diào)用 readValue 去進行反序列化，完成后再次恢復(fù) Parcel 調(diào)用前的 dataPostion。

	這可能會涉及到一些安全問題，比如多線程之間的條件競爭，在修改 dataPostion 之后被其他線程使用，當然這通過?synchronized?同步塊防御住了。另一個問題是，在 LazyValue 未使用之前，其所對應(yīng)的 Parcel 是不能被釋放的，否則就會出現(xiàn)類似 UAF 的內(nèi)存問題?？紤]到對于 Parcel 的內(nèi)存分配策略而言，大多數(shù)是使用手工管理的 obtain/recycle 方式，這個問題是有可能存在的。

	Parcel 內(nèi)存管理

	由于 Parcel 本身是為了頻繁的 IPC 傳輸而設(shè)計的，因此對于其分配和釋放通常使用手工管理的方式，以避免 Java 堆分配或者 GC 帶來的性能損耗。在閱讀系統(tǒng)源碼或者 AIDL 生成的模版代碼時都能發(fā)現(xiàn)，Parcel 使用 obtain 進行分配，使用 recycle 進行釋放。

	分配的代碼實現(xiàn)如下:
public?static?Parcel?obtain()?{
????Parcel?res?=?null;
????synchronized?(sPoolSync)?{
????????if?(sOwnedPool?!=?null)?{
????????????res?=?sOwnedPool;
????????????sOwnedPool?=?res.mPoolNext;
????????????res.mPoolNext?=?null;
????????????sOwnedPoolSize--;
????????}
????}
????if?(res?==?null)?{
????????res?=?new?Parcel(0);
????}?else?{
????????res.mRecycled?=?false;
????????res.mReadWriteHelper?=?ReadWriteHelper.DEFAULT;
????}
????return?res;
}

	其中?sOwnedPool?是靜態(tài)屬性，mPoolNext?是成員屬性，二者都是 Parcel 類型。因此內(nèi)存池中的 Parcel 可以看做是一個表頭為 sOwnedPool 的單鏈表結(jié)構(gòu)。obtain 本質(zhì)上是從鏈表中取出表頭的數(shù)據(jù)。

	對于 IPC 接收到的 Parcel 數(shù)據(jù)分配方式略有不同，因為這些 Parcel 在 C++ 層由系統(tǒng)創(chuàng)建，因此使用不同的鏈表，表頭為?sHolderPool?靜態(tài)屬性。這些 Parcel 通過構(gòu)造函數(shù)?Parcel(long nativePtr)?去構(gòu)建，生命周期由系統(tǒng)管理(mOwnsNativeParcelObject?為?false)，因此需要區(qū)分開來。這類 Parcel 的分配通過重載的?obtain(long)?方法去創(chuàng)建，與上述實現(xiàn)大同小異。

	在釋放過程會將這兩種情況區(qū)分開來:
public?final?void?recycle()?{
????if?(mRecycled)?{
????????Log.wtf(TAG,?"Recycle?called?on?unowned?Parcel.?(recycle?twice?)?Here:?"
????????????????+?Log.getStackTraceString(new?Throwable())
????????????????+?"?Original?recycle?call?(if?DEBUG_RECYCLE):?",?mStack);

????????return;
????}
????mRecycled?=?true;

????//?We?try?to?reset?the?entire?object?here,?but?in?order?to?be
????//?able?to?print?a?stack?when?a?Parcel?is?recycled?twice,?that
????//?is?cleared?in?obtain?instead.

????mClassCookies?=?null;
????freeBuffer();

????if?(mOwnsNativeParcelObject)?{
????????synchronized?(sPoolSync)?{
????????????if?(sOwnedPoolSize?

	釋放操作相當于單鏈表的插入，即將釋放的 Parcel 放入 sOwnPool/sHolderPool 鏈表的頭部。從上述代碼可以看出，Parcel 的分配和釋放過程是后進先出(LIFO)的，即 Parcel obtain 會分配出最近一次釋放的對象。

	Parcel UAF

	通過 LazyValue 的實現(xiàn)以及 Parcel 內(nèi)存管理的策略，我們似乎可以找到一個攻擊場景: 在 Parcel 讀取 LazyValue 之后，將 Parcel 進行釋放，而后再讀取對應(yīng)的 LazyValue，此時如果 Parcel 被分配并填充了敏感數(shù)據(jù)，那么我們的 LazyValue 就可以讀取出這些敏感內(nèi)容造成數(shù)據(jù)泄露。如果泄露的數(shù)據(jù)來自其他進程，且數(shù)據(jù)中包含特權(quán)的 IBinder 等結(jié)構(gòu)，那么還可能造成提權(quán)或者 RCE 的危害！

	為此，我們首先需要找到一個 recycle 后再次使用 LazyValue 的場景。接下來，就是漏洞上場的時間了，出現(xiàn)上述問題的漏洞編號是?CVE-2022-20452[15]，其 patch 代碼為:
diff?--git?a/core/java/android/os/BaseBundle.java?b/core/java/android/os/BaseBundle.java
index?0418a4b..b599028?100644
---?a/core/java/android/os/BaseBundle.java
+++?b/core/java/android/os/BaseBundle.java
@@?-438,8?+438,11?@@
?????????????map.ensureCapacity(count);
?????????}
?????????try?{
+????????????//?recycleParcel?being?false?implies?that?we?do?not?own?the?parcel.?In?this?case,?do
+????????????//?not?use?lazy?values?to?be?safe,?as?the?parcel?could?be?recycled?outside?of?our
+????????????//?control.
?????????????recycleParcel?&=?parcelledData.readArrayMap(map,?count,?!parcelledByNative,
-????????????????????/*?lazy?*/?true,?mClassLoader);
+????????????????????/*?lazy?*/?recycleParcel,?mClassLoader);
?????????}?catch?(BadParcelableException?e)?{
?????????????if?(sShouldDefuse)?{
?????????????????Log.w(TAG,?"Failed?to?parse?Bundle,?but?defusing?quietly",?e);
@@?-1845,7?+1848,6?@@
?????????????//?bundle?immediately;?neither?of?which?is?obvious.
?????????????synchronized?(this)?{
?????????????????initializeFromParcelLocked(parcel,?/*recycleParcel=*/?false,?isNativeBundle);
-????????????????unparcel(/*?itemwise?*/?true);
?????????????}
?????????????return;
?????????}

	問題還是出現(xiàn)在 Bundle 反序列化的過程中，之前說過 Bundle 通過 readFromParcelInner 去進行反序列化，其實現(xiàn)如下:
private?void?readFromParcelInner(Parcel?parcel,?int?length)?{
????final?int?magic?=?parcel.readInt();
????final?boolean?isJavaBundle?=?magic?==?BUNDLE_MAGIC;
????final?boolean?isNativeBundle?=?magic?==?BUNDLE_MAGIC_NATIVE;
????if?(!isJavaBundle?&&?!isNativeBundle)?{
????????throw?new?IllegalStateException("Bad?magic?number?for?Bundle:?0x"
????????????????+?Integer.toHexString(magic));
????}

????if?(parcel.hasReadWriteHelper())?{
????????//?If?the?parcel?has?a?read-write?helper,?it's?better?to?deserialize?immediately
????????//?otherwise?the?helper?would?have?to?either?maintain?valid?state?long?after?the?bundle
????????//?had?been?constructed?with?parcel?or?to?make?sure?they?trigger?deserialization?of?the
????????//?bundle?immediately;?neither?of?which?is?obvious.
????????synchronized?(this)?{
????????????initializeFromParcelLocked(parcel,?/*recycleParcel=*/?false,?isNativeBundle);
????????????unparcel(/*?itemwise?*/?true);
????????}
????????return;
????}
????//?直接使用?Parcel.appendFrom?拷貝原?Parcel?的數(shù)據(jù)
????Parcel?p?=?Parcel.obtain();
????p.appendFrom(parcel,?offset,?length);
????mParcelledData?=?p;

	注意 if 分支外部，這是大部分 Bundle 反序列化的流程，即通過新分配一個 parcel 去拷貝原始數(shù)據(jù)并保存到 mParcelledData 中。因為開發(fā)者知道 parcel 參數(shù)的生命周期不由自身控制。

	而在 if 內(nèi)部，調(diào)用了 initializeFromParcelLocked，其中會使用 readArrayMap 對 parcel 數(shù)據(jù)進行反序列化，這其中是帶有 LazyValue 的。由于開發(fā)者知道 parcel 生命周期不可控，因此在后續(xù)調(diào)用了?unparcel(true)?去強制對每個 LazyValue 進行反序列化以去除對 parcel 數(shù)據(jù)的依賴。

	如果 unparcel 內(nèi)部某些 LazyValue 能夠被攻擊者繞過解析，那么這里就存在一個 UAF 漏洞，后續(xù)讀取 LazyValue 時就能泄露出復(fù)用的 Parcel 中的數(shù)據(jù)。當然，要觸發(fā)這個漏洞需要有幾個前提:

	1.?hasReadWriteHelper 返回 true；

	2.?unparcel 能被繞過；

	對于問題 1，我們可以在 AOSP 代碼中搜索符合條件的 Parcel 類，比如?RemoteViews；

	對于問題 2，我們可以嘗試使其中某個 LazyValue 解析失敗，比如 Parcelable 的類不存在時，代碼會拋出 ClassNotFoundException，被捕捉后再次拋出 BadParcelableException。有趣的是這個異常會在 getValueAt 中被捕捉，如下所示:
@Nullable
final??T?getValueAt(int?i,?@Nullable?Class?clazz,?@Nullable?Class...?itemTypes)?{
????Object?object?=?mMap.valueAt(i);
????if?(object?instanceof?BiFunction)?{
????????try?{
????????????object?=?((BiFunction,?Class[],??>)?object).apply(clazz,?itemTypes);
????????}?catch?(BadParcelableException?e)?{
????????????if?(sShouldDefuse)?{
????????????????Log.w(TAG,?"Failed?to?parse?item?"?+?mMap.keyAt(i)?+?",?returning?null.",?e);
????????????????return?null;
????????????}?else?{
????????????????throw?e;
????????????}
????????}
????????mMap.setValueAt(i,?object);
????}
????return?(clazz?!=?null)???clazz.cast(object)?:?(T)?object;
}

	如果?sShouldDefuse?為 true，那么異常不會被再次拋出，而只是打印異常并返回 null。對于?system_server?而言該條件是滿足的，因為其目的就是為了防止系統(tǒng)重要服務(wù)頻繁崩潰。因此，我們可以將 Bundle 的某個值設(shè)置為另外一個容器，比如 List，然后在容器中存儲一個不存在的 Parcelable，那么 List 中后續(xù)的 LazyValue 將不會被遞歸解析到，我們也就獲得了一個 UAF 對象。

	漏洞利用

	該漏洞的利用過程比較曲折，由于漏洞已經(jīng)修復(fù)，因此筆者對于復(fù)現(xiàn)的興趣缺缺。此外原作者也公開了詳細利用思路和漏洞利用代碼，感興趣的可以自行參考:

	??Exploit for CVE-2022-20452, privilege escalation on Android from installed app to system app (or another app) via LazyValue using Parcel after recycle()[16]

	這里提煉一下其中值得學習的點:

	1.?UAF 漏洞的核心利用目標是獲取目標應(yīng)用的?IApplicationThread?句柄，這通常是應(yīng)用啟動初期使用?attachApplication()?傳遞給?system_server?的，主要用于讓后者給應(yīng)用發(fā)送四大組件的生命周期回調(diào)。通過濫用這個 Binder 句柄可以實現(xiàn) RCE，參考前面的 CVE-2021-0928 (scheduleReceiver)；

	2.?為了能從?system_server?中泄露任意應(yīng)用的 IApplicationThread 句柄，需要兩個條件。首先是有一個接口可以發(fā)送 Parcelable 數(shù)據(jù)并將其取回，AppWidgetHost、Notification.contentView、Mediasession 都可以滿足，作者選用的是 MediaSession.get/setQueue 接口；

	3.?其次，要使得 UAF 對象能被包含 IApplicationThread 的 Parcel 復(fù)用，需要準確的時機。但是 attachApplication 只在應(yīng)用啟動時一個很小的時間窗口中被調(diào)用，因此作者尋找其中可能存在的鎖去拓展這個窗口；

	4.?ParceledListSlice 是一個在 IPC 間傳輸?shù)奶厥鈹?shù)據(jù)結(jié)構(gòu)，在其數(shù)據(jù)量小時可以同步傳輸，而對于大量的數(shù)據(jù)，會將其轉(zhuǎn)換為 binder 發(fā)送給對方然后進行異步傳輸；

	5.?ActivityManager.moveTaskToFront()?調(diào)用時可以提供 ActivityOptions 參數(shù)，以 Bundle 形式進行封裝，并在 system_server 端進行反序列化。因此攻擊者可以在 Bundle 中加入 ParceledListSlice 類型的數(shù)據(jù)，從而在反序列化時回調(diào)到自身進行阻塞。該函數(shù)調(diào)用時候持有?mGlobalLock?鎖，因此可以阻塞 attachApplication 的執(zhí)行，從而更好地構(gòu)造 UAF 風水；

	6.?由于調(diào)用了 moveTaskToFront，種種原因?qū)е聼o法使用 startActivity 來啟動目標應(yīng)用，因此作者使用 ContentProvider 來啟動目標應(yīng)用。

	7.?在我們的 UAF LazyValue Parcel 被成功占位后，對應(yīng)的 IApplicationThread 實際上在比較靠前的位置，但我們的 LazyValue 所在位置比較靠后因此無法讀取到對應(yīng) binder。解決方案是可以找其他占位對象，不過作者這里利用了一個新的漏洞?CVE-2022-20474[17]，即 readLazyValue 方法中 objectLenth 只檢查了證書溢出，卻沒檢查負數(shù)的情況，因此設(shè)置負數(shù)的 prefixLength 實際上可以讀取 Parcel 前方的數(shù)據(jù)，從而繞過該限制。

	其他還有億點細節(jié)，就需要動手復(fù)現(xiàn)才能真正理解了。理論上該漏洞可以影響安全補丁在 2022-11 之前的 Android 13 設(shè)備。 攻擊的目標應(yīng)用可以是任意應(yīng)用，因此可以選擇?Settings.apk，其 UID=system，攻擊成功后就相當于獲取到了 system 權(quán)限。這在 Goole VRP 中應(yīng)該是 10 萬刀樂的標準。

	總結(jié)

	本文算是筆者學習 Android 反序列化漏洞的一個筆記，按照時間線記錄了幾個公開的經(jīng)典反序列化漏洞，并且介紹相關(guān)的修復(fù)策略以及繞過方法。從中我們可以看到，Parcel 作為輕量級的序列化方案，許多操作都需要手動管理，這導(dǎo)致了許多讀寫不匹配的問題，雖然后續(xù)引進了 LazyBundle 優(yōu)化，但又引發(fā)了新的內(nèi)存管理問題，使得傳統(tǒng)二進制的 UAF 甚至 Double Free 類漏洞可以在 Java 世界重現(xiàn)。

	漏洞本身只是一個引子，指導(dǎo)我們未來的研究方向。從這些漏洞中，我們也可以發(fā)現(xiàn) Security By Default 的重要性，比如序列化 Java 容器導(dǎo)致的類型擦除問題和 Bundle 的序列化問題。在后期雖然嘗試進行了緩釋，但由于歷史負擔，很多不安全的設(shè)計只能縫縫補補延續(xù)下去，這也是后續(xù)挖掘和審計其他產(chǎn)品漏洞的一個重要著手點。

	參考資料

	??ReparcelBug[18]

	??ReparcelBug2[19]

	??LeakValue[20]

	??Blackhat EU22 Android parcels: the bad, the good and the better - Introducing Android’s Safer Parcel[21]

	引用鏈接

	[1]?Parcel:?https://developer.android.com/guide/components/activities/parcelables-and-bundles

	[2]?Android 進程間通信與逆向分析:?https://evilpan.com/2020/07/11/android-ipc-tips/

	[3]?GetStringRegion:?https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html

	[4]?Android 8.0 中的版本:?http://androidxref.com/8.0.0_r4/xref/frameworks/base/core/java/android/os/Parcel.java#writeValue

	[5]?patch:?https://android.googlesource.com/platform/frameworks/base/+/5bab9da%5E%21/

	[6]?ReparcelBug - PoC for CVE-2017-0806:?https://github.com/michalbednarski/ReparcelBug

	[7]?CVE-2017-0806 原理分析:?https://github.com/michalbednarski/IntentsLab/issues/2#issuecomment-344365482

	[8]?Bundle風水——Android序列化與反序列化不匹配漏洞詳解:?https://xz.aliyun.com/t/2364

	[9]?LazyBundle(9ca6a5):?https://cs.android.com/android/_/android/platform/frameworks/base/+/9ca6a5e21a1987fd3800a899c1384b22d23b6dee

	[10]?CVE-2021-0928, writeToParcel/createFromParcel serialization mismatch in android.hardware.camera2.params.OutputConfiguration:?https://github.com/michalbednarski/ReparcelBug2

	[11]?Type Erasure:?https://www.baeldung.com/java-type-erasure

	[12]?readSerializable/ObjectInputStream 不需要指定 ClassLoader:?https://cs.android.com/android/platform/superproject/+/master:libcore/ojluni/src/main/java/java/io/ObjectInputStream.java;drc=9b25969d7bf3e31c5b7fec5b34c37a304b6a7fa7;l=678?q=libcore%2Fojluni%2Fsrc%2Fmain%2Fjava%2Fjava%2Fio%2FObjectInputStream.java&ss=android%2Fplatform%2Fsuperproject

	[13]?繞過 Hidden API 的限制:?https://www.xda-developers.com/bypass-hidden-apis/

	[14]?Parcel.enforceNoDataAvail:?https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/os/Parcel.java;l=961;drc=9b25969d7bf3e31c5b7fec5b34c37a304b6a7fa7?q=enforceNoDataAvail&sq=&ss=android%2Fplatform%2Fsuperproject

	[15]?CVE-2022-20452:?https://android.googlesource.com/platform/frameworks/base/+/1aae720772a86e2db682d2e9ed77937334e475f3%5E%21/

	[16]?Exploit for CVE-2022-20452, privilege escalation on Android from installed app to system app (or another app) via LazyValue using Parcel after recycle():?https://github.com/michalbednarski/LeakValue

	[17]?CVE-2022-20474:?https://android.googlesource.com/platform/frameworks/base/+/569c3023f839bca077cd3cccef0a3bef9c31af63%5E%21/

	[18]?ReparcelBug:?https://github.com/michalbednarski/ReparcelBug

	[19]?ReparcelBug2:?https://github.com/michalbednarski/ReparcelBug2

	[20]?LeakValue:?https://github.com/michalbednarski/LeakValue

	[21]?Blackhat EU22 Android parcels: the bad, the good and the better - Introducing Android’s Safer Parcel:?https://www.blackhat.com/eu-22/briefings/schedule/index.html#android-parcels-the-bad-the-good-and-the-better---introducing-androids-safer-parcel-28404

	編輯：黃飛

	?