Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Yara keywords (uint32be & others) are not supported by (Lib)ClamAV yet... #606

Open
pettai opened this issue May 31, 2022 · 3 comments
Open

Comments

@pettai
Copy link

pettai commented May 31, 2022

Describe the bug

uint32be is Yara keyword that has been around since 2014 (Yara v3.2.0) and is used in some yara-rules to find malicious contents, however these rules cannot be utilized by ClamAV yet today...

This has been reported at other places too:
https://forums.gentoo.org/viewtopic-t-1035172-start-0.html
https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1883857
https://www.mail-archive.com/clamav-users@lists.clamav.net/msg41480.html
extremeshok/clamav-unofficial-sigs#384

How to reproduce the problem

Download https://raw.githubusercontent.com/Yara-Rules/rules/56c5e06b41fb9a6e8331600d2ab136d426c52bf6/maldocs/Maldoc_CVE_2017_11882.yar

~ % clamscan -V
ClamAV 0.105.0

~ % clamscan -d Downloads/Maldoc_CVE_2017_11882.yar a_doc_file.doc
LibClamAV Error: yyerror(): Downloads/Maldoc_CVE_2017_11882.yar line 18 undefined identifier "uint32be"
LibClamAV Warning: cli_loadyara: failed to parse or load 1 yara rules from file Downloads/Maldoc_CVE_2017_11882.yar, successfully loaded 0 rules.
LibClamAV Warning: cli_loadyara: empty database file
Compiling:   0s, ETA:   0s [========================>]       40/40 tasks

~ % clamconf -n
Checking configuration files in /opt/homebrew/etc/clamav

clamd.conf not found

freshclam.conf not found

clamav-milter.conf not found

Software settings
-----------------
Version: 0.105.0
Optional features supported: MEMPOOL AUTOIT_EA06 BZIP2 LIBXML2 PCRE2 ICONV JSON RAR

Database information
--------------------
Database directory: /opt/homebrew/Cellar/clamav/0.105.0/share/clamav
WARNING: freshclam.conf and clamd.conf point to different database directories
Total number of signatures: 0

Platform information
--------------------
uname: Darwin 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:46:32 PDT 2022; root arm64
OS: Darwin, ARCH: arm64, CPU: arm64
zlib version: 1.2.11 (1.2.11), compile flags: a9
platform id: 0x040396960800000000040201

Build information
-----------------
Clang: Apple LLVM 13.1.6 (clang-1316.0.21.2) (4.2.1)
sizeof(void*) = 8
Engine flevel: 150, dconf: 150

Attachments

You'll find some yara-rules with this yara-keyword that won't load here:
https://github.com/Yara-Rules/rules/search?q=uint32be&type=code
and some more here:
https://github.com/Neo23x0/signature-base/search?q=uint32be&type=code

@micahsnyder
Copy link
Contributor

Yara's uint32be() feature is a really neat feature. ClamAV offers a similar capability through the "byte compare" subsignature for logical signatures: https://docs.clamav.net/manual/Signatures/LogicalSignatures.html#byte-compare-subsignatures
ClamAV's byte compare feature allows not only raw byte comparison with different endianness, signedness, and byte width. And it also enables evaluation from decimal text and hex text numbers instead of evaluating the raw bytes.

But ClamAV's byte compare feature requires a different pattern as a trigger, with an offset from the start of that pattern match, so unfortunately it will not translate directly to Yara's uint32be() feature. That is, I don't expect we can simply map the Yara functionality to ClamAV's functionality the way we have with Yara's text and regex pattern matching. Adding the Yara feature would therefore require an entirely new feature in ClamAV to evaluate bytes at an exact offset without anchoring to a pattern match, and so is unlikely to happen soon. I'm not saying it's not a great request, just that it's not an easy translation from an existing ClamAV signature feature.

@pettai
Copy link
Author

pettai commented Jun 2, 2022

Thanks for your insights @micahsnyder

I see this mainly as an usability feature with ClamAVs Yara-scan support.
New Yara-rules tend to utilize the full yara keyword "palette", and then it becomes hard to just grab and utilize the yara rules supplied form various sources nowadays, so ClamAV users have to spend time on converting them to fit (or just give up because lack of knowledge etc.)

(btw. I also noted that the documentation at https://docs.clamav.net/manual/Signatures/LogicalSignatures.html#byte-compare-subsignatures lacks examples, that would also be helpful to provide)

@micahsnyder
Copy link
Contributor

Agreed! It definitely needs more examples. A lot of the signature types do, in fact. :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants