0x00 写在前面

第一次接触FILE结构体，是在BCTF2018的baby_arena中，利用了FSOP，当时感觉结构体中字段太多了，没有理清楚到底是什么关系。也是时隔非常非常非常久，咸鱼的我终于开始系统的学习一下FILE结构体。本篇基于libc-2.27源码对该版本文件流的数据结构、相关操作以及一些常见的漏洞利用方法进行分析。

0x01 数据结构

• _IO_FILE_plus
  虽然每次都是说FILE结构体，但其实FILE结构体的外层还有一个结构体，叫做_IO_FILE_plus结构体。该结构体在glibc/libio/libioP.h中定义如下:

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

中间包含了一个我们常说的FILE结构体，以及_IO_jump_t的一个虚表结构体。

• FILE/_IO_FILE
  在glibc/libio/bits/types/FILE.h中可以看到FILE结构体其实就是_IO_FILE结构体。

typedef struct _IO_FILE FILE;

_IO_FILE结构体在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字段标志了该FILE结构体的读写等属性，该字段的前2个字节固定为0xFBAD的魔术头，其具体数值在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字段为输入缓冲区的当前地址
_IO_read_end字段为输入缓冲区的结束地址
_IO_read_base字段为输入缓冲区的起始地址
_IO_write_base字段为输出缓冲区的起始地址
_IO_write_ptr字段为输出缓冲区的当前地址
_IO_write_end字段为输出缓冲区的结束地址
_IO_buf_base字段为输入输出缓冲区的起始地址
_IO_buf_end字段为输入输出缓冲区的结束地址
_chain字段为指向下一个_IO_FILE结构体的指针，在gilbc/libio/libioP.h中有如下声明：

extern struct _IO_FILE_plus *_IO_list_all;

该变量为一个单链表的头结点，该单链表用于管理程序中所有的FILE结构体，并通过_chain字段索引下一个FILE结构体，每个程序中该链表的最后3个节点从后往前固定为_IO_2_1_stdin、_IO_2_1_stdout、_IO_2_1_stderr，之前是用户新申请的FILE结构体，每次新申请的FILE结构体会插在该链表的表头。大概长成下面这样：

_IO_list_all

_IO_2_1_stdin_

• _IO_jump_t
  该结构体在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结构体的虚表指针均指向虚表_IO_file_jumps，在进行IO操作时，都会调用到该结构体中的函数。

0x02 相关操作

fopen

fopen为stdio库中的函数，其在glibc/include/stdio.h中宏定义如下：

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

由stdio.h宏定义可知，平时我们常用的fopen函数其实为定义在glibc/libio/iofopen.c中的_IO_new_fopen函数，该函数直接调用了__fopen_internal函数。

__fopen_internal

• __fopen_internal函数中第58-65行声明了一个locked_FILE结构体变量指针new_f，该结构体中主要包含了_IO_FILE_plus和_IO_wide_data两个结构，并为该声明的变量分配了空间。
• __fopen_internal函数中第72行调用了_IO_no_init函数对新申请的locked_FILE结构体进行了初始化，该函数在glibc/libio/genops.c中定义如下：
  
  _IO_no_init
  
  其中调用的_IO_old_init函数定义于其上方：
  
  _IO_old_init
  
  不难看出，_IO_old_init函数主要是对_IO_FILE_plus结构体中的各个元素进行初始化，而_IO_no_init主要是对_IO_wide_data 结构体中的各个元素进行初始化。通过两个结构体的初始化，初步猜测，_IO_FILE_plus结构体中元素及虚表主要用于单字节的文件流处理流程中，_IO_wide_data结构体中的元素及虚表主要用于宽字节的文件流处理流程中。
• __fopen_internal函数中第73行调用了_IO_JUMPS函数对结构体的虚表进行了初始化，_IO_JUMPS函数在glibc/libio/libioP.h中宏定义如下：

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

即将_IO_FILE_plus结构体中的虚表指针赋值为虚表_IO_file_jumps的地址。

• __fopen_internal函数中第74行调用了_IO_new_file_init_internal函数将新初始化的结构体链入_IO_list_all链表的头部，该函数在glibc/libio/fileops.c中定义如下：
  
  _IO_new_file_init_internal
  
  该函数主要实现了将初始化好的_IO_FILE_plus结构体链入_IO_list_all链表头部的功能，其中链入链表的功能主要是由_IO_link_in函数进行实现，该函数定义在glibc/libio/genops.c中。除了实现链入功能外，还对_IO_FILE_plus结构体加入了相应的属性，如CLOSED_FILEBUF_FLAGS(可关闭？)属性以及_IO_link_in函数中的_IO_LINKED已链接属性第115行，对_fileno函数赋值为-1，该字段代表该文件流在_IO_list_all链表中的序号，此处赋值为-1相当于对该字段进行一个非法数值的初始化，后面会有_IO_file_is_open函数专门对_fileno数值是否合法进行check。
• __fopen_internal函数中第78行调用了_IO_file_open函数，开始执行真正意义上的fopen操作，该函数在glibc/libio/fileops.c中定义如下：

versioned_symbol(libc, _IO_new_file_fopen, _IO_file_fopen, GLIBC_2_1);

即_IO_file_fopen函数等价于_IO_new_file_fopen函数，该函数定义于同一文件的第211行(太长了就不一次性全部贴了)。

_IO_new_file_fopen(1)

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

即通过检查FILE结构体的_fileno是否为合法序号来判断检该文件流是否为已打开状态。
第二个操作则是通过mode，即fopen函数第二个参数的第一个字符来确定该文件流的属性，并添加对应的flag。在写入flag字段前，代码中有3个比那里那个来分别存储不同的属性，这三个变量分别是omode、oflags、read_write，其中omode标志文件的读写属性，oflags标志文件的修改方式，read_write标志文件内容的读写方式。有如下对应关系：

_IO_new_file_fopen继续往后走，代码如下：

_IO_new_file_fopen(2)

在将所有附属性遍历完后，会调用_IO_file_open函数用于打开文件并返回句柄，该函数有6个参数，该函数在glibc/libio/fileops.c中定义如下：

_IO_file_open

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

以及还有在某些情况__open64_nocancel函数可以等价为__libc_open64函数的定义。在同一文件中，两个函数定义如下：

__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函数中，此时执行到了__fopen_internal函数的最后一步，如果上面调用_IO_file_fopen函数打开文件失败，则执行函数第81-83行：调用_IO_un_link函数将链入_IO_list_all的结构体摘除，并free掉为其申请的空间，之后return NULL；若打开文件成功，则会执行第79行：调用__fopen_maybe_mmap函数并返回。该函数在glibc/libio/iofopen.c中定义如下；
  
  __fopen_maybe_mmap
  
  该函数会判断_flags2字段中是否含有_IO_FLAGS2_MMAP位，即在打开文件时是否有m属性，还会检查_flags字段中是否含有_IO_NO_WRITES位，即在打开文件时是否有r属性。即在打开文件时有rm两个属性，则会执行函数的主体部分，调用_IO_JUMPS_FILE_plus函数将重置FILE结构体的vtable虚表，该函数在glibc/libio/libioP.h中定义如下：
  
  _IO_JUMPS_FILE_plus

以上，完成了对fopen函数源码的分析，该函数主要进行了3个操作：为文件流申请空间；初始化FILE结构体及虚表，包括将文件流链入_IO_list_all链表中；打开文件流，包括读取文件属性以及利用系统调用打开文件。
通过阅读源码，对文件属性有了船新的认识：

• 除了日常用到的r/w/a/b/+之外还有x/m/c/e这4个属性，而且作为主属性的r/w/a必须在fopen第二个参数的开头，即只能wb而不能bw。
• 在正常编写代码时宏观能够感到打开文件方式不一样的属性有r/w/a/+/x，而m/c/e这三个属性的采用，仅仅会在系统进行打开文件操作过程中进行一些不太影响大局的判断操作，在宏观上感觉不到。这可能也是FILE结构体中_flags和_flags2两个字段的区别。
• 在上一点中所没提到的b属性，虽然一直知道是以二进制方式打开文件，但是在_IO_new_file_fopen函数中的关于副属性的switch...case语句中，b属性并没有什么卵用。没有加入任何flag标志位，只是将last_recognized赋值为b，即最后一个识别的属性是b。就算不考虑后续代码，只看switch...case语句的结果，当b属性后面跟有其他属性，那么b属性的case中没有留下任何东西(其他属性多多少少修改了_flags/_flags2字段)。

fread

fread函数的一般用法为

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

该函数共有4个参数，buffer代表接收从文件读取数据的变量首地址，size代表每个对象的大小，count代表对象的个数，stream是代表文件流。即该函数实现了从stream中读size * count字节数据并赋给buffer所指向的地址。该函数在glibc/libio/iofread.c中有如下宏定义：

weak_alias(_IO_fread , fread)

即fread函数原形为_IO_fread函数，该函数在同一文件中定义如下：

_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行的判断语句，则会调用__underflow函数，该函数在glibc/libio/genops.c中定义如下：
  

  __underflow
  
  该函数经过一系列检查后调用了_IO_UNDERFLOW函数，该函数即虚表中的__underflow字段，对应_IO_new_file_underflow函数，该函数定义在glibc/libio/fileop.c中，进入函数后按照当前状态会直接跳过前面的检查，直接从第520行开始执行，如下图：
  
  _IO_new_file_underflow(partial)
  
  首先将read和write的6个字段都初始化为_IO_buf_base，之后调用_IO_SYSREAD函数尝试从fp中读_IO_buf_end - _IO_buf_base即4K大小的数据到从_IO_buf_base开始的空间中，该函数的原形为虚表中的__read，对应_IO_file_read函数。该函数在glibc/libio/fileops.c中定义如下：
  
  _IO_file_read
  
  该函数再往下就是调用__read()或__read_nocancel()直接进行系统调用进行读入，返回值为实际读取的大小，赋值给count。若正常读取成功，则会将_IO_read_end和offset字段增加count的大小，返回_IO_read_ptr的值。调用完该函数后，返回_IO_file_xsgetn函数，此时该文件中最多4K大小的数据已经被读入到了缓存缓冲区中，且_IO_read_base和_IO_read_end两个指针分别对应这想要读入的数据的起始位置和终止位置，相当于输入缓冲区，此时执行continue，重新开始循环，进入第1316行的判断语句，直接调用memcpy函数，将数据从输入缓冲区中拷贝如目标变量中，_IO_read_ptr字段加上相应大小，此时所有数据全部读入，want赋值为0，一路执行，最后跳出循环。

• n > 4K
  若读取数据大小大于4K，则不会进入第1341行的判断句，而是继续往下执行：
  

  _IO_file_xsgetn(3)
  
  紧接着调用了_IO_setg和_IO_setp两个函数，这两个函数在glibc/libio/libioP.h中有宏定义如下：
  
  _IO_setp/_IO_setg
  
  即实现了将FILE结构体中的read和write相关共6个指针均初始化为_IO_buf_base的功能。随后在1357行的判断中，是将之前分配的缓冲区大小作为一个block_size，因为这条分支接下来会直接调用_IO_SYSREAD函数，将数据直接从文件流中读入变量中而不经过缓冲区，所以为了(优化性能？)，每次只读取block_size大小的数据，即4K。调用完_IO_SYSREAD后want会减去4K再次进行循环，直到最后小于4K的一部分，会和上面n <= 4K经历相同的过程，并退出循环。

至此，分析完了fread函数主要流程，尤其是_IO_file_xsgetn函数的执行流程。fread函数主要进行了1个操作，调用_IO_file_xsgetn函数，当然加锁也是比较重要的。_IO_file_xsgetn函数，主要进行了3个操作：调用_IO_doallocbuf给FILE结构体分配缓冲区；当n <= block_size时，调用_IO_file_underflow将文件流中的数据读入缓冲区再调用memcpy从缓冲区拷贝至目标变量中；当n > block_size时，大部分先对齐到block_size，调用_IO_SYSREAD函数直接从文件流读入到目标变量，若还有剩余的数据再用老方从走缓冲区拷贝到目标变量中。
通过阅读源码，对FILE结构体以及其中各字段所代表的含义有了船新的认识：

• 首先是从_IO_read_ptr到_IO_buf_end这8个字段，原本认为是共申请了3个缓冲区，通过阅读源码后知道了只申请了1个缓冲区，其中_IO_buf_base和_IO_buf_end指向这个缓冲区的两端，其余6个read和write字段没事的时候都与_IO_buf_base的值相同，在进行读操作时，相当于3个read指针起作用控制缓冲区中的内容，可以推出在进行写操作时，3个read指针与_IO_buf_base的值相同，而3个write指针独起作用控制缓冲区中的内容。
• 其次_IO_save_base到_IO_save_end这3个字段，因为在该段代码中只存在几处判断，并没有实际用处，所以判断大概是为了保存某个时刻缓冲区而设置的指针。
• 最后是在调试时发现的FILE结构体有多种形态，比如我在调试时看到的FILE结构体实际上是glibc/libio/bits/libio.h中定义的_IO_FILE_complete结构体。最终究其原因，是因为有个宏判断把定义结构体的大括号给吃掉了。如下图：
  
  骚骚的宏判断

fwrite

fwrite函数的一般用法为

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

与fread函数相似，该函数共有4个参数，buffer代表存储要写入文件数据的首地址，size代表每个对象的大小，count代表对象的个数，stream代表文件流。即该函数实现了将buffer中size * count字节数据写入stream文件流的操作。该函数在glibc/libio/iofwrite.c中有如下宏定义：

weak_alias(_IO_fwrite , fwrite)

即fwrite函数原形为_IO_fwrite函数，该函数在同一文件中定义如下：

_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
  若要写入的数据小于4K，则do_write = 0，不会进入第1275行的判断语句，而是在1287行直接调用_IO_default_xsputn函数进行处理，该函数在glibc/libio/genops.c中定义如下：
  

  _IO_default_xsputn
  
  该函数主要实现了将数据从变量中拷贝到结构体缓冲区中的操作，主要有两种情况，一种是当要拷贝的数据大于20字节时，会直接调用__mempcpy进行拷贝，如果小于等于20，则用for循环逐字节进行拷贝，若缓冲区大小不够，则会调用_IO_OVERFLOW刷新缓冲区。
  值得注意的是，_IO_default_xsputn函数仅仅实现了将数据从变量中拷贝到了从_IO_write_base到_IO_write_ptr为止的缓冲区中，并没有写入文件。

• to_do >= 4K
  若要写入的数据大于4K，则do_write被赋值为4K的倍数，将在第1277行调用new_do_write函数进行写入，该函数在glibc/libio/fileops.c中定义如下：
  

  new_do_write
  
  首先会判断是否具有_IO_IS_APPENDING属性，即判断该文件是由a属性打开还是由w属性打开：若为w属性，则将_offset字段赋值为-1；若为a属性，则_offset字段不变，这正是写文件时覆盖和追加方式的体现。之后判断_IO_read_end与_IO_write_base相等，若不等则调用_IO_SYSSEEK函数。对于本次调用的流程，这两个判断语句不会有太大的影响。主要是在函数的第457行执行了_IO_SYSWRITE函数，该函数为虚表中的__write，即为_IO_new_file_write函数，该函数在glibc/libio/fileops.c中定义如下：
  
  _IO_new_file_write
  
  该函数也是通过调用__write函数或__write_nocancel函数进行系统调用，将to_do长度的数据从data中写入文件中。调用完_IO_SYSWRITE函数后，若读入成功，即count不为0，在之后会调用_IO_adjust_column函数去更新FILE结构体中的_cur_column字段，该字段代表（文件的行数+1)，该函数在glibc/libio/genops.c中定义如下：
  
  _IO_adjust_column
  
  该函数通过判断上面通过_IO_SYSWRITE函数写入的数据中含有多少\n字符来确定文件中增加了多少行。调用完_IO_adjust_column后返回到new_do_write函数，之后会调用_IO_setg函数以及各种赋值操作将文件流中read、write相关6个字段都赋值为_IO_buf_base，类似于初始化的操作。综上，new_do_write函数完成了将对齐block_size大小的数据不通过缓冲区，直接从变量写入文件流的操作。从new_do_write函数返回后，之前未对齐的剩余的数据，则会在下方调用_IO_default_xsputn函数拷贝到缓冲区中。

至此，分析完了fwrite函数主要流程，尤其是_IO_new_file_xsputn函数的执行流程。fwrite函数与fread相互对仗，fread是将文件中数据直接读入变量，或先从文件读入FILE结构体缓冲区，再利用read相关指针进行间接读入变量；fwrite是将数据直接从文件中写入变量或写入FILE结构体中的缓冲区。_IO_new_file_xsputn作为实现fwrite的重要函数，主要进行了****个操作：调用_IO_new_file_overflow函数为FILE结构体申请缓冲区；若n < block_size时，直接调用__mempcpy函数拷贝到缓冲区中；若n >= block_size时，会将对齐到block_size的部分用系统调用直接读入文件，剩余部分按与n < block_size相同的方法拷贝到缓冲区中。
通过阅读源码，对fwrite函数有了船新认识：

• 本以为fwrite只是把fread的读操作变成写操作，其他都是相同的。然而fread执行完后不论多少数据都读入了变量中，而fwrite执行完后未对齐block_size大小的数据仍在缓冲区中，推测在执行fclose函数或在程序退出时才会真正的写入文件中。
• _IO_new_file_overflow函数并不仅仅有上文中描述的调用_IO_doallocbuf申请缓冲区的作用，其主要担负着刷新缓冲区的作用：第一种调用情况为上文中所提到的，当_IO_buf_base字段为空，即还未初始化缓冲区时，则会调用_IO_doallocbuf函数进行申请缓冲区；若缓冲区已经初始化，且_IO_write_end == _IO_write_ptr，即缓冲区已满时，则会把这些待写入内容写入文件，之后会将_IO_write_ptr赋值为_IO_buf_base，相当于清空缓冲区的操作。

fclose

与fopen函数相同，在glibc/include/stdio.h中有如下宏定义：

#define fclose(fp) _IO_new_fclose(fp)

即fclose函数的原形为_IO_new_fclose函数，该函数在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函数流程的分析，总的来说代码比较短暂，也都是对前面已经执行代码的一个逆过程，因此并没有太多需要注意的地方，主要还是印证了前面在fwrite结尾的一个预测，会在关闭文件流时去调用了_IO_do_flush函数将缓冲区内的数据写入文件。

0x03 利用方法

• 利用伪造stdout进行任意地址读
  stdout，即标准输出，默认为当前终端，其本质也为一个FILE结构体，利用这种方法最终达到将任意地址数据输出到终端供我们进行读的效果。因此首先定位到fwrite函数中输出的位置，即调用_IO_SYSWRITE的地方。由前小节的分析可知，只有在new_do_write函数中有对_IO_SYSWRITE的调用，而调用new_do_write理论上有两个地方，一个是在_IO_new_file_xsputn函数中的第1266行调用_IO_OVERFLOW函数中会有调用，以及在第1277行直接进行调用。
  
  调用_new_do_write
  
  第一种调用情况，在利用_IO_OVERFLOW函数通过调用_IO_do_write函数，实现间接调用new_do_write函数将_IO_write_base到_IO_write_ptr之间的数据进行写入。
  首先我们需要获得执行到_IO_OVERFLOW函数的条件，主要还是第1262行的to_do + must_flush > 0，因为正常函数调用时传进来的to_do均大于0，因此必然会进入该语句，所以前置条件几乎算是没有；
  接下来进入_IO_OVERFLOW函数内部进行分析调用new_do_write函数的条件。
  
  条件判断(1)
  
  可以看到在我们最终调用_IO_do_write函数之前会有2个比较关键的判断：第747行判断是否有写权限，若没有则会报错并返回，因此搜集到的第一个必要条件为：f->_flags & _IO_NO_WRITES == 0；接下来一个重要判断是在第754行的判断，经过上一节的分析我们知道这个判断是用来判断缓冲区是否初始化的，若未初始化则会进入该判断语句，由于在该判断分支中最后会将FILE结构体中的write相关指针进行重新赋值，从而破坏了我们事先构造好的write指针，所以这个判断也不能进入，因此搜集到的第二个必要条件为f->_flags & _IO_CURRENTLY_PUTTING != 0。
  
  条件判断(2)
  
  之后进入_IO_do_write函数，这个函数比较简单，只要满足f->_IO_write_ptr - f->_IO_write_base != 0便可调用new_do_write函数；最后在new_do_write函数中，只要满足fp->_IO_read_end == fp->_IO_write_base即可调用_IO_SYSWRITE将_IO_write_base到_IO_write_ptr之间的数据输出。
  第二种调用情况，是在第1277行直接调用new_do_write函数，因为此处第二个参数，即输出的数据段起始地址为外部传入参数，而不能通过伪造FILE结构体来进行控制，因此不能实现任意地址读的功能，直接PASS掉。

综上，我们只要伪造满足这4个条件的stdout结构体就能够实现任意地址读，其中第1、2个条件为文件流不能具有_IO_NO_WRITES（0x8）属性，且具有_IO_CURRENTLY_PUTTING（0x800）属性，而且_flags位自带一个_IO_MAGIC（0xfbad0000），因此构造的_flags为0xfbad0800。第3、4个条件就和read、write指针息息相关了，根据条件只要构造_IO_read_end = _IO_write_base = （想要leak的起始地址)，_IO_write_ptr = (想要leak的结束地址)，其他3个没有提到的指针置0就可以了。
因此伪造的fake_FILE结构体大概长这样（一般用got表进行libc的leak）：

fake_FILE

在我们最终伪造好这个FILE结构体后再去调用针对stdout进行输出的函数就可以实现任意地址读了，常见的函数一般有printf、fwrite、puts等。

• 利用伪造stdout进行任意地址写
  在_IO_new_file_xsputn函数中，不仅调用了_IO_SYSWRITE进行了输出，而且也有调用__mempcpy函数将要输出的数据写入缓冲区的操作，该操作在函数中的第1258行，如下图：
  
  写入缓冲区
  
  根据调用的参数，可通过伪造FILE结构体达到将s中数据向我们可控指针f->_IO_write_ptr中写的操作，即不可控制内容的任意地址写。可以看到执行该语句的最主要判断为count > 0，而count变量在上方有多次赋值操作，对于已经控制了FILE结构体的我们来说轻而易举，但在执行之前会与to_do变量进行比较，取较小的长度进行写入，其中to_do变量为调用时想要写入的长度，一般为字符串的长度。如，puts("12345678")在调用该函数时，to_do的值就为8，s变量就是指向12345678这个字符串的开头。

综上，我们只需要构造如下的fake_FILE就能够实现将字符串写到指定内存的操作。

fake_FILE

虽然看起来不能实现任意地址写任意数据，但若是输出我们输入的值时，则可实现任意地址写任意数据；就算输出的都是固定字符串，能够将一些判断标志改为其他值，而改变程序正常执行流程有时还是很有用的。

• 利用伪造stdin进行任意地址写
  stdin，即标准输出，默认为键盘，其本质也为一个FILE结构体，利用这种方法最终达到由我们从键盘输入的数据写到任意地址的效果。同样，首先我们需要定位到fread函数中获取输入的位置，即调用_IO_SYSREAD函数的地方。由前小节分析可知仅有在_IO_UNDERFLOW函数中会调用_IO_SYSREAD函数进行写入， 程序在_IO_file_xsgetn函数中是通过第1344行调用__underflow函数来间接调用该函数，如下图：
  
  条件判断(1)
  
  与利用stdout进行任意地址读有所不同的是，并不是每次执行都会顺理成章地去调用_IO_UNDERFLOW函数，而会有很多外部的限制条件。首先我们可以看到在调用__underflow函数之间就有了许多的限制。从调用处开始往上看，首先最息息相关的两个条件判断支，第一个为第1341行的判断要求fp->_IO_buf_base != NULL && want < fp->_IO_buf_end - fp->_IO_buf_base，其中want变量的值为传入的参数n，即想要读入的字节数；第二个条件为不满足第1316行的判断语句，即want > fp->_IO_read_end - fp->_IO_read_ptr。其实除了这2个判断语句外，在第1302行的判断也不能为真，因为进入该分支后会调用_IO_doallocbuf函数重新分配缓冲区，会破坏我们事先构造好的FILE结构体，但由于该判断句的条件包含于1341行的判断句，所以不单独算一个条件。满足这两个条件后，程序正常执行到了__underflow函数，如下图：
  
  条件判断(2)
  
  可以看到我们最终要调用的_IO_UNDERFLOW函数在该函数的最终结尾处，因此要小心的过掉上面的各个分支。通过观察，大部分分支在正常情况下都不会进入，需要注意的是一个在第296行的if语句不能满足，因此第3个条件为fp->_IO_read_ptr >= fp->_IO_read_end，接下来进入_IO_UNDERFLOW函数内部，即_IO_new_file_underflow函数，如下图：
  
  条件判断(3)
  
  在_IO_new_file_underflow函数的第531行调用了_IO_SYSREAD函数的调用，其上方仍有许多if分支，看似特别多，其实只有第478行的影响比较大，即第4个条件为fp->_flags & _IO_NO_READS == 0。之后第484、487行的分支虽然都不能进入，但这些判断条件在调用前已经囊括了，因此不做重复搜集；第500行的条件分支也没有进去的必要，之后就能够顺利地调用_IO_SYSREAD函数，实现向fp->_IO_buf_base地址写入从键盘输入_IO_buf_base - _IO_buf_end长度数据的功能。

综上，我们只要伪造满足这4个条件的stdin结构体就能够实现任意地址写，其中第1个条件与调用时本来要写入的数据长度有关，我们要伪造的写入大小应该比其本要写入的大小更大。比如，在调用read(0 , buf , 0x10)函数时，我们构造的_IO_buf_end - _IO_buf_base就应该大于0x10；第2、3个条件综合起来可构造_IO_read_ptr == fp->_IO_read_end来同时满足，也不知道给个什么值，就默认为0吧；第4个就是_flags属性的问题了，不包含_IO_NO_READS。
因此伪造的fake_FILE结构体大概长这样：

fake_FILE

在我们最终伪造好这个FILE结构体后再去调用针对stdin进行输入的函数就可以实现任意地址写了，常见的函数一般有scanf、fread、gets、fgets等。

• 修改stdin->_IO_buf_end而导致的堆溢出
  再次回到执行fread函数过程中在_IO_new_file_underflow中调用_IO_SYSREAD将文件中的数据读入缓冲区的地方，即_IO_new_file_underflow的第531行，此时调用如下：
  _IO_SYSREAD(fp, fp->_IO_buf_base, fp->_IO_buf_end - fp->_IO_buf_base)
  通过上文的分析可知，_IO_buf_base指向所申请的堆的头部，_IO_buf_end指向所申请的堆的末尾，在执行fread过程中当文件大小 <= 缓冲区大小时（这个大小通常是4K），会执行到这一步，将文件中数据全部读入缓冲区中。但，正如这个调用语句所示，此处的缓冲区大小是由_IO_buf_end - _IO_buf_base所决定。
  有这样一种场景，在申请过缓冲区后，_IO_buf_base指向缓冲区的头部，而通过某些手段，我们能够修改_IO_buf_end为别的更大的值，在执行相应函数时则会造成堆溢出。而这种手段，我们可以在有unsortbin attack的条件下，很轻松地将_IO_buf_end修改为main_arena上的很大的值，那么我们就可以构造这样一个文件或输入，一直覆盖到main_arena之前的free_hook等敏感指针。

• 劫持vable
  对FILE结构体的虚表的利用，早在libc-2.23版本时就有了FSOP之类的伪造vtable劫持控制流的利用方法等，但随着版本的更新，从2.24版本开始，对调用vtable的合法性检查也开始进行了check，这就导致了前版本中直接更改vtable的利用方法变得不可行。同样，在本文的2.27版本中，在调用vtable之前也是有这一定的check机制。下面我们就分析vtable的check机制，以及利用方法。
  首先我们来定位vtable调用的地方，从前小节的分析中，可以找到许多调用的地方，比如_IO_new_file_xsputn函数第1266行调用的_IO_OVERFLOW函数就是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)))

通过多个宏定义，我们可以发现，在调用vtable所代表的函数之前，首先调用了IO_validate_vtable函数，该函数在glibc/libio/libioP.h中定义如下：

IO_validate_vtable

_IO_vtable_check

_IO_str_jumps

_IO_str_finish

FSOP方法在之前的文章中有过介绍，在此只做简单描述。该方法的精髓为当程序从main函数返回或调用exit函数或libc进行abort操作时，会调用_IO_flush_all_lockp函数去遍历_IO_list_all链表中的每一个FILE结构体，而当FILE结构体满足(_mode <= 0) && (_IO_write_ptr > _IO_write_base)时，则会调用_IO_OVERFLOW函数，即vtable指针+ 0x18位置的函数。

因此，对应到此处，想要成功调用_IO_str_finish函数，则需要在FSOP的基础上将的vtable改为_IO_str_jumps - 8，此为调用函数前的利用条件。在进入函数后，首先要满足判断条件_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结构体在glibc/libio/strfile.h中定义如下：

_IO_strfile结构体

综上，我们想要需要构造如下的fake_FILE结构体来利用FSOP方法来绕过新版本中对vtable的check，从而达到利用的目的。

fake_FILE