实验环境

静态分析

首先查看漏洞编号获取信息。

fig:

可以得到一些模糊的信息，如漏洞产生的地点在于恢复卷（recovery volumes），漏洞的原因是在于没有对用户提交的数据进行校验，可能导致缓冲区溢出，从而导致RCE。

从rarlab上能得到更多信息，如发生的漏洞是处理RAR 3.0格式，触发的漏洞条件是解压与格式错误的rev文件同一目录下的rar文件。

fig:

使用bindiff对比查看6.22和6.23版本的unrar.exe（winrar.exe可能只是一个GUI）。发现多了一些额外的检测，看起来很像对溢出的检测。

fig:

由于该检测与255进行比较，可以去尝试搜索unrar的源代码，并在其中搜索255这个值。由于2023年9月10日存在漏洞的该库代码已经修复，并且没有一个好的分支管理，所以只能看到修复后的结果如图。

fig:

漏洞产生的unrar代码。

fig:

如今修复后的代码。

fig:

可以发现控制SrcFile索引的本质是P[2]+P[0]-1，而检测只对P[1]+P[2] > 255进行了检测。而SrcFile的容量为256。

fig:

为了触发漏洞，我们需要调用bool RecVolumes3::Restore(CommandData *Cmd,const wchar *Name,bool Silent)函数，所以需要构造rar3的恢复卷。

Windbg Attach进程，触发崩溃。

fig:

栈回溯如下：

fig:

使用Unrar.exe

fig:

IDA查看

fig:

由于本次分析32位和64位混杂，所以会看起来比较乱。

关于此处复现有几个问题没弄清除，rev格式文件的详解没有找到，所以并不懂PoC是如何编写的。
其次本次漏洞利用能覆盖的数据为Array类型的Buff，但是会收到ASLR，DEP，GS，CFG防护措施的影响。但是我想既然能覆盖对象，为什么不尝试覆盖虚函数呢？后续进行漏洞利用的学习的时候可以回来再看看。
最后就是补丁分析，发现者究竟是如何从那么多差异中确定该补丁的作用呢？是每一个都看过了还是怎么样（当然，补丁中的信息和漏洞描述可以对上，这是否是确定的证据之一呢）