前段时间参加了ciscn华中赛区的半决赛,成绩不是很理想,就在最后patch了一道catchme,其它题目都没有去看,今天看了师傅们的博客,发现全是uaf漏洞,心在滴血www。但是在复现途中确实的发现了自己很多不足。:chart_with_upwards_trend:
本来想记录一下的,一直拖着没搞,趁着今天空闲时间比较长来复现一下题目
catchme
house of storm
特性 malloc calloc realloc 主要目的 分配内存 分配并清零内存 修改已分配内存的大小 初始化 随机残余数据 (Dirty) 全清零 (Zero-initialized) 保留旧数据,新扩大部分不初始化 参数个数 1 (总字节数) 2 (元素个数, 单个大小) 2 (原指针, 新总字节数) 性能 高 略低(有清零开销) 不确定(若涉及拷贝则低) 返回值 指向新内存的指针 指向新内存的指针 指向调整后内存的指针(可能变动) 这里再放一下

add看到有三种模式的malloc,并且会输出chunk地址的WORD2

uaf漏洞

有show,从+8位置开始输出
终于不用通过IO结构体去操作了,但是只能show1次

从user_con+8处开始填入,只能改0x18大小,并且限制次数为3次

还有一个clean函数,清空了所有的chunk地址
break
分析:
2.27的libc版本,3个malloc的大小中还有一个0x50,PIE的 x64 程序的堆地址总是 0x55xxxx… 或者 0x56xxxx…,考虑house of storm
先填满0x50的tcache,然后泄露libc基地址,再malloc一个chunk释放进unsorted bin,因为它只能从user_con+8的位置开始修改,改bk为free_hook-0x10-0x8,之后再通过large bin改free_hook这个伪造chunk上面的伪造的size
Houseof Storm中,目标是让calloc从伪造的地址(free_hook 附近)分配出内存。calloc 默认不使用Tcache:在大多数GLIBC版本中,calloc 在申请内存时会跳过从Tcache中直接取块的步骤。但如果此时Ox50的Tcache没满,calloc在找到你那个伪造的0x56块时,并不会立刻把它返回给用户。
• 根据Tcache Stashing机制,它可能会尝试把这个新发现的”好东西”先放入Tcache列表里。
• 由于你的块是伪造的,它只具备最基础的size和一些指针结构。如果它被塞进Tcache,可能会因为 Tcache的一些额外检查(如key字段清零或计数器更新)或者在后续从Tcache取块时触发崩溃。
1 | from pwn import * |
fix
这里放一篇赛时写的文章
broken_message
fix
uaf漏洞
