house of apple3

前言

之前提出了一种新的IO利用方法 house of apple，并已经发布了和，其中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的基础上，直接控制程序执行流。

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

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

利用条件

使用house of apple3的条件为：

• 已知heap地址和glibc地址
• 能控制程序执行IO操作，包括但不限于：从main函数返回、调用exit函数、通过__malloc_assert触发
• 能控制_IO_FILE的vtable和_codecvt，一般使用largebin attack去控制

注意：
上面提到，本篇文章并不会特别关注_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的调用链比较多，这里给出我总结的几条比较好利用的链。

利用_IO_wfile_underflow函数控制程序执行流

对fp的设置如下：

• _flags设置为~(4 | 0x10)
• vtable设置为_IO_wfile_jumps地址（加减偏移），使其能成功调用_IO_wfile_underflow即可
• fp->_IO_read_ptr < fp->_IO_read_end，即满足*(fp + 8) < *(fp + 0x10)
• _wide_data保持默认，或者设置为堆地址，假设其地址为A，即满足*(fp + 0xa0) = A
• _wide_data->_IO_read_ptr >= _wide_data->_IO_read_end，即满足*A >= *(A + 8)
• _codecvt设置为可控堆地址B，即满足*(fp + 0x98) = B
• codecvt->__cd_in.step设置为可控堆地址C，即满足*B = C
• codecvt->__cd_in.step->__shlib_handle设置为0，即满足*C = 0
• codecvt->__cd_in.step->__fct设置为地址D,地址D用于控制rip，即满足*(C + 0x28) = D。当调用到D的时候，此时的rdi为C。如果_wide_data也可控的话，rsi也能控制。

函数的调用链如下：

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

利用_IO_wfile_underflow_mmap函数控制程序执行流

对fp的设置如下：

• _flags设置为~4
• vtable设置为_IO_wfile_jumps_mmap地址（加减偏移），使其能成功调用_IO_wfile_underflow_mmap即可
• _IO_read_ptr < _IO_read_end，即满足*(fp + 8) < *(fp + 0x10)
• _wide_data保持默认，或者设置为堆地址，假设其地址为A，即满足*(fp + 0xa0) = A
• _wide_data->_IO_read_ptr >= _wide_data->_IO_read_end，即满足*A >= *(A + 8)
• _wide_data->_IO_buf_base设置为非0，即满足*(A + 0x30) != 0
• _codecvt设置为可控堆地址B，即满足*(fp + 0x98) = B
• codecvt->__cd_in.step设置为可控堆地址C，即满足*B = C
• codecvt->__cd_in.step->__shlib_handle设置为0，即满足*C = 0
• codecvt->__cd_in.step->__fct设置为地址D,地址D用于控制rip，即满足*(C + 0x28) = D。当调用到D的时候，此时的rdi为C。如果_wide_data也可控的话，rsi也能控制。

函数的调用链如下：

详细分析如下：
看_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函数控制程序执行流

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

对fp的设置如下：

• vtable设置为_IO_file_jumps/地址（加减偏移），使其能成功调用_IO_new_file_sync即可
• _IO_write_ptr > _IO_write_base，即满足*(fp + 0x28) > *(fp + 0x20)
• _mode > 0，即满足(fp + 0xc0) > 0
• _IO_write_end != _IO_write_ptr或者_IO_write_end == _IO_write_base，即满足*(fp + 0x30) != *(fp + 0x28)或者*(fp + 0x30) == *(fp + 0x20)
• _wide_data设置为堆地址，假设地址为A，即满足*(fp + 0xa0) = A
• _wide_data->_IO_write_ptr >= _wide_data->_IO_write_base，即满足*(A + 0x20) >= *(A + 0x18)
• _codecvt设置为可控堆地址B，即满足*(fp + 0x98) = B
• codecvt->__cd_out.step设置为可控堆地址C，即满足*(B + 0x38) = C
• codecvt->__cd_out.step->__shlib_handle设置为0，即满足*C = 0
• codecvt->__cd_out.step->__fct设置为地址D,地址D用于控制rip，即满足*(C + 0x28) = D。当调用到D的时候，此时的rdi为C。如果_wide_data也可控的话，rsi也能控制。

函数的调用链如下：

详细分析如下：
首先看_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，相比上两条链的约束条件要更多一点。

使用_IO_wfile_sync函数控制程序执行流

对fp的设置如下：

• _flags设置为~(4 | 0x10)
• vtable设置为_IO_wfile_jumps地址（加减偏移），使其能成功调用_IO_wfile_sync即可
• _wide_data设置为堆地址，假设其地址为A，即满足*(fp + 0xa0) = A
• _wide_data->_IO_write_ptr <= _wide_data->_IO_write_base，即满足*(A + 0x20) <= *(A + 0x18)
• _wide_data->_IO_read_ptr != _wide_data->_IO_read_end，即满足*A != *(A + 8)
• _codecvt设置为可控堆地址B，即满足*(fp + 0x98) = B
• codecvt->__cd_in.step设置为可控堆地址C，即满足*B = C
• codecvt->__cd_in.step->__stateful设置为非0，即满足*(B + 0x58) != 0
• codecvt->__cd_in.step->__shlib_handle设置为0，即满足*C = 0
• codecvt->__cd_in.step->__fct设置为地址D,地址D用于控制rip，即满足*(C + 0x28) = D。当调用到D的时候，此时的rdi为C。如果rsi为&codecvt->__cd_in.step_data可控。

函数的调用链如下：

详细分析如下：
直接看_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。

例题分析

依旧以 中的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。