updates

[BigMike]

Hi,
I guess PowerArchiver and PACL are also affected by this:
https://research.checkpoint.com/extracting-code-execution-from-winrar/

The vulnerability is inside UnAceV2.dll, which is also used by PowerArchiver and PACL.
As a result of these vulnerabilities, WinRAR dropped ACE support.

Could you please have a look and also take action.

[spwolf]

@BigMike We go the files from Christian over the weekend, but we could not reproduce them being sent to wrong path, so thank you for testing. We have issued updates for all PowerArchiver setups over the weekend, so you can get latest update via our website. Should be going up on PB later today.

[spwolf]

@BigMike said in Security vulnerability in UnAceV2.dll:

Hi,
I guess PowerArchiver and PACL are also affected by this:
https://research.checkpoint.com/extracting-code-execution-from-winrar/

The vulnerability is inside UnAceV2.dll, which is also used by PowerArchiver and PACL.
As a result of these vulnerabilities, WinRAR dropped ACE support.

Could you please have a look and also take action.

someone already reported it to us via email… preliminary look says that at very minimum we are not affected in the same way (we cant reproduce it on our system yet), but need to test more.

Main problem is path handling, and with proper filtering from our side, it should not be an issue. Of course, easiest action is to simply delete ace dll and do no work other than that.

[BigMike]

Thank you for the quick response.
It’s really nice to hear, that you’re already aware and testing.
For sure, having a workaround and keep ACE support would be the preferable over removing the dll and abandoning ACE archives completely.

[spwolf]

@BigMike said in Security vulnerability in UnAceV2.dll:

Thank you for the quick response.
It’s really nice to hear, that you’re already aware and testing.
For sure, having a workaround and keep ACE support would be the preferable over removing the dll and abandoning ACE archives completely.

it is “easier” if they find something in PA specifically, since we get full report that is not published and example of archive that reproduces the issue.

edit: also they give between 20 and 40 days time between reporting the issue (to WinRar) and publishing it (today). So WR team knew about this 20-40 days ago.

[BigMike]

Sure, I guess almost any product supporting ACE archives could be affected, as most of them will rely on the provided closed source UnAceV2.dll instead of trying to implement an own solution.

But as I’m using your products and not any other, my primary interest is, that you are aware of the issue and ensuring, that your products are save. And I know it will be hard, if you don’t have an example to test the issue.

To be honest, I used WinAce myself a long time ago, but I doubt I have any ACE archives around. So I guess dropping support is really a good option if it would take much work to mitigate the issue. There are really good alternatives available now. Your PA format for own use - or 7z if you like to use a “common” format.

[spwolf]

@BigMike said in Security vulnerability in UnAceV2.dll:

Sure, I guess almost any product supporting ACE archives could be affected

every product has different path filtering already, it was a problem showing up many times before with various different formats.

Question is just what else can be found… we will be removing ace support until we can add our new dll.

[BigMike]

Hi,

just to let you know: If you can’t get the original example from CheckPoint, maybe you’ll like to contact the author of Total Commander. In this forum post the author of Total Commander tells, that he managed to create a test archive on his own and also already found a workaround.
In the very same thread, he published his example.

My results with:
PowerArchiver 2018 x64 18.01.04 and its Shell Extension (“extract here” and “extract to <archive name>”):
There, the file seems to be simply skipped (but I get no error, that there was something wrong)

PowerArchiver 2019 x86 19.00.30 and its Shell Extension
Shell Extension: Gives me errors, but extracts the file to the traversal path and therefore is affected (both cases)
PowerArchiver: Also gives me an error, but then extracts the file to the traversal path and is affected.

With PACL 9.00b
paext64 seems also to skip the file
paext32 extracts the file to the very same folder (ignoring the traversal path)

[spwolf]

@BigMike We go the files from Christian over the weekend, but we could not reproduce them being sent to wrong path, so thank you for testing. We have issued updates for all PowerArchiver setups over the weekend, so you can get latest update via our website. Should be going up on PB later today.

[BigMike]

Did you test with a x86 OS/PowerArchiver. As I wrote, I was able to reproduce the issue (only) in the x86 version.

But thank you for your quick action.

[spwolf]

@BigMike said in Security vulnerability in UnAceV2.dll:

Did you test with a x86 OS/PowerArchiver. As I wrote, I was able to reproduce the issue (only) in the x86 version.

But thank you for your quick action.

yeah, ace.dll was 32bit only so it worked in 32bit versions of PA only. But couldnt reproduce it, regardless of that we have removed it for now. Thanks for the testing and checking!

[BigMike]

Actually, the new behavior may lead to some confusion if a user doesn’t know about this issue.

The new versions can open ACE archives and display the contents. (I guess, this is your own code).
Trying to extract via command line (PACL), shell extension or dialogs (PowerArchiver) fails silently without an error/information message.

Trying to extract via drag and drop will create 0 byte files, while the correct file sizes are displayed in the archive. Again, no error/information message.

Could you please either add a message or remove the support for this format completely?

[drteeth]

FWIW, I have been heavily into computing since April 1992 and was online well before the internet was even around and have never come across an ACE archive.

[BigMike]

I used ACE format for my own file storage, years ago. There was a time, when ACE had very good compression ratios compared to other formats.
But as you say, it was pretty unknown for most people and therefore not suited for common file exchange. As 7z is wide spread and has good ratios, I mostly use this format.

But this doesn’t change the point of my last post. At least a message should be displayed, that extracting files from ACE archives isn’t supported anymore, to not confuse users.

[spwolf]

@drteeth @BigMike ACE was pretty big 15-20 years ago, it was neck to neck with RAR for a long time…

[BigMike]

@spwolf Just to let you know:
ghisler, the author of Total Commander, managed to patch UnAceV2.dll, so that the path traversal attacks fail:
Post with the patched dll

Explanation, what was changed (German)

You wrote, you weren’t able to reproduce the issue at all.
I was able to reproduce it with ghisler’s test file (just rechecked with PA 19.00.30, x86)…
I’ve tested his patched dll with the very same version. The issue seems to be fixed here.
The extraction of a malicious ace file silently fails as described. A “good” ace archive extracts as expected.

I’m not sure if adding ACE support again, is wise.
It’s an pretty old format and maybe the next vulnerability couldn’t be fixed, as there’s no source code for the dll and no official support for years. And it’s not working in x64 anyway.

But if you like, there would be a possibility.

[spwolf]

@BigMike Christian sent us that patch info right away, super nice guy, but for us the problem is as you say that someone could discover some other vulnerability and we would have the same problem, so it is too risk for , as you say, an old little used format that doesnt work on x64 anyway.

thanks!

[WHITE]

Thank you for sharing the information it was helpful.