CVE-2023-40477 WinRAR 远程代码执行漏洞 0Day PoC

Rainbow Technology

已于 2023-09-02 17:10:24 修改

阅读量1.7k

点赞数

分类专栏：系统安全 CVE 文章标签： winrar 系统安全安全威胁分析网络攻击模型网络安全 web安全

于 2023-09-02 16:16:11 首次发布

本文链接：https://blog.csdn.net/qq_39190622/article/details/132637853

版权

系统安全同时被 2 个专栏收录

11 篇文章

订阅专栏

CVE

7 篇文章

订阅专栏

“Game of Rars” – 通过概念验证探索 WinRAR 中新的远程代码执行漏洞

WinRAR 拥有超过 500 亿用户，面临新漏洞（CVE-2023-40477、CVE-2023-38831）。
今天，我们首次展示：CVE-2023-40477 的 PoC。
尽管 RCE 被认为是可利用的，但由于多种原因，其在实现过程中看起来并不乐观。
我们在此展示全面的技术研究：其影响、可利用的场景和缓解措施。
该漏洞已在最近的 WinRAR v6.23 中修复，我们在这里还提供了另一种缓解措施。

CVE-2023-40477：技术概述和概念验证

8月2号，Winrar 6.23 发布了更新，并带有一些关于严重漏洞的模糊警报。

我们所知道的是 – 漏洞 (CVE-2023-40477) 已修复，如图：

配备 BinDiff、IDA 和记事本，让我们深入研究。

比较二进制文件

我们知道 v6.23 已修复了该漏洞，那么让我们尝试查找修复前后的版本，以便我们可以观察它。winrar-v6.22 与 winrar-v6.23 ：

可以观察到 winrar.exe 只是一个 GUI，如果是解压缩中的漏洞 - 它也可能存在于“unrar.exe”中。比较 6.23 和 6.22 提供了以下差异：

在 6.23 中，通过查看流程图给了我几个有趣的补充（在大功能图中，看起来像是主提取）：

仔细看，这些似乎是额外的检查！

这看起来很有希望！我们在这里看到一些 var < 255 的额外检查！有趣的是，看起来这里有溢出检查权限。
因此，触发时间到了（即将字节更改为最大值）。

我已经看过RAR格式，从描述中我们知道这与RAR4（vol3？）恢复卷有关，
所以我用这些特性生成了RAR4，它给了我一个文件列表，如下所示：

RAR文件.RAR
RAR_文件.r00
RAR_FILE00.rev版本
RAR_文件.r01
RAR_FILE01.rev版

我曾试图强行删除“.rev”和“rXX”卷中任何“类字节”值的内容，但没有成功。它没有触发或改变任何事情。
然后，我试着用谷歌搜索一些“unrar”源代码——也许它是作为其他项目的一部分存在的？！
于是我成功找到了这个旧存储库：https://github.com/aawc/unrar

通过查看源代码，我们看到多个“255”常量选择，特别是在“recvol3.cpp”，它们也出现在原来的6.22源代码中，所以可能是因为…溢出而添加了额外的源代码？
让我们检查一下，深入一点，我发现安全检查实际上与0xff/255有关。

漏洞

这里，P[i]是从“.rev”文件本身中提取的。它们位于文件末尾。
这些P[i]用于确定它们代表哪个恢复卷以及它们适合什么FileNumber 。
FileNumber也在P[2]中从它们检索。
紧接着，File*被分配并放置在我们控制的大小为 256 的数组中的索引中！（第 241 行）。
这就解释了 255 次检查。
因为索引实际上等于：P[2]+P[0]-1。我们几乎可以通过“rev”卷内容任意控制它。
所以，毕竟，我们可以用指针覆盖该缓冲区（指向文件结构），它们会覆盖当前对象中的下一个属性。

PoC

为了触发该漏洞，我们发现需要在recvol3.cpp中调用“Restore()”。
我们还发现需要进行重建步骤，因此将通过覆盖指针来完成一些操作。

要做到这一点，需要有一些缺失的rar卷（.r00缺失）和.rev卷可用。
此外，我们需要确保 crc32 校验和是正确的。

为了方便起见，我们通过使用 GUI 生成的原始 rar4 恢复卷，这肯定可以更小且更高效，最多可能包含 2-3 个文件。


# 1. re-generate malformed recovery vols.
data = open('%s01.rev' % ARCHIVE_NAME, 'rb').read() # just use the first and malform it up.
names = ['%s%s.rev' % (ARCHIVE_NAME, str(i).zfill(2)) for i in range(256)]
# "destroy" the P[i]'s
datas = [data[:-7] + bytes([0xf0, 0x00, i]) + calc_crc(data[:-7] + bytes([0xf0, 0x00, i])) for i in range(256)]

# 2. overwrite malformed recovery vols.
for i in range(256):
	fname = names[i]
	data = datas[i]
	open(fname, 'wb').write(data)

然而我们还在 rar-labs 网站上看到了 CVE-2023-40477 vulnerability，这很有可能证实了我们的发现。

我们在以下几种情况下成功地使 winrar/unrar Crash：

1、Memset 用零覆盖无效内存（可能在缓冲区之后）：

使用“extract to”时winrar.exe中可能出现堆溢出的情况

可利用性

为了确定可利用性，让我们看看我们在256数组之后覆盖的结构。
让我们确定攻击者如何使用此原语获得RCE以及存在哪些缓解措施。

// RecVolume3 struct - that gets overflowed
class RecVolumes3
{
  private:
    File *SrcFile[256]; // overflow in here with File* pointers.
    Array Buf;

#ifdef RAR_SMP
    ThreadPool *RSThreadPool;
#endif
  public:
    RecVolumes3(CommandData *Cmd,bool TestOnly);
    ~RecVolumes3();
    void Make(CommandData *Cmd,wchar *ArcName);
    bool Restore(CommandData *Cmd,const wchar *Name,bool Silent);
    void Test(CommandData *Cmd,const wchar *Name);
};
...
...
// Array template class:
template  class Array
{
  private:
    T *Buffer;
    size_t BufSize;
    size_t AllocSize;
    size_t MaxSize;
  public:
    Array();
    Array(size_t Size);
    Array(const Array &Src); // Copy constructor.
    ~Array();

此处利用“File*”指针使“Buffer”对象溢出。

幸运的是，内部有许多保护措施：ASLR、CFG、Stack-Cookie和DEP。

这还没有提及 winrar 版本之间的二进制差异。所有这些都使得利用成为可能，但对于普通威胁行为者来说可能性不大。