search

Cisco-Talos / clamav

ClamAV - Documentation is here: https://docs.clamav.net
https://www.clamav.net/
GNU General Public License v2.0
4.28k stars 693 forks source link

Upgrade 7-Zip version? #580

Open teoberi opened 2 years ago

teoberi commented 2 years ago

Describe the bug

The 7-Zip version included in Clamav 0.105.0 is 9.20 from 2010-11-18 (https://github.com/Cisco-Talos/clamav/blob/main/libclamav/7z/7zVersion.h) The latest stable version is 21.07 according to the history.txt Is there any particular reason why the latest 7-Zip version is not used with all updates including security updates?

micahsnyder commented 2 years ago

We've been procrastinating upgrading the 7z LZMA-SDK for many years largely because of significant customizations made to our vendored copy back in the 2011-2012 time-frame.

We intend to switch from the C version to the C++ version soon, to get some additional features (see: https://github.com/Cisco-Talos/clamav/issues/542). We will of course pick up the latest version during that switch.

teoberi commented 2 years ago

What @HenkPoley says in #542 may also apply to the use of codecs not yet included in Igor Pavlov's original 7-Zip version. Viruses that pass the Clamav scan can be packaged this way. For the 7-Zip version 21.07 by Igor Pavlov

Codecs: 4ED 303011B BCJ2 EDF 3030103 BCJ EDF 3030205 PPC EDF 3030401 IA64 EDF 3030501 ARM EDF 3030701 ARMT EDF 3030805 SPARC EDF 20302 Swap2 EDF 20304 Swap4 ED 40202 BZip2 ED 0 Copy ED 40109 Deflate64 ED 40108 Deflate EDF 3 Delta ED 21 LZMA2 ED 30101 LZMA ED 30401 PPMD D 40301 Rar1 D 40302 Rar2 D 40303 Rar3 D 40305 Rar5 EDF 6F10701 7zAES EDF 6F00181 AES256CBC

For the 7-Zip version 21.07 by cielavenir

Codecs: 4ED 303011B BCJ2 EDF 3030103 BCJ EDF 3030205 PPC EDF 3030401 IA64 EDF 3030501 ARM EDF 3030701 ARMT EDF 3030805 SPARC EDF 20302 Swap2 EDF 20304 Swap4 ED 40202 BZip2 ED 0 Copy ED 40109 Deflate64 ED 40108 Deflate EDF 3 Delta ED 21 LZMA2 ED 30101 LZMA ED 30401 PPMD ED 4F71101 ZSTD ED 4F71104 LZ4 ED 4F71102 BROTLI ED 4F71106 LIZARD ED 4F71105 LZ5 ED 4F71001 LZHAM D 40301 Rar1 D 40302 Rar2 D 40303 Rar3 D 40305 Rar5 EDF 6F10701 7zAES EDF 6F00181 AES256CBC ED 4010A PKImplode ED 21 FLZMA2

teoberi commented 2 years ago

7-Zip 22.01 Upgrade from UnRAR 6.0.7 -> 6.1.7 (fix a path traversal vulnerability). Compile failure with llvm 14. With all these 3 problems solved we will be able to use Clamav again (which is now suspended).

micahsnyder commented 2 years ago

@teoberi we am working on the UnRAR upgrade (https://github.com/Cisco-Talos/clamav/pull/634) and will include it in patch versions for 0.103, 0.104, and 0.105 in the coming week(s).

The other issues (llvm14, and 7zip) are not critical and should not prevent anyone from using ClamAV:

teoberi commented 2 years ago

Fair enought, I will wait for that. Building with the bytecode interpreter generates quite a few warnings, I avoided this in the last builds. Regarding to 7-zip, I consider that the update to the latest version (now that the 7-zip development is going quite well) is necessary and important. On my servers I use Clamav integrated in Amavis to scan email messages together with a commercial solution from Sophos which will have EOL next year. So I still have time to wait for Clamav to fix this problems if it will remains the only solution for my operating system (Slackware).

micahsnyder commented 2 years ago

I did some additional research today. I found the blog post describing the unrar CVE. https://blog.sonarsource.com/zimbra-pre-auth-rce-via-unrar-0day/

After some intense debugging and reading over the article, I think we may actually be affected by this CVE, but ONLY when using the --leave-temps option. I was able to modify a test.rar RAR archive and change the name of an embedded file to have the name ..\..\../t. In my testing that caused it to try to extract to this path:

unrar_extract_file: Extracted file to: /tmp/20220721_101601-test.rar.051dfeb4f4/test.rar.be3b9aca25/..\..\..\t.ae45e02c57

According to the blog post, the bug in libunrar is specifically for symbolic links, though. For these, it will convert those backslashes after they're passed in to the extraction function over to / which turns them into actual path separators which means writing outside the temp directory. My very brief review of the libunrar code confirms this. For ClamAV's use of libunrar, we append a hash suffix, like you see above (t.ae45e02c57), so even if you can get the path traversal issue to affect ClamAV in --leave-temps-mode, would be highly unlikely to be useful.

When not using --leave-temps, the filename for the extracted file is totally random, so it extracts here instead:

unrar_extract_file: Extracted file to: /tmp/20220721_104349-scantem.3f66db77da/clamav-1c8d878fa9dbe5535b71297e49fa100b.tmp

That is excellent. Almost nobody uses --leave-temps except when using clam to analyze files, or when debugging a ClamAV bug.

TL;DR: ClamAV appears to be only very very slightly affected. It is still best for us to to upgrade libunrar in ClamAV, and I will continue to work on getting that done for a patch release next week.

micahsnyder commented 8 months ago

For reference: From discussion in discord on 2023/12/16, @CTRLRLTY is working on this.

teoberi commented 8 months ago

I'm glad to know that!

I would be even more happy if the support for LLVM 14+ would also be resolved!

micahsnyder commented 8 months ago

Re: LLVM 14+ support, it's on our radar but actively focusing on LLVM 14+ support for the bytecode compiler, first. And after that we have to focus on some archive support improvements before we can look at it. So it's a ways down the backlog.

Others are welcome to help if they want -- though you can also use the bytecode interpreter for bytecode functionality whenever LLVM is not available.

Sanesecurity commented 6 months ago

Just to add useful 7zip feature updates...

HISTORY of the 7-Zip

24.01 2024-01-31