征战hitcon2022，pwn手坐大牢，wtfshell这道题审了三小时源码，只看出来一个 chk_pw侧信道+read_pw未置零，最终可以通过侧信道leak出一个heap地址，没有看出其余的洞，最终放弃。

wtfshell1最终解数为4，wtfshell2最终解数为3。第一题解出来了第二题基本就解出来了。

感谢crazyman第二天来告诉我wtfshell的主要漏洞（strtok off by null），思考后脑子里出现了一套完整的利用思路。因此做出如下复现。

文章不太喜欢附图，大家多包涵，做出来难度还是蛮大的，因为即使知道了strtok->off-by-null，还是有非常多细节需要思考☹️。

题目提供了源码，一共930+行，libc为glibc2.36 3，由于glibc-all-in-one中找不到该版本libc，因此我换了一个小版本，用glibc2.36 4进行复现。

程序实现了一个类似于shell交互，输入rtfm可以查看菜单：

功能主要为：

查看chk_pw函数：

可以看到逻辑为：

当检查途中遇到不正确的字符，且 i 并未到达pw_len时，我们可以通过输入\n符是否退出chk_pw来判断当前密码字符是否正确。

且若密码不正确，输入\n退出chk_pw后会打印：

因此我们可以通过接收字符来判断密码字符是否正确，达到侧信道爆破的目的。

查看user结构体：uname堆指针跟在ushadow密码后。

查看read_pw函数：在读满PWMAXsize的时候，并未在末尾置零，导致user->ushadow与user->uname指针连接。

查看chk_pw函数：判断密码位数是通过strlen来判断的：

因此结合起来，我们可以利用侧信道+结构体，来leak出一个堆地址。

main函数中的gbuff是拿来储存我们的命令字符串的，大小为0x400，对其有一个分割符处理：

strtok函数会不断往字符串后面遍历，直到遇到\x00截断，同时strtok会将查找到的隔断符delim设置为\x00。

查看隔断符delim：

其中！的ascii码值为0x21，若我们能在gbuff 0x400大小的堆块里填入0x408个非零字符，同时在后面跟上一个size头低字节为0x21的堆块，即可通过strtok实现off-by-null。

首先申请一个user结构体，填满其pwd。本地gdb调试之后发现这样user->uname指针末尾为0，因此可以申请两个user结构体，第一个用作填充，使第二个user结构体的user->uname指针末尾不为0。

由于堆地址最低字节固定，不用泄露：

堆风水真的给整麻了。

首先我们需要得到一个被填满0x408非零字节的gbuff堆块。

整个程序free只能通过两种方式：①xrealloc，②xfree。

其中xfree函数：

其中malloc_usable_size函数会获取该heap所有能写的size，也就是说紧邻该堆块的下一个堆块的prev_size也会被算进来清零，因此我们要避开xfree，只能用xrealloc来free。

xrealloc其实就是调用realloc函数，当我们申请一个大于当前堆块size的堆块时，realloc会free掉当前堆块，然后重新申请堆块，这个过程中是不会清空free的堆块内容的。

小堆风水一波，得到一个填满0x408非零字节的gbuff堆块步骤为：

接下来就很简单能够想到在gbuff的下面申请一个堆块，off-by-null之后利用，以下文章将该堆块命名为off-by-null-chunk

在思考这一段时，卡了我非常久，特别鸣谢winmt师傅和ln3师傅和我激情讨论，一次次点醒我。

①off-by-null-chunk的prev_size我们无法控制。

首先我们知道，off-by-null-chunk的prev_size是被填满了八字节的，不然无法触发strtok然后触发off-by-null。

gbuff堆块与off-by-null-chunk是紧挨的，然后我们如果要更改off-by-null-chunk的prev_size，就必须通过gbuff来更改。

我们知道，我们只能控制gbuff堆块的前0x400个字节，更改不了off-by-null-chunk的prev_size。

尝试思路一：首先肯定要触发off-by-null，我想的是触发off-by-null之后，再次调用cmd_irl来free掉gbuff，然后申请一个普通chunk，size为0x408，这样就能更改到off-by-null-chunk的prev_size。

但是这样是显然行不通的，因为free掉gbuff的时候，会判断gbuff下面那个堆块的use状态，由于已经off-by-null，会触发off-by-null，但是我们的prev_size不合法，这样会导致程序出错。

尝试思路二：我详细查阅了strtok的作用，如果出现连续的delim分隔符会如何处理，看能不能同时利用strtok将gbuff第0x400-0x408个字节中非prev_size部分清空，同时触发off-by-null。最终也以失败告终。

最终思路：再次审查源码后，发现cmd_rip函数中：

注意代码中我注释的this和that部分。

关注到remove_slash函数，会将字符串中含\的部分置为\x00：

同时也是通过strlen来判断长度。

menu与cmd_rip函数中，按先后顺序调用了如下：

如果我们构造这样的payload：

同时，在之前堆风水写gbuff的第0x400-0x408字节，若我们填入如下内容：

那么在执行第一句语句之后，返回的指针已经指向

注意strtok第一个参数为NULL时，继承的是上一次strtok返回的指针。

因此执行第二句语句之后，能够将off-by-null的size头低位0x21置为0，触发off-by-null

同时，执行第三句语句，将调整我们的prev_size为正常。

因此至此，我们已经构造好prev_size。

我们知道，free一个堆块，会去检测下一个堆块的next_size是否合法：

我们free掉off-by-null-chunk的时候，除非off-by-null-chunk的size本身为0x501这种，off by null之后不用伪造next_size。否则需要伪造合法的next_size，不然free会触发错误。

伪造next_size的过程几乎没有希望的，之前看来：

首先off-by-null-chunk的size需要大于0x400（不能在tcache范围），在tcache范围内的tcache_off-by-null是没有作用的。

这就意味着我们申请的off-by-null-chunk的size需要大于0x400，那就只能调用cmd_rip来申请，其他都不能申请大于0x400 size的chunk。而cmd_rip的操作是根据strlen函数返回的长度来进行realloc的，也就是说，我们申请出某个size 的堆块，就必须填满他。

cmd_rip中部分代码：

但我们要伪造fake_next_size，fake_next_size中肯定带\x00截断，同时由于off-by-null-chunk原本size低字节为0x21，被改成\x00后，fake_next_size要放在off-by-null-chunk的+0x500处，例如如下结构：

其中padding为8非零字节。可以注意到fake_next_size中带\x00截断，因此我们不能申请到0x521大小的chunk。

想过很多种方法，例如利用realloc去进行一些trick，例如：

先申请出0x521大小的chunk，然后利用cmd_wtf里的strcpy往里填入零字节，再利用cmd_rip来realloc到适当字节，恰好写进fake_next_size，但是对一个内存大于申请size的堆块进行realloc，会free掉剩余size的小chunk：

例如对0x521 chunk 进行reallc(ptr,0x410)，他会free掉剩余的0x100字节。这样会破坏掉原来chunk的size头，导致我们不能触发off-by-null。

可见对大于0x400 size的chunk去写入一个fake_next_size是非常困难的。

转换思路呢？可能一开始就想错了，为什么off-by-null-chunksize一定要大于0x400呢？他的size可以是0x321，只要我们提前填满对应size的tcache_list即可。

而如果size小于0x400，我们观察cmd_wtf函数：

其中关键的即为：

若strlen(fdata)<strlen(gfiles[i]->fdata)，是不会触发realloc的，而是直接调用strcpy，也就是说，我们可以提前填满一个堆块，然后利用这个fdata size更小的时候，从后往前填充\x00字节，这样就能够伪造好我们的fake_next_size。

后续写入地址也多次用到这个方式，因此我封装了一个函数(不太优雅，将就着看)：

整理一下我们之前做到的事情：

并且这道题我们已经用侧信道泄露了堆地址，大大降低了off-by-null的难度，可以进行safe-unlink。

只用在上方伪造一个size，然后绕过如下检测即可：

堆风水：

如果我们构造成：

这里注意的是，p->fd->bk和p->bk->fd指向的地方，不能和p->fd_nextsize->bk_nextsize和p->bk_nextsize->fd_nextsize指向的地方相同，否则在通过第一个检测之后，会执行：

就绕不过第二个检测：

因此最终构造为：

这里我在off-by-null-chunk下方没有构造好，导致一个tcache的prev_inuse为0，触发了第二次unlink，小调整了一下即可。

off-by-null之后，中间夹了几个tcache，即可实现泄露和任意地址写。

需要注意的是：

能够任意写的tcache size必须要小，因为cmd中任何申请函数都是以strlen返回结果来进行malloc的，也就是说，如果我们想申请任意写，我们就必须填满其chunk。例如我最开始构造的tcache size为0x300，这样的话，申请过去的堆块必须填满0x2f0内容。

wtfshell1中，我的思路是申请到flag1堆块，更改其file->flag为3(rw)与file->name。

如果任意写的tcache_size过大，申请过去必须得写完，这会导致把堆上很多指针或者file->name破坏掉。

wtfshell2中，我的思路是打libc got表，那0x2f0大小必定会破坏掉非常多东西，因此也是不可能的。

因此做到这之后，我又重新调整tcache_size，小改了一波堆风水。

至此我们已经拿到heap_base，libc_base，并且有了任意写，泄露之后申请任意写过去改掉file->flag为3(rw)与file->name。

观察cmd_omfg:发现如果是root用户，可以查看所有文件内容(若具有可读属性)。

由于我已经将file->flag改为3，file->name改为aaaaaaaaaaaaaaaa。

直接调用show即可打印出第一个flag。

至此,wtfshell1 get。

ps：exp运行一次可能不能成功，侧信道爆破以及write_addr似乎有某些bug，不过多运行几次就能通。

wtfshell2只用考虑如何绕过沙盒，并且劫持程序流即可。

劫持strtok的libc-got表为magic_gadget，然后可劫持程序流。

沙盒是白名单，没有open。沙盒绕过卡掉了一个解，wtfshell2比wtfshell1少了一个解。wtfshell2相比与wtfshell1就是多了沙盒。因为我们在wtfshell1中已经拿到了任意地址写，和heap_base，libc_base，wtfshell2考察的就是如何绕过沙箱写orw：

沙盒绕过是由winmt师傅看出来的，沙盒大手子。

但是程序本身是白名单，并没有允许open，这该怎么办呢？

可以看到沙盒没有判断架构，而允许了preadv

而preadv在64位下调用号为：

同时openat在32位下调用号为：

因此直接可用int0x80调用32位下的openat。

注意沙盒里判断了preadv的第一个参数需要大于2，因此我们openat的第一个参数也需要大于2，而当openat使用绝对路径的时候，第一个参数不影响结果，故这里最好用绝对路径/flag2。

至此，wtfshell2 get

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