house of apple系列利用方法文章：

之前提出了一种新的IO利用方法 house of apple，并已经发布了house of apple1和house of apple2，其中house of apple1中的利用链能任意地址写堆地址，house of apple2中的利用链能通过控制FILE结构体的_wide_data成员去直接控制程序执行流。本篇是house of apple系列的第三篇，继续给出基于FILE->_wide_data的有关利用技巧（利用链仍然与FILE->_wide_data操作有一点相关）。

前两篇文章中的利用链主要关注_wide_data成员，而本篇文章并不会特别关注_wide_data，而是关注FILE结构体的另外一个成员_codecvt的利用。

本篇的house of apple3同样会给出几条新的IO利用链，在劫持FILE->_codecvt的基础上，直接控制程序执行流。

关于前置知识点击 house of apple1进行查看。

文章中的fp为一个FILE类型的指针，以下分析均基于amd64程序。

使用house of apple3的条件为：

注意：
上面提到，本篇文章并不会特别关注_wide_data成员，这是因为_wide_data设置不当的话会影响某些利用链的分支走向。但是，如果采用默认的_wide_data成员（默认会指向_IO_wide_data_2，除了_wide_vtable外其他成员均默认为0），也并不影响house of apple3的利用。

因此，如果能伪造整个FILE结构体，则需要设置合适的_wide_data；如果只能伪部分FILE的成员的话，保持fp->_wide_data为默认地址即可。

FILE结构体中有一个成员struct _IO_codecvt *_codecvt;，偏移为0x98。该结构体参与宽字符的转换工作，结构体被定义为：

可以看到，__cd_in和__cd_out是同一种类型的数据。往下拆，结构体_IO_iconv_t被定义为：

继续拆，来看struct __gconv_step：

然后来看struct __gconv_step_data结构体：

以上两个结构体均会被用于字符转换，而在利用的过程中，需要精准控制结构体中的某些成员，避免引发内存访问错误。

house of apple3的利用主要关注以下三个函数：__libio_codecvt_out、__libio_codecvt_in和__libio_codecvt_length。三个函数的利用点都差不多，以__libio_codecvt_in为例，源码分析如下：

其中，__gconv_fct和DL_CALL_FCT被定义为：

而在_IO_wfile_underflow函数中调用了__libio_codecvt_in，代码片段如下：

而_IO_wfile_underflow又是_IO_wfile_jumps这个_IO_jump_t类型变量的成员函数。

分析到这里，利用原理就呼之欲出了：劫持或者伪造FILE结构体的fp->vtable为_IO_wfile_jumps，fp->_codecvt为可控堆地址，当程序执行IO操作时，控制程序执行流走到_IO_wfile_underflow，设置好fp->codecvt->__cd_in结构体，使得最终调用到__libio_codecvt_in中的DL_CALL_FCT宏，伪造函数指针，进而控制程序执行流。

注意，在伪造过程中，可以设置gs->__shlib_handle == NULL，从而绕过__pointer_guard的指针调用保护。

基于该利用思路，编写demo验证：

输出如下：

目前在glibc源码中搜索到的__libio_codecvt_in/__libio_codecvt_out/__libio_codecvt_length的调用链比较多，这里给出我总结的几条比较好利用的链。

对fp的设置如下：

函数的调用链如下：

此链的详细分析见上述的利用原理部分。

对fp的设置如下：

函数的调用链如下：

详细分析如下：
看_IO_wfile_underflow_mmap函数：

需要设置fp->_flags & _IO_NO_READS == 0，设置fp->_wide_data->_IO_read_ptr >= fp->_wide_data->_IO_read_end，设置fp->_IO_read_ptr < fp->_IO_read_end不进入调用，设置fp->_wide_data->_IO_buf_base != NULL不进入调用。

_IO_wdo_write的调用点很多，这里我选择一个相对简单的链：

对fp的设置如下：

函数的调用链如下：

详细分析如下：
首先看_IO_new_file_sync函数：

只需要满足fp->_IO_write_ptr > fp->_IO_write_base。

然后看_IO_do_flush宏：

根据fp->_mode的值选择调用_IO_do_write或者_IO_wdo_write。这里我们要调用后者，必须使fp->_mode > 0。此时的第二个参数为fp->_wide_data->_IO_write_base，第三个参数为fp->_wide_data->_IO_write_ptr - fp->_wide_data->_IO_write_base。

接着看_IO_wdo_write：

首先to_do必须要大于0，即满足fp->_wide_data->_IO_write_ptr > fp->_wide_data->_IO_write_base，然后这个判断需要为假fp->_IO_write_end == fp->_IO_write_ptr && fp->_IO_write_end != fp->_IO_write_base。

这个链基本需要控制fp->_wide_data，相比上两条链的约束条件要更多一点。

对fp的设置如下：

函数的调用链如下：

详细分析如下：
直接看_IO_wfile_sync函数：

需要设置fp->_wide_data->_IO_write_ptr <= fp->_wide_data->_IO_write_base和fp->_wide_data->_IO_read_ptr - fp->_wide_data->_IO_read_end != 0。

然后看下__libio_codecvt_encoding函数：

直接设置fp->codecvt->__cd_in.step->__stateful != 0即可返回-1。

依旧以 house of apple1 中的pwn_oneday为例。

程序的详细分析仍然不在此赘述。这里展示使用_IO_wfile_underflow这条链做rop，然后使用orw读取flag。

在largebin attack攻击_IO_list_all之后，伪造_IO_FILE结构：

然后借助几个gadgets中转一下：

所以最后的exp为：

调试如下：
通过exit执行到_IO_wfile_underflow，然后执行到__libio_codecvt_in：

执行到布置好的gadget：

成功栈迁移：

输出flag：

house of apple1和house of apple2主要关注对_IO_FILE->_wide_data成员的攻击，并可以在劫持该成员之后改写地址内容或者控制程序执行流。而本文提出的house of apple3利用链则攻击_IO_FILE另一个关注甚少的成员_codecvt。

可以看到，fp->_codecvt->__cd_in.step中也存储着函数指针，并且在劫持_codecvt的时候可以使得函数指针调用绕过__pointer_guard的保护，因此，可以利用该漏洞进行FSOP。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！