CVE-2023-40477 WinRAR remote code execution vulnerability 0Day PoC

“Game of Rars” – Exploring a new remote code execution vulnerability in WinRAR with a proof-of-concept

WinRAR, with more than 50 billion users, faces new vulnerabilities (CVE-2023-40477, CVE-2023-38831).
Today, we present for the first time: a PoC for CVE-2023-40477.
Although RCE is believed to be exploitable, its implementation does not look promising for a number of reasons.
We present here a comprehensive study of the technology: its impact, exploitable scenarios and mitigation measures.
The vulnerability has been fixed in the recent WinRAR v6.23 and we also provide an alternative mitigation here.

CVE-2023-40477: Technical Overview and Proof of Concept

On August 2nd, Winrar 6.23 was released with some vague warnings about critical vulnerabilities.

What we do know is – the vulnerability (CVE-2023-40477) has been fixed, as shown in the picture:

Equipped with BinDiff, IDA and Notepad, let's dig in.

Compare binary files

We know v6.23 has the vulnerability fixed, so let's try to find the pre- and post-fix versions so we can observe it. winrar-v6.22 and winrar-v6.23:

Title Winrar directory structure and interesting files

It can be observed that winrar.exe is just a GUI, if it is a vulnerability in decompression - it may also exist in "unrar.exe". Comparing 6.23 and 6.22 provides the following differences:

In 6.23, looking at the flow diagram gave me a couple of interesting additions (in the big function diagram, it looks like the main extract):

Looking closer, these appear to be extra checks!

This looks promising! We see some extra checks here for var < 255! Interestingly, it looks like there is overflow checking permissions here.
So, it's time to trigger (i.e. change the bytes to their maximum value).

I've seen the RAR format and from the description we know this is related to RAR4 (vol3?) recovery volumes,
so I generated the RAR4 with these properties and it gave me a list of files like this:

RAR file.RAR
RAR_file.r00
RAR_FILE00.rev version
RAR_file.r01
RAR_FILE01.rev version

I have tried to force delete the contents of any "byte-like" values in the ".rev" and "rXX" volumes without success. It doesn't trigger or change anything.
I then tried googling some "unrar" source code - maybe it exists as part of some other project? !
So I successfully found this old repository: https://github.com/aawc/unrar

By looking at the source code, we see multiple "255" constant selections, specifically in "recvol3.cpp" , which also appear in in the original 6.22 source code, so maybe extra source code was added due to... overflow?
Let's check it out, and digging a little deeper, I found that the security check is actually related to 0xff/255.

loopholes

Here, P[i] is extracted from the ".rev" file itself. They are located at the end of the file.
These P[i] are used to determine which recovery volume they represent and what FileNumber they fit.
FileNumber is also retrieved from them in P[2] .
Next, a File* is allocated and placed at an index in an array of size 256 that we control! (Line 241).
This explains the 255 checks.
Because the index is actually equal to: P[2]+P[0]-1 . We can control it almost arbitrarily through the "rev" volume content. So, after all, we can overwrite that buffer (pointing to the file
structure) with pointers , and they overwrite the next property in the current object.

PoC

In order to trigger the vulnerability, we found that "Restore()" needs to be called in recvol3.cpp.
We also discovered that a rebuild step is required, so some of that will be done by overwriting the pointers.

To do this, some missing rar volumes (.r00 is missing) and .rev volumes need to be available.
Additionally, we need to make sure the crc32 checksum is correct.

For convenience, we generated the original rar4 recovery volume by using the GUI, which can certainly be smaller and more efficient, possibly containing 2-3 files at most.


# 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)

However, we also saw the CVE-2023-40477 vulnerability on the rar-labs website , which likely confirms our findings.

We successfully crashed winrar/unrar in the following situations :

1. Memset overwrites invalid memory with zeros (possibly after the buffer):

Heap overflow may occur in winrar.exe when using "extract to"

availability

To determine exploitability, let's look at the structure we covered after the 256 array.
Let’s determine how an attacker could use this primitive to obtain RCE and what mitigations exist.

// 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();

The "File*" pointer is used here to overflow the "Buffer" object.

Fortunately, there are many protections in place: ASLR, CFG, Stack-Cookie, and DEP.

This also doesn't mention the binary differences between winrar versions. All of these make exploitation possible, but unlikely to common threat actors.

Influence

Despite its high CVE rating, the complexity required for successful exploitation suggests that the potential for widespread abuse is low, unlike the widely exploited Log4j RCE vulnerability.

Interestingly, Chromium also seems to utilize the unrar library: https://chromium.googlesource.com/chromium/src//6ff23b0604e2edbe7ef282564ea340f5c72ab91a^/

It is plausible that the unrar library was incorporated into Chrome OS as a third-party dependency, although there are no code references showing its usage.

Mitigation measures

In terms of mitigation strategies, there are several viable options to consider:

Full Fix: Updating Winrar to 6.23+ will fix the issue completely.
Fix: If updates are unavailable or difficult to deploy - block *.rev files (preferably also block: *.rXX files and *.partXX.rar). This may be a quick fix, although it's not entirely confirmed nor official.

Complete project download

[CSDN Download] https://download.csdn.net/download/qq_39190622/88291093

How to test?

You can generate your own PoC, or just test the included demo RAR file (verified to crash winrar-6.22 after unpacking)

PoC generation- cve_2023_40477_poc.py
Demo RAR file - only extract Rar.rar from 示例 poc_after_gen directory.