Security problem in unacev2.dll

[ghisler(Author)]

This ACE is specific for the vulnerability in Total Commander. I haven't tried it with WinRAR.

The page where the vulnerability is explained uses a similar path with an EXE file which they claim is the RAR vulnerability:
https://www.askvg.com/security-fix-all-winrar-versions-are-affected-by-critical-vulnerability/

[kb80]

I've checked with WinRAR 2.8, and it was able to extract this file from your archive.
It is funny that WinRAR 2.8 is able to view the file but can't extract archive (it has own ace.fmt library for ACE format), while WinRAR 4.2 is not able to even view the file (it has both own ace.fmt library and UNACEV2.DLL, and it seems that ace.fmt is used for reading listing and UNACEV2.DLL is required for extraction).

It seems, that only WinRAR 5.0-5.61 is able to unpack the testfile.ace (with paths option enabled) and yes, they are affected: the c:\b\b.txt is created with the real content. If you replace unacev2.dll in such versions of WinRAR installation to the ghisler-patched version, the unpack process fails with "Write error...". So, the patched unacev2.dll eliminates "WinRAR's vulnerability" (at minimum for the testfile.ace). The behaviour is the same as in TC. It would be nice to know by another testfile, the patched dll also helps on the SMB attack vector, too.

However, WinRAR versions 2.70-4.20 don't unpack the testfile.ace (with paths option enabled), they throw Cannot create C:\C:C:..\b\b.txt (or C_C_..\b\b.txt). So is it possible, that the 19 years are actually 6 years?

WinRAR versions 2.70-5.61 and TC unpack the testfile.ace with paths/subdirs option disabled to the target folder, regardless of unacev2.dll is original (2.6) or patched (2.6.1).

[ghisler(Author)]

How did you unpack the RAR file in WinRAR? In Total Commander, it only happens when you use "Unpack selected" via main menu, not when opening the archive with ENTER and then trying to unpack with F5. I assume that there are similar effects in WinRAR: When you try the file alone, there will not be a problem, only when unpacking the entire archive (maybe via Windows context menu?).

[kb80]

How did you unpack the RAR file in WinRAR? In Total Commander, it only happens when you use "Unpack selected" via main menu, not when opening the archive with ENTER and then trying to unpack with F5. I assume that there are similar effects in WinRAR: When you try the file alone, there will not be a problem, only when unpacking the entire archive (maybe via Windows context menu?).

Yes, the entire ACE (not RAR ) was unpacked without entering to it. Interactive mode, via Windows context menu and in command line mode, too ([ProgramDir\]WinRAR.exe x [source path\]testfile.ace "destination path").

Another thing. Here is another testfile, that can be unpacked even with the patched unacev2.dll (first unpack zip with pass 'ghisler' to get the ACE file). Although TC9.22RC1 doesn't allow unpacking it, directories those are specified inside ACE are still created to C:\ (because the unacev2.dll doesn't return at the patched address).

[MVV]

I have only portable WinRar for tests, so I've focused the archive in WinRar explorer and extracted it via context menu. As I wrote, it was able to create target folder c:\b, but not the file in it.

[ghisler(Author)]

2kb80
Thanks for the test file. Total Commander itself prevents the creation of files outside the designated target directory. However, directories are created by the dll itself without asking the user. The DLL itself only prevents directory traversal via "..". This is because most browsers download files to c:\users\<username>\downloads , and ..\Start menu\Programs\Startup cam be written without admin rights. The global directory c:\ProgramData\Microsoft\Windows\Start Menu\Programs\ is protected via UAC.

[ghisler(Author)]

I have created an improved version of the fixed DLL, which not only handles the ..\ traversal error, but also prevents unwanted directory creation when the archive contains a path in the following forms:
C:\C:\directory\file.ext
or
C:\\directory\file.ext

Download here (updated file at same address):
https://www.totalcommander.ch/win/unacev2_fixed.zip

In pseudo code, it does the following:
if (Path[1]==':' && Path[2]=='\')
strcpy(Path, &Path[3]); <- this part is left unchanged. It handles paths in the form C:\directory\file.ext -> directory\file.ext
The following is changed:
if (Path[1]==':' || Path[0]=='\')
return -1;

So if the path contains a drive at the beginning, or starts with a slash or backslash, the unpacking is again aborted immediately.

[kb80]

The unacev2.dll 2.6.2 brake unpacking testfile_kb80 (and also prevents creation of empty dirs now) which is good protection method on systems, where UAC is a non-existant feature, such Windows 2000/XP/2003 - where the C:\ProgramData\Microsoft\Windows\Start Menu\Programs\ is actually "C:\Documents and Settings\All Users\Start Menu\Programs\Startup" (English Edition).

Really on systems, where the HOME (at minumum \Documents and Settings / \Users) is moved to another logical drive are also partially procected against the "C:..//", "C:\" beginning crafted string with original unacev2.dll, because the malicious program can't be put into the startup folder, but it's off.

Testing the unacev2.dll 2.6.2 on your original testfile also prevents unpacking, but the application gives no error message. Checked with TC9.0a/9.22RC1/9.22RC2 and WinRAR 5.61. It seems, that one of the patched relocation words modifes the "../" check and causes the ret value to >-1. I have more fixed variants, too - will upload later.

[ghisler(Author)]

Thanks for your tests. The new DLL should now prevent extraction also for path starting like this:
c:\c:anything
c:\\anything
\anything

I also noticed the missing error messages, but couldn't find any reason for that.

[kb80]

I've modified the file in 5 steps. You can download the archive here (pass: ghisler). In UNACEV2_1.DLL only the relocation words are changed, so the expected error message arrives on your testfile (both in TC and WinRAR). From UNACEV2_2.DLL to UNACEV2_4.DLL some logical modifications are made directly, so extra jumps and the extra "pop registers then ret" routine (as it is in your 2.6.1 patch) are removed (shared with identical pop/ret routine on higher address). The three basic check code (:, \, ../) block was moved to directly follow each other and wiped the non-executed code with 0x90-s, so all the 0x90 codes are now on non-exec area (call arguments and relocation words updated). The first and second check on failure can jump directly to the original ret routine, because the byte distance is lowered to <128 within the "blockmove". The version resource and file Time and Date stamp are not modified, because the checking logic is the same as your 2.6.2 version (you can adjust if you like). The UNACEV2_4.DLL is the most efficient version, because it's free from extra jumps. Please test it on more Windows editions, if you have resource for it.

[ghisler(Author)]

2kb80
Thanks for your effords. I have checked your dll, and your changes are equivalent to mine. You saved the duplication of the pop registers+ret routine, but we still get no error message for the case where the path starts with C:\\ or a single backslash. Also this function isn't really time critical, so the number of jumps isn't that important. Therefore I will keep my solution for now because I have tested it extensively over multiple weeks.

Did you try to figure out how we could signal to unacev2.dll that there is an error?

[klappa]

The vulnerability is already being exposed in over 100 types of malware at this moment. Is Total Commander safe?

[ghisler(Author)]

Yes, if you either
- use TC 64-bit - it doesn't unpack ace files
or
- use TC 32-bit version 9.22
or
- replace the unacev2.dll in your older TC installation with my patched one, or delete the old unacev2.dll:
https://www.totalcommander.ch/win/unacev2_fixed.zip

[kb80]

2kb80
we still get no error message for the case where the path starts with C:\\ or a single backslash.

I get error message with C:\\, but no error message with single backslash. Latter is because no error message arrives with the original unacev2.dll, too. The reason is, in that case simply doesn't get called the (patched) path parsing routine, because there is another check for it. So I patched the dll again, in the case starting with single backslash the dll now throws the error code 4 (disk full). Another code has also patched, because WinRAR 5.61 still extracted archive with C:\\ path (because skipping the cleanpath function). Unfortunately WinRAR doesn't show error message on \aaaaaa1\b\b*.txt (but TC shows). I've updated unacev2_262_fixed_to_show_error_msg_in_app.7z and testfile_kb80.zip links, you can test them (UNACEV2_3a.DLL and UNACEV2_4.DLL had a logical defect, fixed them; UNACEV2_?new.DLL brings the error message on \aaaaaaa1\b\b.txt).

[rus73]

Not tired already chewing this unacev2.dll?