前言

Javascript中的數(shù)組和數(shù)組對(duì)象一直都是編程人員優(yōu)化的主要目標(biāo)，一般來說，數(shù)組只會(huì)包含一些基本類型數(shù)據(jù)，比如說32位整數(shù)或字符等等。因此，每個(gè)引擎都會(huì)對(duì)這些對(duì)象進(jìn)行某些優(yōu)化，并提升不同元素類型的訪問速度和密集型表示。

[[248537]]

在JavaScriptCore中，JavaScript引擎是在WebKit中實(shí)現(xiàn)的，其中每一個(gè)存儲(chǔ)在對(duì)象中的元素都代表著一個(gè)IndexingType值，一個(gè)8位整數(shù)代表一套Flag組合，具體的參數(shù)定義可以在IndexingType.h中找到。接下來，引擎會(huì)檢測(cè)一個(gè)對(duì)象中indexing的類型，然后決定使用哪一條快速路徑，其中最重要的一種indexing類型就是ArrayWithUndecided，它表示的是所有元素均為未定義(undefined)，而且沒有存儲(chǔ)任何實(shí)際的值。在這種情況下，引擎為了提升性能，會(huì)讓這些元素保持未初始化。

分析

下面，我們一起看一看舊版本中實(shí)現(xiàn)Array.prototype.concat的代碼(ArrayPrototype.cpp)：

EncodedJSValueJSC_HOST_CALL arrayProtoPrivateFuncConcatMemcpy(ExecState* exec)  
{  
    ...  
    unsigned resultSize =checkedResultSize.unsafeGet();  
    IndexingType firstType =firstArray->indexingType();  
    IndexingType secondType =secondArray->indexingType();  
    IndexingType type =firstArray->mergeIndexingTypeForCopying(secondType); // [[ 1 ]]  
    if (type == NonArray ||!firstArray->canFastCopy(vm, secondArray) || resultSize >=MIN_SPARSE_ARRAY_INDEX) {  
        ...  
    }  
    JSGlobalObject* lexicalGlobalObject =exec->lexicalGlobalObject();  
    Structure* resultStructure =lexicalGlobalObject->arrayStructureForIndexingTypeDuringAllocation(type);  
    if(UNLIKELY(hasAnyArrayStorage(resultStructure->indexingType())))  
        return JSValue::encode(jsNull());  
   ASSERT(!lexicalGlobalObject->isHavingABadTime());  
    ObjectInitializationScopeinitializationScope(vm);  
    JSArray* result =JSArray::tryCreateUninitializedRestricted(initializationScope, resultStructure,resultSize);  
    if (UNLIKELY(!result)) {  
        throwOutOfMemoryError(exec, scope);  
        return encodedJSValue();  
    }  
    if (type == ArrayWithDouble) {  
        [[ 2 ]]  
        double* buffer =result->butterfly()->contiguousDouble().data();  
        memcpy(buffer,firstButterfly->contiguousDouble().data(), sizeof(JSValue) *firstArraySize);  
        memcpy(buffer + firstArraySize,secondButterfly->contiguousDouble().data(), sizeof(JSValue) *secondArraySize);  
    } else if (type != ArrayWithUndecided) {  
... 

這個(gè)函數(shù)主要用來判斷結(jié)果數(shù)組[[1]]的indexing類型，我們可以看到，如果indexing類型為ArrayWithDouble，它將會(huì)選擇[[2]]作為快速路徑。接下來，我們看一看：

mergeIndexingTypeForCopying的實(shí)現(xiàn)代碼，這個(gè)函數(shù)主要負(fù)責(zé)在Array.prototype.concat被調(diào)用時(shí)，判斷結(jié)果數(shù)組的indexing類型：

inlineIndexingType JSArray::mergeIndexingTypeForCopying(IndexingType other)  
{  
    IndexingType type = indexingType();  
    if (!(type & IsArray && other& IsArray))  
        return NonArray;  
    if (hasAnyArrayStorage(type) ||hasAnyArrayStorage(other))  
        return NonArray;  
    if (type == ArrayWithUndecided)  
        return other; [[ 3 ]]  
... 

我們可以看到在這種情況下，有一個(gè)輸入數(shù)組的indexing類型為ArrayWithUndecided，結(jié)果indexing類型將會(huì)是另一個(gè)數(shù)組的indexing類型。因此，如果我們我們用一個(gè)indexing類型為ArrayWithUndecided的數(shù)組和另一個(gè)indexing類型為ArrayWithDouble的數(shù)組去調(diào)用Array.prototype.concat方法的話，我們將會(huì)按照快速路徑[[2]]運(yùn)行，并將兩個(gè)數(shù)組進(jìn)行拼接。

這段代碼并不能保證這兩個(gè)“butterfly”(JavaScript引擎攻擊技術(shù)里的一種概念，詳情請(qǐng)參考【這篇文章】)在代碼調(diào)用memcpy之前能夠正確初始化。這也就意味著，如果我們能夠找到一條允許我們創(chuàng)建一個(gè)未初始化數(shù)組并將其傳遞給Array.prototype.concat的代碼路徑，那我們就能夠在堆內(nèi)存中擁有一個(gè)包含了未初始化值的數(shù)組對(duì)象了，而且它的indexing類型還不是ArrayWithUndecided。從某種程度上來說，這個(gè)安全問題跟lokihardt在2017年報(bào)告的一個(gè)舊漏洞有些相似，只不過利用方式不同。

在創(chuàng)建這種數(shù)組對(duì)象時(shí)，可以利用NewArrayWithSize DFG JIT的操作碼來實(shí)現(xiàn)，在對(duì)FTLLowerDFGToB3.cpp中FTL所實(shí)現(xiàn)的allocateJSArray操作碼進(jìn)行分析之后，我們可以看到這個(gè)數(shù)組將會(huì)包含未初始化的值。引擎根本不需要對(duì)數(shù)組進(jìn)行初始化，因?yàn)檫@個(gè)數(shù)組的indexing類型為ArrayWithUndecided。

ArrayValuesallocateJSArray(LValue publicLength, LValue vectorLength, LValue structure,LValue indexingType, bool shouldInitializeElements = true, boolshouldLargeArraySizeCreateArrayStorage = true)  
{  
    [ ... ]  
    initializeArrayElements(  
       indexingType,  
       shouldInitializeElements ?m_out.int32Zero : publicLength, vectorLength,  
       butterfly);  
...  
voidinitializeArrayElements(LValue indexingType, LValue begin, LValue end, LValuebutterfly)  
{  
    if (begin == end)  
        return;    
    if (indexingType->hasInt32()) {  
        IndexingType rawIndexingType =static_cast<IndexingType>(indexingType->asInt32());  
        if (hasUndecided(rawIndexingType))  
            return;  // [[ 4 ]] 

語句new Array(n)在被FTL JIT編譯時(shí)將會(huì)觸發(fā)[[4]]，然后返回一個(gè)indexing類型為ArrayWithUndecided的數(shù)組，其中就包含未初始化的元素。

漏洞利用

清楚了之前所介紹的漏洞原理之后，想必觸發(fā)這個(gè)漏洞也并非難事：我們可以不斷重復(fù)調(diào)用一個(gè)使用new Array()方法來創(chuàng)建數(shù)組的函數(shù)，然后調(diào)用concat方法將這個(gè)數(shù)組和一個(gè)只包含double類型數(shù)據(jù)的數(shù)組進(jìn)行拼接。在調(diào)用夠足夠次數(shù)之后，F(xiàn)TL編譯器將會(huì)對(duì)其進(jìn)行編譯。

這份【漏洞利用代碼】可以利用這個(gè)漏洞來泄漏一個(gè)目標(biāo)對(duì)象的內(nèi)存地址，實(shí)現(xiàn)機(jī)制是通過我們所創(chuàng)建的對(duì)象進(jìn)行內(nèi)存噴射，在觸發(fā)這個(gè)漏洞之后，我們就能夠從代碼所返回的數(shù)組中找到目標(biāo)對(duì)象的地址了。

總結(jié)

這個(gè)漏洞目前已經(jīng)在iOS 12和macOS Mojave的最新版本(Safari)中修復(fù)了，該漏洞的CVE編號(hào)為CVE-2018-4358。