0x00 寫在前面

第一次接觸FILE結(jié)構(gòu)體遂庄，是在BCTF2018的baby_arena中头岔，利用了FSOP塔拳，當(dāng)時感覺結(jié)構(gòu)體中字段太多了，沒有理清楚到底是什么關(guān)系峡竣。也是時隔非常非常非常久靠抑，咸魚的我終于開始系統(tǒng)的學(xué)習(xí)一下FILE結(jié)構(gòu)體。本篇基于libc-2.27源碼對該版本文件流的數(shù)據(jù)結(jié)構(gòu)适掰、相關(guān)操作以及一些常見的漏洞利用方法進行分析颂碧。

0x01 數(shù)據(jù)結(jié)構(gòu)

• _IO_FILE_plus
  雖然每次都是說FILE結(jié)構(gòu)體，但其實FILE結(jié)構(gòu)體的外層還有一個結(jié)構(gòu)體类浪，叫做_IO_FILE_plus結(jié)構(gòu)體载城。該結(jié)構(gòu)體在glibc/libio/libioP.h中定義如下:

struct _IO_FILE_plus
{
    FILE file;
    const struct _IO_jump_t *vtable;
}

中間包含了一個我們常說的FILE結(jié)構(gòu)體，以及_IO_jump_t的一個虛表結(jié)構(gòu)體费就。

• FILE/_IO_FILE
  在glibc/libio/bits/types/FILE.h中可以看到FILE結(jié)構(gòu)體其實就是_IO_FILE結(jié)構(gòu)體诉瓦。

typedef struct _IO_FILE FILE;

_IO_FILE結(jié)構(gòu)體在glibc/libio/bits/libio.h中定義如下：

struct _IO_FILE
{
    int _flags;  /* High-order word is _IO_MAGIC; rest is flags. */

    /* The following pointers correspond to the C++ streambuf protocol. */
    char *_IO_read_ptr;        /* Current read pointer */
    char *_IO_read_end;      /* End of get area. */
    char *_IO_read_base;    /* Start of puback+get area. */
    char *_IO_write_base;   /* Start of put area. */
    char *_IO_write_ptr;      /* Current put pointer. */
    char *_IO_write_end;    /* End of put area. */
    char *_IO_buf_base;     /* Start of reserve area. */
    char *_IO_buf_end;      /* End of reserve area. */
 
    /* The following fields are used to support backing up and undo. */
    char *_IO_save_base;           /* Pointer to start of non-current get area. */
    char *_IO_backup_base;      /* Pointer to first valid character of backup area. */
    char *_IO_save_end;            /* Pointer to end of non-current get area. */
    ......
    struct _IO_FILE *_chain;
    int _fileno;
    ......
    int _flags2;
    ......
#ifdef _IO_USE_OLD_IO_FILE
};

struct _IO_FILE_complete
{
    struct _IO_FILE _file;
#endif
    ......
    size_t __pad5;
    int _mode;
    char _unused2[15 * sizeof(int) - 4 * sizeof(void*) - sizeof(size_t)];
};

其中_flags字段標(biāo)志了該FILE結(jié)構(gòu)體的讀寫等屬性，該字段的前2個字節(jié)固定為0xFBAD的魔術(shù)頭力细，其具體數(shù)值在glibc/libio/libio.h中進行宏定義如下：

/* Magic number and bits for the _flags field.  The magic number is
   mostly vestigial, but preserved for compatibility.  It occupies the
   high 16 bits of _flags; the low 16 bits are actual flag bits.  */
#define _IO_MAGIC         0xFBAD0000 /* Magic number */
#define _IO_MAGIC_MASK    0xFFFF0000
#define _IO_USER_BUF          0x0001 /* Don't deallocate buffer on close. */
#define _IO_UNBUFFERED        0x0002
#define _IO_NO_READS          0x0004 /* Reading not allowed.  */
#define _IO_NO_WRITES         0x0008 /* Writing not allowed.  */
#define _IO_EOF_SEEN          0x0010
#define _IO_ERR_SEEN          0x0020
#define _IO_DELETE_DONT_CLOSE 0x0040 /* Don't call close(_fileno) on close.  */
#define _IO_LINKED            0x0080 /* In the list of all open files.  */
#define _IO_IN_BACKUP         0x0100
#define _IO_LINE_BUF          0x0200
#define _IO_TIED_PUT_GET      0x0400 /* Put and get pointer move in unison.  */
#define _IO_CURRENTLY_PUTTING 0x0800
#define _IO_IS_APPENDING      0x1000
#define _IO_IS_FILEBUF        0x2000
                           /* 0x4000  No longer used, reserved for compat.  */
#define _IO_USER_LOCK         0x8000

_IO_read_ptr字段為輸入緩沖區(qū)的當(dāng)前地址
_IO_read_end字段為輸入緩沖區(qū)的結(jié)束地址
_IO_read_base字段為輸入緩沖區(qū)的起始地址
_IO_write_base字段為輸出緩沖區(qū)的起始地址
_IO_write_ptr字段為輸出緩沖區(qū)的當(dāng)前地址
_IO_write_end字段為輸出緩沖區(qū)的結(jié)束地址
_IO_buf_base字段為輸入輸出緩沖區(qū)的起始地址
_IO_buf_end字段為輸入輸出緩沖區(qū)的結(jié)束地址
_chain字段為指向下一個_IO_FILE結(jié)構(gòu)體的指針睬澡，在gilbc/libio/libioP.h中有如下聲明：

extern struct _IO_FILE_plus *_IO_list_all;

該變量為一個單鏈表的頭結(jié)點，該單鏈表用于管理程序中所有的FILE結(jié)構(gòu)體眠蚂，并通過_chain字段索引下一個FILE結(jié)構(gòu)體煞聪，每個程序中該鏈表的最后3個節(jié)點從后往前固定為_IO_2_1_stdin、_IO_2_1_stdout河狐、_IO_2_1_stderr米绕，之前是用戶新申請的FILE結(jié)構(gòu)體瑟捣，每次新申請的FILE結(jié)構(gòu)體會插在該鏈表的表頭。大概長成下面這樣：

_IO_list_all

_IO_2_1_stdin_

• _IO_jump_t
  該結(jié)構(gòu)體在glibc/libio/libioP.h中定義如下:

struct _IO_jump_t
{
    JUMP_FIELD(size_t, __dummy);
    JUMP_FIELD(size_t, __dummy2);
    JUMP_FIELD(_IO_finish_t, __finish);
    JUMP_FIELD(_IO_overflow_t, __overflow);
    JUMP_FIELD(_IO_underflow_t, __underflow);
    JUMP_FIELD(_IO_underflow_t, __uflow);
    JUMP_FIELD(_IO_pbackfail_t, __pbackfail);
    /* showmany */
    JUMP_FIELD(_IO_xsputn_t, __xsputn);
    JUMP_FIELD(_IO_xsgetn_t, __xsgetn);
    JUMP_FIELD(_IO_seekoff_t, __seekoff);
    JUMP_FIELD(_IO_seekpos_t, __seekpos);
    JUMP_FIELD(_IO_setbuf_t, __setbuf);
    JUMP_FIELD(_IO_sync_t, __sync);
    JUMP_FIELD(_IO_doallocate_t, __doallocate);
    JUMP_FIELD(_IO_read_t, __read);
    JUMP_FIELD(_IO_write_t, __write);
    JUMP_FIELD(_IO_seek_t, __seek);
    JUMP_FIELD(_IO_close_t, __close);
    JUMP_FIELD(_IO_stat_t, __stat);
    JUMP_FIELD(_IO_showmanyc_t, __showmanyc);
    JUMP_FIELD(_IO_imbue_t, __imbue);
#if 0
    get_column;
    set_column;
#endif
};

如上圖所示崩泡，所有的FILE結(jié)構(gòu)體的虛表指針均指向虛表_IO_file_jumps禁荒，在進行IO操作時，都會調(diào)用到該結(jié)構(gòu)體中的函數(shù)角撞。

0x02 相關(guān)操作

fopen

fopen為stdio庫中的函數(shù)呛伴，其在glibc/include/stdio.h中宏定義如下：

#define fopen(fname, mode) _IO_new_fopen(fname, mode)

由stdio.h宏定義可知，平時我們常用的fopen函數(shù)其實為定義在glibc/libio/iofopen.c中的_IO_new_fopen函數(shù)谒所，該函數(shù)直接調(diào)用了__fopen_internal函數(shù)热康。

__fopen_internal

• __fopen_internal函數(shù)中第58-65行聲明了一個locked_FILE結(jié)構(gòu)體變量指針new_f，該結(jié)構(gòu)體中主要包含了_IO_FILE_plus和_IO_wide_data兩個結(jié)構(gòu)劣领，并為該聲明的變量分配了空間姐军。
• __fopen_internal函數(shù)中第72行調(diào)用了_IO_no_init函數(shù)對新申請的locked_FILE結(jié)構(gòu)體進行了初始化，該函數(shù)在glibc/libio/genops.c中定義如下：
  
  _IO_no_init
  
  其中調(diào)用的_IO_old_init函數(shù)定義于其上方：
  
  _IO_old_init
  
  不難看出尖淘，_IO_old_init函數(shù)主要是對_IO_FILE_plus結(jié)構(gòu)體中的各個元素進行初始化奕锌，而_IO_no_init主要是對_IO_wide_data 結(jié)構(gòu)體中的各個元素進行初始化。通過兩個結(jié)構(gòu)體的初始化村生，初步猜測歇攻，_IO_FILE_plus結(jié)構(gòu)體中元素及虛表主要用于單字節(jié)的文件流處理流程中，_IO_wide_data結(jié)構(gòu)體中的元素及虛表主要用于寬字節(jié)的文件流處理流程中梆造。
• __fopen_internal函數(shù)中第73行調(diào)用了_IO_JUMPS函數(shù)對結(jié)構(gòu)體的虛表進行了初始化，_IO_JUMPS函數(shù)在glibc/libio/libioP.h中宏定義如下：

#define _IO_JUMPS(THIS) (THIS)->vtable

即將_IO_FILE_plus結(jié)構(gòu)體中的虛表指針賦值為虛表_IO_file_jumps的地址葬毫。

• __fopen_internal函數(shù)中第74行調(diào)用了_IO_new_file_init_internal函數(shù)將新初始化的結(jié)構(gòu)體鏈入_IO_list_all鏈表的頭部镇辉，該函數(shù)在glibc/libio/fileops.c中定義如下：
  
  _IO_new_file_init_internal
  
  該函數(shù)主要實現(xiàn)了將初始化好的_IO_FILE_plus結(jié)構(gòu)體鏈入_IO_list_all鏈表頭部的功能，其中鏈入鏈表的功能主要是由_IO_link_in函數(shù)進行實現(xiàn)贴捡，該函數(shù)定義在glibc/libio/genops.c中忽肛。除了實現(xiàn)鏈入功能外，還對_IO_FILE_plus結(jié)構(gòu)體加入了相應(yīng)的屬性烂斋，如CLOSED_FILEBUF_FLAGS(可關(guān)閉枫夺？)屬性以及_IO_link_in函數(shù)中的_IO_LINKED已鏈接屬性第115行，對_fileno函數(shù)賦值為-1列林，該字段代表該文件流在_IO_list_all鏈表中的序號联喘，此處賦值為-1相當(dāng)于對該字段進行一個非法數(shù)值的初始化，后面會有_IO_file_is_open函數(shù)專門對_fileno數(shù)值是否合法進行check切蟋。
• __fopen_internal函數(shù)中第78行調(diào)用了_IO_file_open函數(shù)，開始執(zhí)行真正意義上的fopen操作，該函數(shù)在glibc/libio/fileops.c中定義如下：

versioned_symbol(libc, _IO_new_file_fopen, _IO_file_fopen, GLIBC_2_1);

即_IO_file_fopen函數(shù)等價于_IO_new_file_fopen函數(shù)蒿讥，該函數(shù)定義于同一文件的第211行(太長了就不一次性全部貼了)。

_IO_new_file_fopen(1)

#define _IO_file_is_open(__fp) ((__fp)->_fileno != -1)

即通過檢查FILE結(jié)構(gòu)體的_fileno是否為合法序號來判斷檢該文件流是否為已打開狀態(tài)敢伸。
第二個操作則是通過mode，即fopen函數(shù)第二個參數(shù)的第一個字符來確定該文件流的屬性恒削，并添加對應(yīng)的flag池颈。在寫入flag字段前，代碼中有3個比那里那個來分別存儲不同的屬性钓丰，這三個變量分別是omode躯砰、oflags、read_write携丁，其中omode標(biāo)志文件的讀寫屬性琢歇，oflags標(biāo)志文件的修改方式，read_write標(biāo)志文件內(nèi)容的讀寫方式梦鉴。有如下對應(yīng)關(guān)系：

_IO_new_file_fopen繼續(xù)往后走李茫，代碼如下：

_IO_new_file_fopen(2)

在將所有附屬性遍歷完后，會調(diào)用_IO_file_open函數(shù)用于打開文件并返回句柄存筏，該函數(shù)有6個參數(shù)宠互，該函數(shù)在glibc/libio/fileops.c中定義如下：

_IO_file_open

strong_alias(__libc_open64 ,  __open);
...
strong_alias(__open64_nocancel, __open_nocancel);

以及還有在某些情況__open64_nocancel函數(shù)可以等價為__libc_open64函數(shù)的定義。在同一文件中汁掠，兩個函數(shù)定義如下：

__libc_open64

__open64_nocancel

if(result != NULL)
{
    cs = strstr(last_recognized +1 , ",ccs=");
    if(cs != NULL)
    {
        ......                  //大概是給_wide_data中的各元素賦值
        result->_mode = 1;
    }
}

return result;

• return后返回到__fopen_internal函數(shù)中乐尊，此時執(zhí)行到了__fopen_internal函數(shù)的最后一步，如果上面調(diào)用_IO_file_fopen函數(shù)打開文件失敗划址，則執(zhí)行函數(shù)第81-83行：調(diào)用_IO_un_link函數(shù)將鏈入_IO_list_all的結(jié)構(gòu)體摘除扔嵌，并free掉為其申請的空間，之后return NULL夺颤；若打開文件成功对人，則會執(zhí)行第79行：調(diào)用__fopen_maybe_mmap函數(shù)并返回。該函數(shù)在glibc/libio/iofopen.c中定義如下拂共；
  
  __fopen_maybe_mmap
  
  該函數(shù)會判斷_flags2字段中是否含有_IO_FLAGS2_MMAP位，即在打開文件時是否有m屬性姻几，還會檢查_flags字段中是否含有_IO_NO_WRITES位宜狐，即在打開文件時是否有r屬性势告。即在打開文件時有rm兩個屬性，則會執(zhí)行函數(shù)的主體部分抚恒，調(diào)用_IO_JUMPS_FILE_plus函數(shù)將重置FILE結(jié)構(gòu)體的vtable虛表咱台，該函數(shù)在glibc/libio/libioP.h中定義如下：
  
  _IO_JUMPS_FILE_plus

以上，完成了對fopen函數(shù)源碼的分析俭驮，該函數(shù)主要進行了3個操作：為文件流申請空間回溺；初始化FILE結(jié)構(gòu)體及虛表，包括將文件流鏈入_IO_list_all鏈表中混萝；打開文件流遗遵，包括讀取文件屬性以及利用系統(tǒng)調(diào)用打開文件。
通過閱讀源碼逸嘀，對文件屬性有了船新的認(rèn)識：

• 除了日常用到的r/w/a/b/+之外還有x/m/c/e這4個屬性车要，而且作為主屬性的r/w/a必須在fopen第二個參數(shù)的開頭，即只能wb而不能bw崭倘。
• 在正常編寫代碼時宏觀能夠感到打開文件方式不一樣的屬性有r/w/a/+/x翼岁，而m/c/e這三個屬性的采用，僅僅會在系統(tǒng)進行打開文件操作過程中進行一些不太影響大局的判斷操作司光，在宏觀上感覺不到琅坡。這可能也是FILE結(jié)構(gòu)體中_flags和_flags2兩個字段的區(qū)別。
• 在上一點中所沒提到的b屬性残家，雖然一直知道是以二進制方式打開文件榆俺，但是在_IO_new_file_fopen函數(shù)中的關(guān)于副屬性的switch...case語句中，b屬性并沒有什么卵用跪削。沒有加入任何flag標(biāo)志位谴仙，只是將last_recognized賦值為b，即最后一個識別的屬性是b碾盐。就算不考慮后續(xù)代碼晃跺，只看switch...case語句的結(jié)果，當(dāng)b屬性后面跟有其他屬性毫玖，那么b屬性的case中沒有留下任何東西(其他屬性多多少少修改了_flags/_flags2字段)掀虎。

fread

fread函數(shù)的一般用法為

fread( void *buffer, size_t size, size_t count, FILE *stream );

該函數(shù)共有4個參數(shù)，buffer代表接收從文件讀取數(shù)據(jù)的變量首地址付枫，size代表每個對象的大小烹玉，count代表對象的個數(shù)，stream是代表文件流阐滩。即該函數(shù)實現(xiàn)了從stream中讀size * count字節(jié)數(shù)據(jù)并賦給buffer所指向的地址二打。該函數(shù)在glibc/libio/iofread.c中有如下宏定義：

weak_alias(_IO_fread , fread)

即fread函數(shù)原形為_IO_fread函數(shù)，該函數(shù)在同一文件中定義如下：

_IO_fread

CHECK_FILE

_IO_file_xsgetn(1)

_IO_doallocbuf

_IO_file_doallocate

struct stat st

_IO_setb

_IO_file_xsgetn(2)

• n <= 4K
  因為是剛剛完成初始化的文件流，第一次進行fread時所以會進入第1341行的判斷語句饲化，則會調(diào)用__underflow函數(shù)莽鸭，該函數(shù)在glibc/libio/genops.c中定義如下：
  

  __underflow
  
  該函數(shù)經(jīng)過一系列檢查后調(diào)用了_IO_UNDERFLOW函數(shù)，該函數(shù)即虛表中的__underflow字段吃靠，對應(yīng)_IO_new_file_underflow函數(shù)硫眨，該函數(shù)定義在glibc/libio/fileop.c中，進入函數(shù)后按照當(dāng)前狀態(tài)會直接跳過前面的檢查巢块，直接從第520行開始執(zhí)行礁阁，如下圖：
  
  _IO_new_file_underflow(partial)
  
  首先將read和write的6個字段都初始化為_IO_buf_base，之后調(diào)用_IO_SYSREAD函數(shù)嘗試從fp中讀_IO_buf_end - _IO_buf_base即4K大小的數(shù)據(jù)到從_IO_buf_base開始的空間中族奢，該函數(shù)的原形為虛表中的__read姥闭，對應(yīng)_IO_file_read函數(shù)。該函數(shù)在glibc/libio/fileops.c中定義如下：
  
  _IO_file_read
  
  該函數(shù)再往下就是調(diào)用__read()或__read_nocancel()直接進行系統(tǒng)調(diào)用進行讀入越走，返回值為實際讀取的大小棚品，賦值給count。若正常讀取成功廊敌，則會將_IO_read_end和offset字段增加count的大小铜跑，返回_IO_read_ptr的值。調(diào)用完該函數(shù)后骡澈，返回_IO_file_xsgetn函數(shù)锅纺，此時該文件中最多4K大小的數(shù)據(jù)已經(jīng)被讀入到了緩存緩沖區(qū)中，且_IO_read_base和_IO_read_end兩個指針分別對應(yīng)這想要讀入的數(shù)據(jù)的起始位置和終止位置秧廉，相當(dāng)于輸入緩沖區(qū)伞广，此時執(zhí)行continue，重新開始循環(huán)疼电，進入第1316行的判斷語句嚼锄，直接調(diào)用memcpy函數(shù)，將數(shù)據(jù)從輸入緩沖區(qū)中拷貝如目標(biāo)變量中蔽豺，_IO_read_ptr字段加上相應(yīng)大小区丑，此時所有數(shù)據(jù)全部讀入，want賦值為0，一路執(zhí)行沧侥，最后跳出循環(huán)可霎。

• n > 4K
  若讀取數(shù)據(jù)大小大于4K，則不會進入第1341行的判斷句宴杀，而是繼續(xù)往下執(zhí)行：
  

  _IO_file_xsgetn(3)
  
  緊接著調(diào)用了_IO_setg和_IO_setp兩個函數(shù)癣朗，這兩個函數(shù)在glibc/libio/libioP.h中有宏定義如下：
  
  _IO_setp/_IO_setg
  
  即實現(xiàn)了將FILE結(jié)構(gòu)體中的read和write相關(guān)共6個指針均初始化為_IO_buf_base的功能。隨后在1357行的判斷中旺罢，是將之前分配的緩沖區(qū)大小作為一個block_size旷余，因為這條分支接下來會直接調(diào)用_IO_SYSREAD函數(shù)，將數(shù)據(jù)直接從文件流中讀入變量中而不經(jīng)過緩沖區(qū)扁达，所以為了(優(yōu)化性能正卧？)，每次只讀取block_size大小的數(shù)據(jù)跪解，即4K炉旷。調(diào)用完_IO_SYSREAD后want會減去4K再次進行循環(huán)，直到最后小于4K的一部分叉讥，會和上面n <= 4K經(jīng)歷相同的過程窘行，并退出循環(huán)。

至此节吮，分析完了fread函數(shù)主要流程抽高，尤其是_IO_file_xsgetn函數(shù)的執(zhí)行流程。fread函數(shù)主要進行了1個操作透绩，調(diào)用_IO_file_xsgetn函數(shù)翘骂，當(dāng)然加鎖也是比較重要的。_IO_file_xsgetn函數(shù)帚豪，主要進行了3個操作：調(diào)用_IO_doallocbuf給FILE結(jié)構(gòu)體分配緩沖區(qū)碳竟；當(dāng)n <= block_size時，調(diào)用_IO_file_underflow將文件流中的數(shù)據(jù)讀入緩沖區(qū)再調(diào)用memcpy從緩沖區(qū)拷貝至目標(biāo)變量中狸臣；當(dāng)n > block_size時莹桅，大部分先對齊到block_size，調(diào)用_IO_SYSREAD函數(shù)直接從文件流讀入到目標(biāo)變量烛亦，若還有剩余的數(shù)據(jù)再用老方從走緩沖區(qū)拷貝到目標(biāo)變量中诈泼。
通過閱讀源碼，對FILE結(jié)構(gòu)體以及其中各字段所代表的含義有了船新的認(rèn)識：

• 首先是從_IO_read_ptr到_IO_buf_end這8個字段煤禽，原本認(rèn)為是共申請了3個緩沖區(qū)铐达，通過閱讀源碼后知道了只申請了1個緩沖區(qū)，其中_IO_buf_base和_IO_buf_end指向這個緩沖區(qū)的兩端檬果，其余6個read和write字段沒事的時候都與_IO_buf_base的值相同瓮孙，在進行讀操作時唐断，相當(dāng)于3個read指針起作用控制緩沖區(qū)中的內(nèi)容，可以推出在進行寫操作時杭抠，3個read指針與_IO_buf_base的值相同脸甘，而3個write指針獨起作用控制緩沖區(qū)中的內(nèi)容。
• 其次_IO_save_base到_IO_save_end這3個字段偏灿，因為在該段代碼中只存在幾處判斷丹诀，并沒有實際用處，所以判斷大概是為了保存某個時刻緩沖區(qū)而設(shè)置的指針翁垂。
• 最后是在調(diào)試時發(fā)現(xiàn)的FILE結(jié)構(gòu)體有多種形態(tài)忿墅，比如我在調(diào)試時看到的FILE結(jié)構(gòu)體實際上是glibc/libio/bits/libio.h中定義的_IO_FILE_complete結(jié)構(gòu)體。最終究其原因沮峡，是因為有個宏判斷把定義結(jié)構(gòu)體的大括號給吃掉了。如下圖：
  
  騷騷的宏判斷

fwrite

fwrite函數(shù)的一般用法為

fwrite(const void* buffer, size_t size, size_t count, FILE* stream);

與fread函數(shù)相似亿柑，該函數(shù)共有4個參數(shù)邢疙，buffer代表存儲要寫入文件數(shù)據(jù)的首地址，size代表每個對象的大小望薄，count代表對象的個數(shù)疟游，stream代表文件流。即該函數(shù)實現(xiàn)了將buffer中size * count字節(jié)數(shù)據(jù)寫入stream文件流的操作痕支。該函數(shù)在glibc/libio/iofwrite.c中有如下宏定義：

weak_alias(_IO_fwrite , fwrite)

即fwrite函數(shù)原形為_IO_fwrite函數(shù)颁虐，該函數(shù)在同一文件中定義如下：

_IO_fwrite

_IO_new_file_xsputn(1)

_IO_new_file_xsputn(2)

_IO_new_file_overflow(1)

_IO_new_file_overflow(2)

_IO_new_do_write

• to_do < 4K
  若要寫入的數(shù)據(jù)小于4K惋嚎，則do_write = 0杠氢，不會進入第1275行的判斷語句，而是在1287行直接調(diào)用_IO_default_xsputn函數(shù)進行處理另伍，該函數(shù)在glibc/libio/genops.c中定義如下：
  

  _IO_default_xsputn
  
  該函數(shù)主要實現(xiàn)了將數(shù)據(jù)從變量中拷貝到結(jié)構(gòu)體緩沖區(qū)中的操作鼻百，主要有兩種情況，一種是當(dāng)要拷貝的數(shù)據(jù)大于20字節(jié)時摆尝，會直接調(diào)用__mempcpy進行拷貝温艇，如果小于等于20，則用for循環(huán)逐字節(jié)進行拷貝堕汞，若緩沖區(qū)大小不夠勺爱，則會調(diào)用_IO_OVERFLOW刷新緩沖區(qū)。
  值得注意的是讯检，_IO_default_xsputn函數(shù)僅僅實現(xiàn)了將數(shù)據(jù)從變量中拷貝到了從_IO_write_base到_IO_write_ptr為止的緩沖區(qū)中邻寿，并沒有寫入文件。

• to_do >= 4K
  若要寫入的數(shù)據(jù)大于4K视哑，則do_write被賦值為4K的倍數(shù)，將在第1277行調(diào)用new_do_write函數(shù)進行寫入誊涯，該函數(shù)在glibc/libio/fileops.c中定義如下：
  

  new_do_write
  
  首先會判斷是否具有_IO_IS_APPENDING屬性挡毅，即判斷該文件是由a屬性打開還是由w屬性打開：若為w屬性，則將_offset字段賦值為-1暴构；若為a屬性跪呈，則_offset字段不變，這正是寫文件時覆蓋和追加方式的體現(xiàn)取逾。之后判斷_IO_read_end與_IO_write_base相等耗绿，若不等則調(diào)用_IO_SYSSEEK函數(shù)。對于本次調(diào)用的流程砾隅，這兩個判斷語句不會有太大的影響误阻。主要是在函數(shù)的第457行執(zhí)行了_IO_SYSWRITE函數(shù)，該函數(shù)為虛表中的__write晴埂，即為_IO_new_file_write函數(shù)究反，該函數(shù)在glibc/libio/fileops.c中定義如下：
  
  _IO_new_file_write
  
  該函數(shù)也是通過調(diào)用__write函數(shù)或__write_nocancel函數(shù)進行系統(tǒng)調(diào)用，將to_do長度的數(shù)據(jù)從data中寫入文件中儒洛。調(diào)用完_IO_SYSWRITE函數(shù)后精耐，若讀入成功，即count不為0琅锻，在之后會調(diào)用_IO_adjust_column函數(shù)去更新FILE結(jié)構(gòu)體中的_cur_column字段卦停，該字段代表（文件的行數(shù)+1)向胡，該函數(shù)在glibc/libio/genops.c中定義如下：
  
  _IO_adjust_column
  
  該函數(shù)通過判斷上面通過_IO_SYSWRITE函數(shù)寫入的數(shù)據(jù)中含有多少\n字符來確定文件中增加了多少行。調(diào)用完_IO_adjust_column后返回到new_do_write函數(shù)惊完，之后會調(diào)用_IO_setg函數(shù)以及各種賦值操作將文件流中read僵芹、write相關(guān)6個字段都賦值為_IO_buf_base，類似于初始化的操作专执。綜上淮捆，new_do_write函數(shù)完成了將對齊block_size大小的數(shù)據(jù)不通過緩沖區(qū)，直接從變量寫入文件流的操作本股。從new_do_write函數(shù)返回后攀痊，之前未對齊的剩余的數(shù)據(jù)，則會在下方調(diào)用_IO_default_xsputn函數(shù)拷貝到緩沖區(qū)中拄显。

至此苟径，分析完了fwrite函數(shù)主要流程，尤其是_IO_new_file_xsputn函數(shù)的執(zhí)行流程躬审。fwrite函數(shù)與fread相互對仗棘街，fread是將文件中數(shù)據(jù)直接讀入變量，或先從文件讀入FILE結(jié)構(gòu)體緩沖區(qū)承边，再利用read相關(guān)指針進行間接讀入變量遭殉；fwrite是將數(shù)據(jù)直接從文件中寫入變量或?qū)懭?strong>FILE結(jié)構(gòu)體中的緩沖區(qū)。_IO_new_file_xsputn作為實現(xiàn)fwrite的重要函數(shù)博助，主要進行了****個操作：調(diào)用_IO_new_file_overflow函數(shù)為FILE結(jié)構(gòu)體申請緩沖區(qū)险污；若n < block_size時，直接調(diào)用__mempcpy函數(shù)拷貝到緩沖區(qū)中富岳；若n >= block_size時蛔糯，會將對齊到block_size的部分用系統(tǒng)調(diào)用直接讀入文件，剩余部分按與n < block_size相同的方法拷貝到緩沖區(qū)中窖式。
通過閱讀源碼蚁飒，對fwrite函數(shù)有了船新認(rèn)識：

• 本以為fwrite只是把fread的讀操作變成寫操作，其他都是相同的萝喘。然而fread執(zhí)行完后不論多少數(shù)據(jù)都讀入了變量中淮逻，而fwrite執(zhí)行完后未對齊block_size大小的數(shù)據(jù)仍在緩沖區(qū)中，推測在執(zhí)行fclose函數(shù)或在程序退出時才會真正的寫入文件中阁簸。
• _IO_new_file_overflow函數(shù)并不僅僅有上文中描述的調(diào)用_IO_doallocbuf申請緩沖區(qū)的作用弦蹂，其主要擔(dān)負(fù)著刷新緩沖區(qū)的作用：第一種調(diào)用情況為上文中所提到的，當(dāng)_IO_buf_base字段為空强窖，即還未初始化緩沖區(qū)時凸椿，則會調(diào)用_IO_doallocbuf函數(shù)進行申請緩沖區(qū)；若緩沖區(qū)已經(jīng)初始化翅溺，且_IO_write_end == _IO_write_ptr脑漫，即緩沖區(qū)已滿時髓抑，則會把這些待寫入內(nèi)容寫入文件，之后會將_IO_write_ptr賦值為_IO_buf_base优幸，相當(dāng)于清空緩沖區(qū)的操作吨拍。

fclose

與fopen函數(shù)相同，在glibc/include/stdio.h中有如下宏定義：

#define fclose(fp) _IO_new_fclose(fp)

即fclose函數(shù)的原形為_IO_new_fclose函數(shù)网杆，該函數(shù)在glibc/libio/iofclose.c中定義如下：

_IO_new_fclose

_IO_un_link

_IO_file_close_it

_IO_do_flush

_IO_file_close

_IO_new_file_finish

_IO_default_finish

至此沃于，完成了對fclose函數(shù)流程的分析涩咖，總的來說代碼比較短暫海诲，也都是對前面已經(jīng)執(zhí)行代碼的一個逆過程，因此并沒有太多需要注意的地方檩互，主要還是印證了前面在fwrite結(jié)尾的一個預(yù)測特幔，會在關(guān)閉文件流時去調(diào)用了_IO_do_flush函數(shù)將緩沖區(qū)內(nèi)的數(shù)據(jù)寫入文件。

0x03 利用方法

• 利用偽造stdout進行任意地址讀
  stdout闸昨，即標(biāo)準(zhǔn)輸出蚯斯，默認(rèn)為當(dāng)前終端，其本質(zhì)也為一個FILE結(jié)構(gòu)體饵较，利用這種方法最終達到將任意地址數(shù)據(jù)輸出到終端供我們進行讀的效果拍嵌。因此首先定位到fwrite函數(shù)中輸出的位置，即調(diào)用_IO_SYSWRITE的地方告抄。由前小節(jié)的分析可知撰茎，只有在new_do_write函數(shù)中有對_IO_SYSWRITE的調(diào)用，而調(diào)用new_do_write理論上有兩個地方打洼，一個是在_IO_new_file_xsputn函數(shù)中的第1266行調(diào)用_IO_OVERFLOW函數(shù)中會有調(diào)用龄糊，以及在第1277行直接進行調(diào)用。
  
  調(diào)用_new_do_write
  
  第一種調(diào)用情況募疮，在利用_IO_OVERFLOW函數(shù)通過調(diào)用_IO_do_write函數(shù)炫惩，實現(xiàn)間接調(diào)用new_do_write函數(shù)將_IO_write_base到_IO_write_ptr之間的數(shù)據(jù)進行寫入。
  首先我們需要獲得執(zhí)行到_IO_OVERFLOW函數(shù)的條件阿浓，主要還是第1262行的to_do + must_flush > 0他嚷，因為正常函數(shù)調(diào)用時傳進來的to_do均大于0，因此必然會進入該語句芭毙，所以前置條件幾乎算是沒有筋蓖；
  接下來進入_IO_OVERFLOW函數(shù)內(nèi)部進行分析調(diào)用new_do_write函數(shù)的條件。
  
  條件判斷(1)
  
  可以看到在我們最終調(diào)用_IO_do_write函數(shù)之前會有2個比較關(guān)鍵的判斷：第747行判斷是否有寫權(quán)限退敦，若沒有則會報錯并返回粘咖，因此搜集到的第一個必要條件為：f->_flags & _IO_NO_WRITES == 0；接下來一個重要判斷是在第754行的判斷侈百，經(jīng)過上一節(jié)的分析我們知道這個判斷是用來判斷緩沖區(qū)是否初始化的瓮下，若未初始化則會進入該判斷語句，由于在該判斷分支中最后會將FILE結(jié)構(gòu)體中的write相關(guān)指針進行重新賦值钝域，從而破壞了我們事先構(gòu)造好的write指針讽坏，所以這個判斷也不能進入，因此搜集到的第二個必要條件為f->_flags & _IO_CURRENTLY_PUTTING != 0例证。
  
  條件判斷(2)
  
  之后進入_IO_do_write函數(shù)路呜，這個函數(shù)比較簡單，只要滿足f->_IO_write_ptr - f->_IO_write_base != 0便可調(diào)用new_do_write函數(shù)；最后在new_do_write函數(shù)中拣宰，只要滿足fp->_IO_read_end == fp->_IO_write_base即可調(diào)用_IO_SYSWRITE將_IO_write_base到_IO_write_ptr之間的數(shù)據(jù)輸出党涕。
  第二種調(diào)用情況，是在第1277行直接調(diào)用new_do_write函數(shù)巡社，因為此處第二個參數(shù)膛堤，即輸出的數(shù)據(jù)段起始地址為外部傳入?yún)?shù)，而不能通過偽造FILE結(jié)構(gòu)體來進行控制晌该，因此不能實現(xiàn)任意地址讀的功能肥荔，直接PASS掉。

綜上朝群，我們只要偽造滿足這4個條件的stdout結(jié)構(gòu)體就能夠?qū)崿F(xiàn)任意地址讀燕耿，其中第1、2個條件為文件流不能具有_IO_NO_WRITES（0x8）屬性姜胖，且具有_IO_CURRENTLY_PUTTING（0x800）屬性誉帅，而且_flags位自帶一個_IO_MAGIC（0xfbad0000），因此構(gòu)造的_flags為0xfbad0800右莱。第3蚜锨、4個條件就和read、write指針息息相關(guān)了慢蜓，根據(jù)條件只要構(gòu)造_IO_read_end = _IO_write_base = （想要leak的起始地址)亚再，_IO_write_ptr = (想要leak的結(jié)束地址)，其他3個沒有提到的指針置0就可以了晨抡。
因此偽造的fake_FILE結(jié)構(gòu)體大概長這樣（一般用got表進行libc的leak）：

fake_FILE

在我們最終偽造好這個FILE結(jié)構(gòu)體后再去調(diào)用針對stdout進行輸出的函數(shù)就可以實現(xiàn)任意地址讀了氛悬，常見的函數(shù)一般有printf、fwrite耘柱、puts等如捅。

• 利用偽造stdout進行任意地址寫
  在_IO_new_file_xsputn函數(shù)中，不僅調(diào)用了_IO_SYSWRITE進行了輸出调煎，而且也有調(diào)用__mempcpy函數(shù)將要輸出的數(shù)據(jù)寫入緩沖區(qū)的操作镜遣，該操作在函數(shù)中的第1258行，如下圖：
  
  寫入緩沖區(qū)
  
  根據(jù)調(diào)用的參數(shù)汛蝙，可通過偽造FILE結(jié)構(gòu)體達到將s中數(shù)據(jù)向我們可控指針f->_IO_write_ptr中寫的操作烈涮，即不可控制內(nèi)容的任意地址寫朴肺〗呀＃可以看到執(zhí)行該語句的最主要判斷為count > 0，而count變量在上方有多次賦值操作戈稿，對于已經(jīng)控制了FILE結(jié)構(gòu)體的我們來說輕而易舉西土，但在執(zhí)行之前會與to_do變量進行比較，取較小的長度進行寫入鞍盗，其中to_do變量為調(diào)用時想要寫入的長度需了，一般為字符串的長度跳昼。如，puts("12345678")在調(diào)用該函數(shù)時肋乍，to_do的值就為8鹅颊，s變量就是指向12345678這個字符串的開頭。

綜上墓造，我們只需要構(gòu)造如下的fake_FILE就能夠?qū)崿F(xiàn)將字符串寫到指定內(nèi)存的操作堪伍。

fake_FILE

雖然看起來不能實現(xiàn)任意地址寫任意數(shù)據(jù)，但若是輸出我們輸入的值時觅闽，則可實現(xiàn)任意地址寫任意數(shù)據(jù)帝雇；就算輸出的都是固定字符串，能夠?qū)⒁恍┡袛鄻?biāo)志改為其他值蛉拙，而改變程序正常執(zhí)行流程有時還是很有用的尸闸。

• 利用偽造stdin進行任意地址寫
  stdin，即標(biāo)準(zhǔn)輸出孕锄，默認(rèn)為鍵盤吮廉，其本質(zhì)也為一個FILE結(jié)構(gòu)體，利用這種方法最終達到由我們從鍵盤輸入的數(shù)據(jù)寫到任意地址的效果硫惕。同樣茧痕，首先我們需要定位到fread函數(shù)中獲取輸入的位置，即調(diào)用_IO_SYSREAD函數(shù)的地方恼除。由前小節(jié)分析可知僅有在_IO_UNDERFLOW函數(shù)中會調(diào)用_IO_SYSREAD函數(shù)進行寫入踪旷， 程序在_IO_file_xsgetn函數(shù)中是通過第1344行調(diào)用__underflow函數(shù)來間接調(diào)用該函數(shù)，如下圖：
  
  條件判斷(1)
  
  與利用stdout進行任意地址讀有所不同的是豁辉，并不是每次執(zhí)行都會順理成章地去調(diào)用_IO_UNDERFLOW函數(shù)令野，而會有很多外部的限制條件。首先我們可以看到在調(diào)用__underflow函數(shù)之間就有了許多的限制徽级。從調(diào)用處開始往上看气破，首先最息息相關(guān)的兩個條件判斷支，第一個為第1341行的判斷要求fp->_IO_buf_base != NULL && want < fp->_IO_buf_end - fp->_IO_buf_base餐抢，其中want變量的值為傳入的參數(shù)n现使，即想要讀入的字節(jié)數(shù)；第二個條件為不滿足第1316行的判斷語句旷痕，即want > fp->_IO_read_end - fp->_IO_read_ptr碳锈。其實除了這2個判斷語句外，在第1302行的判斷也不能為真欺抗，因為進入該分支后會調(diào)用_IO_doallocbuf函數(shù)重新分配緩沖區(qū)售碳，會破壞我們事先構(gòu)造好的FILE結(jié)構(gòu)體，但由于該判斷句的條件包含于1341行的判斷句，所以不單獨算一個條件贸人。滿足這兩個條件后间景，程序正常執(zhí)行到了__underflow函數(shù)，如下圖：
  
  條件判斷(2)
  
  可以看到我們最終要調(diào)用的_IO_UNDERFLOW函數(shù)在該函數(shù)的最終結(jié)尾處艺智，因此要小心的過掉上面的各個分支倘要。通過觀察，大部分分支在正常情況下都不會進入十拣，需要注意的是一個在第296行的if語句不能滿足碗誉，因此第3個條件為fp->_IO_read_ptr >= fp->_IO_read_end，接下來進入_IO_UNDERFLOW函數(shù)內(nèi)部父晶，即_IO_new_file_underflow函數(shù)哮缺，如下圖：
  
  條件判斷(3)
  
  在_IO_new_file_underflow函數(shù)的第531行調(diào)用了_IO_SYSREAD函數(shù)的調(diào)用，其上方仍有許多if分支甲喝，看似特別多尝苇，其實只有第478行的影響比較大，即第4個條件為fp->_flags & _IO_NO_READS == 0埠胖。之后第484糠溜、487行的分支雖然都不能進入，但這些判斷條件在調(diào)用前已經(jīng)囊括了直撤，因此不做重復(fù)搜集非竿；第500行的條件分支也沒有進去的必要，之后就能夠順利地調(diào)用_IO_SYSREAD函數(shù)谋竖，實現(xiàn)向fp->_IO_buf_base地址寫入從鍵盤輸入_IO_buf_base - _IO_buf_end長度數(shù)據(jù)的功能红柱。

綜上，我們只要偽造滿足這4個條件的stdin結(jié)構(gòu)體就能夠?qū)崿F(xiàn)任意地址寫蓖乘，其中第1個條件與調(diào)用時本來要寫入的數(shù)據(jù)長度有關(guān)锤悄，我們要偽造的寫入大小應(yīng)該比其本要寫入的大小更大。比如嘉抒，在調(diào)用read(0 , buf , 0x10)函數(shù)時零聚，我們構(gòu)造的_IO_buf_end - _IO_buf_base就應(yīng)該大于0x10；第2、3個條件綜合起來可構(gòu)造_IO_read_ptr == fp->_IO_read_end來同時滿足，也不知道給個什么值许起，就默認(rèn)為0吧；第4個就是_flags屬性的問題了蚂会，不包含_IO_NO_READS。
因此偽造的fake_FILE結(jié)構(gòu)體大概長這樣：

fake_FILE

在我們最終偽造好這個FILE結(jié)構(gòu)體后再去調(diào)用針對stdin進行輸入的函數(shù)就可以實現(xiàn)任意地址寫了狈定，常見的函數(shù)一般有scanf颂龙、fread、gets纽什、fgets等措嵌。

• 修改stdin->_IO_buf_end而導(dǎo)致的堆溢出
  再次回到執(zhí)行fread函數(shù)過程中在_IO_new_file_underflow中調(diào)用_IO_SYSREAD將文件中的數(shù)據(jù)讀入緩沖區(qū)的地方，即_IO_new_file_underflow的第531行芦缰，此時調(diào)用如下：
  _IO_SYSREAD(fp, fp->_IO_buf_base, fp->_IO_buf_end - fp->_IO_buf_base)
  通過上文的分析可知企巢，_IO_buf_base指向所申請的堆的頭部，_IO_buf_end指向所申請的堆的末尾让蕾，在執(zhí)行fread過程中當(dāng)文件大小 <= 緩沖區(qū)大小時（這個大小通常是4K）浪规，會執(zhí)行到這一步，將文件中數(shù)據(jù)全部讀入緩沖區(qū)中探孝。但笋婿，正如這個調(diào)用語句所示，此處的緩沖區(qū)大小是由_IO_buf_end - _IO_buf_base所決定顿颅。
  有這樣一種場景缸濒，在申請過緩沖區(qū)后，_IO_buf_base指向緩沖區(qū)的頭部粱腻，而通過某些手段庇配，我們能夠修改_IO_buf_end為別的更大的值，在執(zhí)行相應(yīng)函數(shù)時則會造成堆溢出绍些。而這種手段捞慌，我們可以在有unsortbin attack的條件下，很輕松地將_IO_buf_end修改為main_arena上的很大的值柬批，那么我們就可以構(gòu)造這樣一個文件或輸入啸澡，一直覆蓋到main_arena之前的free_hook等敏感指針。

• 劫持vable
  對FILE結(jié)構(gòu)體的虛表的利用氮帐，早在libc-2.23版本時就有了FSOP之類的偽造vtable劫持控制流的利用方法等锻霎，但隨著版本的更新，從2.24版本開始揪漩，對調(diào)用vtable的合法性檢查也開始進行了check旋恼，這就導(dǎo)致了前版本中直接更改vtable的利用方法變得不可行。同樣奄容，在本文的2.27版本中冰更，在調(diào)用vtable之前也是有這一定的check機制。下面我們就分析vtable的check機制昂勒，以及利用方法蜀细。
  首先我們來定位vtable調(diào)用的地方，從前小節(jié)的分析中戈盈，可以找到許多調(diào)用的地方奠衔，比如_IO_new_file_xsputn函數(shù)第1266行調(diào)用的_IO_OVERFLOW函數(shù)就是vtable的入口谆刨。追隨_IO_OVERFLOW的腳步，可以在glibc/libio/libioP.h中找到如下宏定義：

#define _IO_OVERFLOW(FP, CH) JUMP1(__overflow, FP, CH)
......
#define JUMP1(FUNC, THIS, X1) (_IO_JUMPS_FUNC(THIS)->FUNC) (THIS, X1)
......
#define _IO_JUMPS_FUNC(THIS) (IO_validate_vtable (_IO_JUMPS_FILE_plus (THIS)))

通過多個宏定義归斤，我們可以發(fā)現(xiàn)痊夭，在調(diào)用vtable所代表的函數(shù)之前，首先調(diào)用了IO_validate_vtable函數(shù)脏里，該函數(shù)在glibc/libio/libioP.h中定義如下：

IO_validate_vtable

_IO_vtable_check

_IO_str_jumps

_IO_str_finish

FSOP方法在之前的文章中有過介紹，在此只做簡單描述随常。該方法的精髓為當(dāng)程序從main函數(shù)返回或調(diào)用exit函數(shù)或libc進行abort操作時潜沦，會調(diào)用_IO_flush_all_lockp函數(shù)去遍歷_IO_list_all鏈表中的每一個FILE結(jié)構(gòu)體，而當(dāng)FILE結(jié)構(gòu)體滿足(_mode <= 0) && (_IO_write_ptr > _IO_write_base)時绪氛，則會調(diào)用_IO_OVERFLOW函數(shù)唆鸡，即vtable指針+ 0x18位置的函數(shù)。

因此枣察，對應(yīng)到此處争占，想要成功調(diào)用_IO_str_finish函數(shù)，則需要在FSOP的基礎(chǔ)上將的vtable改為_IO_str_jumps - 8序目，此為調(diào)用函數(shù)前的利用條件臂痕。在進入函數(shù)后，首先要滿足判斷條件_IO_buf_base != NULL以及_flags & _IO_USER_BUF == 0猿涨，最后是利用條件_s._free_buffer == system_addr || _IO_buf_base == "/bin/sh\x00"或_s._free_buffer == one_gadget握童。其中_IO_strfile結(jié)構(gòu)體在glibc/libio/strfile.h中定義如下：

_IO_strfile結(jié)構(gòu)體

綜上，我們想要需要構(gòu)造如下的fake_FILE結(jié)構(gòu)體來利用FSOP方法來繞過新版本中對vtable的check叛赚，從而達到利用的目的澡绩。

fake_FILE