这几天在看house of orange，然后遇到了HCTF这么一道题目，感觉能够用house of orange来做（和出题大佬spine聊完之后发现这个方法不算准确的预期解法，还有别的解法。），但是和house of orange的场景不一致，最后貌似学会了一种不需要知道heap地址的house of orange攻击方法，这样house of orange的攻击面更加广泛了，不知道各位大牛怎么看，有误之处，还望多多指教。

程序流程很简单了，就是一个堆分配，然后一个gets读入，有溢出，同时之后又打印，有格式化字符串。

咋一看，格式化字符串漏洞，哇，这道题目这么简单的吗？然后。。。。。
发现开启了FORTIFY_SOURCE机制，emm......记得32位好像可以绕过，然后再定睛一看64位，mmp,好像饶不了？难不成是0day?
FORTIFY_SOURCE机制对格式化字符串有两个限制

第二点还是比较好过的，依然还是可以泄露出来信息的。但是第一点是无法绕过的，至少在谷歌上没有找到方案，在32位的情况下是可以绕过的，所以思路不能停留在格式化字符串上。

gets这里可以无限写入直到\n为止，所以通过这个漏洞可以修改top_chunk，所以想到了可以使用house of orange（关于house_of_orange有不懂的可以看我之前关于house of orange的博客http://simp1e.leanote.com/post/9571ae32e8ca）。

先用格式化字符串漏洞泄露libc地址，为我们后面的house of orange做好准备。和普通的格式化字符串漏洞泄露方法差不多，就是需要把%n$前面的n-1个也打上就行。然后你可以去尝试用用%n，会发现被检测出来使用可写地址，然后结束了，我的泄露部分如下，能够泄露出来libc_start_main的返回地址，由偏移得到libc地址，同时栈上还有stack地址一并进行了泄露。

但是这里有一个问题就是我们无法泄露heap的地址，但是在house of orange里面是需要获取heap地址来设置vtable的，而且这里给出的服务器上libc的版本是2.24，在2.24的libc源码中对io_file的vtable进行了IO_vtable_check,源码如下https://code.woboq.org/userspace/glibc/libio/vtables.c.html#39

这里其实我没看懂，但是知道就算我们知道了heap地址，应该还是正常伪造的vtable通过不了检查的，那么有一个思路，有没有可以利用不在heap上的vtable呢，这个真的可以有，在strops的源码中就有这样的io_jump结构。 https://code.woboq.org/userspace/glibc/libio/strops.c.html#14

这里面的结构体有什么特点呢？一个是这个io_str_jumps是在libc上的，第二是我们来看这个IO_str_overflow这个函数。

这个函数里面是有一个相对地址调用的，也就是调用fp结构某处地址，由于fp这个结构我们正好是可以控制的。具体偏移是多少呢？这个偏移我们就不看源码了，直接用IDA来看这个偏移。

由IDA我们可以很快知道这个偏移是0x1c*8=0xe0,同时执行函数时候参数正好2*v6+100,不过我们也需要绕过一些判断。
那么我们一步一步来分析

我们设置v7为binsh的地址，那么v6=(binsh-100) /2，把0xe0偏移位置设置成system地址就可以了，所以，这样的话house_of_orange是不需要依靠heap地址的，我还看了一下，其他版本的libc也有和这个io_str_jumps，所以这应该是一个通用的方法。
这里参考了lowkey师傅在安全客的文章，以及angelboy的house of orange，感谢他们的分享，学习到不少知识。

最近某湿敷发了一句话，know it then hack it，这几天重新学习堆方面的漏洞利用知识时候很受教，在学习新的攻击方法和漏洞利用思路时候，必须把每一个步骤都了解清楚，必要的时候比照libc源码进行分析，不知道内部原因的情况下，是无法吃透一个漏洞利用思路的精华所在的，那就更别谈对方法进行改进了。
题目附件我已经上传了，题目最近还开着，大家可以自己尝试去做做，据spine大佬说还有很多解法，我的解法不一定是官方出题思路，大家如果用别的姿势进行利用成功的话，也可以分享来学习一下。

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