Security problem in unacev2.dll

[dlpz]

https://www.askvg.com/security-fix-all-winrar-versions-are-affected-by-critical-vulnerability/

Total commander also use this dll, maybe is affected too? Will be a good option delete unacev2.dll file from Total Commander Directory?

[Security Fix] All WinRAR Versions are Affected by Critical Vulnerability

WinRAR is one of the most popular and widely used file archive software for Windows operating system. It supports almost all popular file compression and decompression (extract) formats. Although it's a paid software but you can install its trial version for free to test its features. Long time back WinRAR provided its 3.51 full version for free download and still many people use that version in their computer systems.

There are many Windows users who are using WinRAR in their computer systems to extract downloaded ZIP or RAR files or to compress files and folders to send via emails or to store as a backup.

Recently a critical vulnerability has been discovered which affects almost all WinRAR versions released in last 19 years. This security bug includes remote code execution and Absolute Path Traversal.

This security bug allows attackers to extract a maliciously-crafted file archive to their desired folder on a targeted system and then add the malicious program to Windows startup list so that the program can launch automatically on next system reboot.

The security flaw is present inside a DLL file "UNACEV2.DLL" which is used by WinRAR to extract ACE file format.

[Stefan2]

Thanks for your report.


That is currently discussed in German Forum also

ACE-Format: Kritische Lücke in WinRAR erst nach 14 Jahren entdeckt
viewtopic.php?f=2&t=51946

and noticed by Mr. Ghisler.



 

[dlpz]

I just have curiosity for know if deletion of unacev2.dll file can be a problem for the Total Commander program, of course i´m not interessed in .ace files, i don´t use these from many years ago.

[Stefan2]

I just have curiosity for know if deletion of unacev2.dll file can be a problem for the Total Commander program,...

TC do need that DLL only if you ask TC to use that un-packer. Otherwise TC would not recognize if that file is missing.
But as general tip, just rename that file and work a week or two whit TC to see if it has any issue for you



 

[kesdoputr]

Sorry for first that I don't know it's tc problem or plugin problem.

I see this from winrar homepage https://rarlab.com/rarnew.htm that there is a security problem on UNACEV2.DLL
Image: https://i.imgur.com/D2KjVij.png

So i remove this dll from TC's dir, but i found i can't use the plugin excellence.wlx when i remove the UNACEV2.DLL
Image: https://i.imgur.com/hclF4Ee.png

I'm using windows 7 SP1 64bit with 32bitTC(excellence only have 32bit ver), i confirmed when i revert the UNACEV2.DLL then excellence can work.

Please help to check and maybe remove the UNACEV2.DLL on next TC ver for the security?
The ACE format seems not used for a long time and no update, thank you.

[kesdoputr]

Update：It seems only depnd on if there is a file named UNACEV2.DLL, i create a 0byte file and rename to UNACEV2.DLL
The excellence can still work.

[ghisler(Author)]

I was able to generate a test archive file myself by calculating the modified CRC checksum myself and writing it to the file.
Result: Total Commander is affected, but only in one function:
1. Unpack the entire archive with Alt+F9: affected, files can be unpacked into the wrong directory
2. Extract with Enter, highlight, F5: not affected, files will be skipped
3. Search for text in archives: not affected because files are unpacked without the path
4. Test archives: Not affected
5. The 64-bit version is generallynot affected because the dll is only present in 32-bit

So that the error can occur in the DLL, you first have to download such a manipulated file, and then unpack it with Alt+F9. If you want to play it safe, you can simply delete the UNACEV2.DLL. I have found a solution for the next TC version where such files are skipped or deleted.

[ghisler(Author)]

I have patched the unacev2 dll so it's not prone to the bug anymore. The DLL immediately terminates the unpacking process if it finds the string ../ or .. \ in the path name. In the process, directories with the name "test .." are wrongly recognized as dangerous. Since such names are not normally found on Windows, that's better than the vulnerability.

Download here:
https://www.totalcommander.ch/win/unacev2_fixed.zip

Installation: Double click on unacev2_fixed.zip within Total Commander.

[tikimotel]

With Total Commander using a un-Ace internal dll whenever possible by default, is Total Commander also vulnerable to same bug found in WinRAR?

From the WinRAR 5.70 release notes

21. Nadav Grossman from Check Point Software Technologies informed us
about a security vulnerability in UNACEV2.DLL library.
Aforementioned vulnerability makes possible to create files
in arbitrary folders inside or outside of destination folder
when unpacking ACE archives.

WinRAR used this third party library to unpack ACE archives.
UNACEV2.DLL had not been updated since 2005 and we do not have access
to its source code. So we decided to drop ACE archive format support
to protect security of WinRAR users.

We are thankful to Check Point Software Technologies for reporting
this issue.

[norfie²]

Maybe you missed the following thread:
https://www.ghisler.ch/board/viewtopic.php?f=3&t=51949

Moderation: thanks norfie, "ACE unpacking vulnerabillity" thread merged with "Security problem in unacev2.dll"

[infinity]

@ghisler

interesting to read about your modified unacev2.dll. Would your modifications also apply successfully (from security perspective) to other programs like WinRAR etc.? As far as I've seen WinRAR (4.20 x64 and 5.60 x64) does not refuse to start if replacing it's default unacev2.dll with your fixed one. Though I cannot verify its functionality, as your ACE-Testfile "https://plugins.ghisler.com/test/testfile.ace" won't extract with winrars default unacev2.dll, nor with your fixed one. Although, I can open your ace-archive in winrar with default winrar unacev2.dll as well as with the fixed one, hence I can browse the archive up to the file testfile.ace\C:\C:C:..\b\b.txt. I just cannot extract it, which means I cannot verify the functionality of your fixed unacev2 file.

Perhaps you can share some thoughts about this? Would be interesting if your fixed file could be applied to other programs vulnerable to this security bug.

[MVV]

BTW I can't view b.txt from mentioned test archive with Lister or extract with drag-and-drop. Shouldn't TC allow manual extracting it?

I'm trying to view b.txt with Lister, TC says about disk error, and I don't see any write operations for b.txt in Process Monitor, it looks like TC doesn't even try to unpack the file into temp dir.

And, what is funny, I've opened this archive in old WinRAR 4.20, and it is unable to extract it. And I can't extract it using TC 9.21a with old DLL.


ghisler(Author),
BTW, I've compared old and fixed DLLs, don't you want to fill with 0x90 or 0xCC unused instructions after inserted RET instruction in patched chunk? Byte 0x5C at address 0x0040CBFF (file offset 0xBFFF) is now looks like a POP ESP instruction (last byte of partially overwritten instruction), and some next instructions has no sense until push instruction at address 0x0040CC0E (file offset 0xC00E) which is a target for JZ instruction at address 0x0040CC00 (file offset 0xC000).

[ghisler(Author)]

Would your modifications also apply successfully (from security perspective) to other programs like WinRAR etc.?

Yes they would! All they cause is that the extraction is immediately aborted when ../ or ..\ is encountered in a file to be extracted.

I'm trying to view b.txt with Lister, TC says about disk error, and I don't see any write operations for b.txt in Process Monitor, it looks like TC doesn't even try to unpack the file into temp dir.

That's intentional. Why? "..\" has no purpose in regular archives. So if it is there, it most probably means that the file is malicious. That's why the DLL now simply aborts the unpack progress. I could have tried to patch a better function to remove the ..\, e.g. remove it even if it's not at the start of the string and not \..\ or /../, but I didn't want to risk another possible security hole. That's why aborting is in my opinion the best solution.

don't you want to fill with 0x90 or 0xCC unused instructions

I could, but it doesn't make a difference for the processor since that code is never called. It only makes a difference for other users disassembling the dll.

[MVV]

I could, but it doesn't make a difference for the processor since that code is never called. It only makes a difference for other users disassembling the dll.

That's correct, of course, but it would look a bit more elegant.

That's intentional. Why? "..\" has no purpose in regular archives. So if it is there, it most probably means that the file is malicious.

Ok, I get your point, you prevent extraction of such a suspicious file to protect users.

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

I've tested this archive with TC 9.22rc1 and old UNACEV2.DLL, during extraction it creates folder but don't extract file.

[infinity]

@MVV

I've had the very same observations. My WinRAR 4.20 (x64) would open the Test-ACE with old unacev2.dll, but would not extract or execute the contained b.txt within the archive. It would always show an error message - that being said with unpatched unacev2.dll.

If using the patched unacev2.dll it behaves the exact same way. So I'd say this ACE-test-archive is not suited for testing WinRAR. The old WinRAR 4.20 seems not to be vulnerable for this kind of example-case. For testing WinRARs vulnerability we'd need a test-file with some other special-case of \/ paths or so, hence another test-file, which would harm the original unacev2.dll but not be harmful with patched unacev2.dll anymore.