一直以为在2.31补丁后,Large bin Attack 就无法使用了。在打比赛bsidesahmedabad CTF时,才发现原来在2.31 下也有骚操作来利用Large bin来进行attack。(唉~(◞‸◟ )tcl…)
Large bin Attack目的
Large bin Attack的目的是 利用Large bin 向任意一地址任意一个地址写入一个大数(p2 chunk addr).
how2heap 源码学习
经过信息收集,发现在how2heap中更新了Large bin Attack 源码。(ps:菜鸡才知道正版how2heap项目有团队在不断维护,中文翻译版how2heap已经没有维护了,啊这…..)
源码
1 |
|
新保护
由上文源码所说,在2.30后libc 增加了两个检查:
1 |
|
先说check 2:对当前bin的bk值对应bin的 fd是否为当前bin。
check 1 对largebin的bk_nextsize进行了跟bk一样的检查,即当前bin的bk_nextsize值对应bin的 fd_nextsize是否为当前bin。
新利用点
1 | if ((unsigned long) (size) < (unsigned long) chunksize_nomask (bck->bk)){ |
这源码中,核心就是利用这段代码。这部分完整的源码在https://elixir.bootlin.com/glibc/glibc-2.31/source/malloc/malloc.c#L3831
这个代码在unsorted bin加入largebin时,若unsorted bin 大小大于目前最大largebin时触发。在触发时,被未对fd_nextsize
和bk_nextsize
进行检查,就直接向victim->bk_nextsize->fd_nextsize
写入victim的地址。
流程梳理
首先我们如下写创建4个chunk。
1 | size_t target = 0; |
然后:
1 | free(p1); |
让p1 加入了larger bin,此时:
1 | largebins |
然后释放p2:
1 | free(p2); |
此时p2为unsortedbin:
1 | unsortedbin |
此时P1的内存分布为:
1 | gdb-peda$ x/36gx 0x55f31dd5e5e0 |
然后我们再让p2进入larger bin
1 | size_t *g4 = malloc(0x438); |
这时,由于p1>p2,我们的攻击将进行
1 | fwd->fd->bk_nextsize = victim->bk_nextsize->fd_nextsize = victim; |
,在target处写入p2地址:
1 | 0x7f0c129bee30: 0x0000000000000000 0x0000000000000000 |
例题_bsidesahmedabad_2021_padnote
题目环境:
1 | Arch: amd64-64-little |
题目源码:
1 |
|
题目主要漏洞在它的edit功能的安全检查:
1 | /* Security check */ |
题目在offset + count
进行检查时,忘了在int64 中0x8000000==0
的情况。
导致我们可以任意写,然后通过 PrintNote
泄露出基地址。
但是,由于calloc函数,导致我们不能用tache bin 来attack。
但是由于题目没有限制chunk大小,导致我们可以利用Large bin Attack 写入`free_hook+0x20处再创造chunk覆盖
__free_hook`为system。
exp:
1 | #!/usr/bin/env python |