2020-08-22 14:01:55 hawk
因为参加的2020年全国大学生信息安全竞赛创新实践赛时，因为自己十分的菜，pwn题仅仅痛苦的做出了几道。之后学校大佬分享了一下他们的wp，仔细查看部分题目的wp，解法涉及到了之前的盲区——IO_FILE（比如其中的一道题，我傻乎乎的将strdup的got表转换为printf的plt地址，然后再leak对应的调用strdup的栈的基址，最后使用格式化字符串漏洞leak程序的libc基址并修改strdup为system，太笨了。。；而当后面出现了FULL RELRO和PIE保护机制时，这个方法就失效了，我也就不会了。。。），因此这里特点学习一下IO_FILE相关的知识，填补一下知识短板。
众所周知，Linux将一切都当作文件进行操作，因此实际上，对于程序的IO来说，也是如此。而顾名思义，IO_FILE就是和描述IO的文件结构体，我们首先查看一下相关的源代码（我的是glibc2.23，不同版本内容可能会有一定差别），其中IO_FILE相关的源代码位于glibc源代码的libio/libioP.h文件中，如下所示
/* We always allocate an extra word following an _IO_FILE. This contains a pointer to the function jump table used. This is for compatibility with C++ streambuf; the word can be used to smash to a pointer to a virtual function table. */ struct _IO_FILE_plus { _IO_FILE file; const struct _IO_jump_t *vtable; };
实际上我们最终描述文件流文件的数据结构是_IO_FILE_plus，其中有_IO_FILE结构体和常量_IO_jump_t（内容不可被修改），而根据成员的名称，我们大概可以推测出不同成员的作用——file成员应该包含的是该文件的一些关键数据；而vtable，也就是virtual table，虚表，即各种操作函数的指针。
下面我们再分别查看一个各自成员的组成，首先是_IO_FILE，其源代码位于libio/libio.h文件中，如下所示
struct _IO_FILE { int _flags; /* High-order word is _IO_MAGIC; rest is flags. */ #define _IO_file_flags _flags /* The following pointers correspond to the C++ streambuf protocol. */ /* Note: Tk uses the _IO_read_ptr and _IO_read_end fields directly. */ char* _IO_read_ptr; /* Current read pointer */ char* _IO_read_end; /* End of get area. */ char* _IO_read_base; /* Start of putback+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_marker *_markers; struct _IO_FILE *_chain; int _fileno; #if 0 int _blksize; #else int _flags2; #endif _IO_off_t _old_offset; /* This used to be _offset but it‘s too small. */ #define __HAVE_COLUMN /* temporary */ /* 1+column number of pbase(); 0 is unknown. */ unsigned short _cur_column; signed char _vtable_offset; char _shortbuf[1]; /* char* _save_gptr; char* _save_egptr; */ _IO_lock_t *_lock; #ifdef _IO_USE_OLD_IO_FILE }; struct _IO_FILE_complete { struct _IO_FILE _file; #endif #if defined _G_IO_IO_FILE_VERSION && _G_IO_IO_FILE_VERSION == 0x20001 _IO_off64_t _offset; # if defined _LIBC || defined _GLIBCPP_USE_WCHAR_T /* Wide character stream stuff. */ struct _IO_codecvt *_codecvt; struct _IO_wide_data *_wide_data; struct _IO_FILE *_freeres_list; void *_freeres_buf; # else void *__pad1; void *__pad2; void *__pad3; void *__pad4; # endif size_t __pad5; int _mode; /* Make sure we don‘t get into trouble again. */ char _unused2[15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t)]; #endif };
该数据结构大概如此，其他大小通过输出sizeof可以判断（64/0xd8, 32/0x94)。我们根据源代码中的注释，就很容易注意到中间的那些指针应该就和输入、输出数据有相当大的关系了。这些我们会在后面在进行分析。
下面我们再介绍一下_IO_FILE_plus的另一个重要的成员结构，即_IO_jump_t结构，其源代码位于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 };
我们简单列出来对应的数据的索引，方便之后进行查询，如下所示
0,size_t, __dummy 1,size_t, __dummy2 2,_IO_finish_t, __finish 3,_IO_overflow_t, __overflow 4,_IO_underflow_t, __underflow 5,_IO_underflow_t, __uflow 6,_IO_pbackfail_t, __pbackfail 7,_IO_xsputn_t, __xsputn 8,_IO_xsgetn_t, __xsgetn 9,_IO_seekoff_t, __seekoff 10,_IO_seekpos_t, __seekpos 11,_IO_setbuf_t, __setbuf 12,_IO_sync_t, __sync 13,_IO_doallocate_t, __doallocate 14,_IO_read_t, __read 15,_IO_write_t, __write 16,_IO_seek_t, __seek 17,_IO_close_t, __close 18,_IO_stat_t, __stat 19,_IO_showmanyc_t, __showmanyc 20,_IO_imbue_t, __imbue
而我们在程序中经常会听到如下一些关键字stdin、stdout等，实际上其也就是上面提到的结构，如下所示
extern struct _IO_FILE_plus _IO_2_1_stdin_; extern struct _IO_FILE_plus _IO_2_1_stdout_; extern struct _IO_FILE_plus _IO_2_1_stderr_;
可以看到，实际上我们所说的stdin、stdout以及stderr等，都是IO_FILE数据结构进行组织的。这样子，我们就基本完成了IO_FILE相关知识的总体概括。而实际上单纯对于IO_FILE结构来说，很难展开去讲——因为涉及的方面过多，但是我们在ctf比赛或者利用的时候，并不需要那么多，因此下面我将结合功能进行讲解。
这里我们首先结合puts函数（往往可以用来leak地址），puts函数是由_IO_puts实现的（网络资料），而_IO_puts的功能主要会调用_IO_sputn，而_IO_sputn是_IO_new_file_xsputn的包装。当然这中间的分析极其复杂，我尝试从头到尾分析一遍，最后放弃了，因为过于庞大。但就我有限的尝试来看，实际上前者都是对后者的一些包装，也就是通过各种情况的判断，从而提高对于后者的调用效率，因此我们只需要直接对于最后的_IO_new_file_overflow函数进行分析即可。_IO_new_file_xsputn位于libio/fileops.c文件中，因为代码过长，我这里放置一个经过优化的源代码，如下所示
_IO_size_t _IO_new_file_xsputn (_IO_FILE *f, const void *data, _IO_size_t n) { const char *s = (const char *) data; _IO_size_t to_do = n; int must_flush = 0; _IO_size_t count = 0; if (n <= 0) return 0; /* This is an optimized implementation. If the amount to be written straddles a block boundary (or the filebuf is unbuffered), use sys_write directly. */ /* First figure out how much space is available in the buffer. */ if ((f->_flags & _IO_LINE_BUF) && (f->_flags & _IO_CURRENTLY_PUTTING)) ... } else if (f->_IO_write_end > f->_IO_write_ptr) count = f->_IO_write_end - f->_IO_write_ptr; /* Space available. */
/* Then fill the buffer. */ if (count > 0) { if (count > to_do) count = to_do; #ifdef _LIBC f->_IO_write_ptr = __mempcpy (f->_IO_write_ptr, s, count); #else memcpy (f->_IO_write_ptr, s, count); f->_IO_write_ptr += count; #endif s += count; to_do -= count; }
if (to_do + must_flush > 0) { _IO_size_t block_size, do_write; /* Next flush the (full) buffer. */ if (_IO_OVERFLOW (f, EOF) == EOF) /* If nothing else has to be written we must not signal the caller that everything has been written. */ return to_do == 0 ? EOF : n - to_do; /* Try to maintain alignment: write a whole number of blocks. */ block_size = f->_IO_buf_end - f->_IO_buf_base; do_write = to_do - (block_size >= 128 ? to_do % block_size : 0); if (do_write) { count = new_do_write (f, s, do_write); to_do -= count; if (count < do_write) return n - to_do; } /* Now write out the remainder. Normally, this will fit in the buffer, but it‘s somewhat messier for line-buffered files, so we let _IO_default_xsputn handle the general case. */ if (to_do) to_do -= _IO_default_xsputn (f, s+do_write, to_do); } return n - to_do; }
实际上我们可以根据源代码中的注释，大体了解程序的流程——首先根据情况获取可用空间大小，然后将字符串复制到_IO_write_ptr所指向的地址处，最后使用_IO_OVERFLOW、new_do_write等进行刷新即可。而实际上_IO_OVERFLOW是对于_IO_new_file_overflow函数的包装，最后仍然引用到了new_do_write，这里我放置一下其他博主https://n0va-scy.github.io/2019/09/21/IO_FILE/优化过的代码，如下所示
int _IO_new_file_overflow (_IO_FILE *f, int ch) { if (f->_flags & _IO_NO_WRITES) /* SET ERROR */ { ... } /* If currently reading or no buffer allocated. */ if ((f->_flags & _IO_CURRENTLY_PUTTING) == 0 || f->_IO_write_base == NULL){ ... } if (ch == EOF) return _IO_do_write (f, f->_IO_write_base, f->_IO_write_ptr - f->_IO_write_base); //进入目标 if (f->_IO_write_ptr == f->_IO_buf_end ) /* Buffer is really full */ if (_IO_do_flush (f) == EOF) return EOF; *f->_IO_write_ptr++ = ch; if ((f->_flags & _IO_UNBUFFERED) || ((f->_flags & _IO_LINE_BUF) && ch == ‘\n‘)) if (_IO_do_write (f, f->_IO_write_base, f->_IO_write_ptr - f->_IO_write_base) == EOF) return EOF; return (unsigned char) ch; }
可以看出来，其会有两个判断，判断成功执行的代码都是设置错误并退出，我们在执行时需要绕过，其中对应的标志位宏定义位于libio/libio.h中，可以具体查看。可以看到，最后都可以归纳为对于_IO_do_write的调用，而_IO_do_write实际上又是new_do_write的包装，同样位于libio/fileops.c文件中，同样借鉴一下上面博主整理的代码，方便阅读，如下所示
static _IO_size_t new_do_write (_IO_FILE *fp, const char *data, _IO_size_t to_do) { ... _IO_size_t count; if (fp->_flags & _IO_IS_APPENDING) fp->_offset = _IO_pos_BAD; else if (fp->_IO_read_end != fp->_IO_write_base) { _IO_off64_t new_pos = _IO_SYSSEEK (fp, fp->_IO_write_base - fp->_IO_read_end, 1); if (new_pos == _IO_pos_BAD) return 0; fp->_offset = new_pos; } // 调用函数输出输出缓冲区 count = _IO_SYSWRITE (fp, data, to_do); //最终输出 ... return count; }
同样类似于_IO_new_file_overflow，而我们想要的及时调用的_IO_SYSWRITE，中间的变化到会导致一些不可控的因素，因此我们需要让两个判断都不成立即可。如果我们要让第二个不成立，根据网络资料，程序可能会崩溃，因此我们选择进入第一个判断，也就是让fp->offset & _IO_IS_APPENDING !=0即可。最后总结即可知，实际上打印的数据地址是fp->_IO_write_base，并且f->_flags需要满足如下条件
f->_flags必须包含魔数(结构体注释)
f->_flags & _IO_NO_WRITES = 0 f->_flags & _IO_CURRENTLY_PUTTING != 0 f->_flags & _IO_IS_APPENDING != 0
其各个宏常量定义在libio/libio.h文件中，最后我们可以得出f->_flags字段的值
#define _IO_MAGIC 0xFBAD0000 /* Magic number * #define _IO_NO_WRITES 8 /* Writing not allowd */ #define _IO_CURRENTLY_PUTTING 0x800 #define _IO_IS_APPENDING 0x1000 f->_flags = (~_IO_NO_WRITES) | (_IO_CURRENTLY_PUTTING) | (_IO_IS_APPENDIGN) =0xfbad0000 | 0x800 | 0x1000 & (0xfffffff7) = 0xfbad1800
因此，如果我们修改了stdout的flags和_IO_write_base成员，并且将_IO_write_base减小，则根据上面源代码易知，我们将输出_IO_write_base地址，长度为_IO_write_ptr-_IO_write_base个字节的信息，从而会输出多一些的相关信息，即而泄露glibc地址。
原文：https://www.cnblogs.com/hawkJW/p/13546416.html