Created attachment 7407 [details]
clamd std log

Created attachment 7408 [details]
db packer.yar for example

Marking as public so it can be referenced in the clamav-users list.  
In addition, we have an internal (Jira) task to follow up on this issue.

Another user reported crash due to clamav handling of yara rule sets.
Source:
 clamav-users: http://lists.clamav.net/pipermail/clamav-users/2018-May/006185.html

*** Bug 12117 has been marked as a duplicate of this bug. ***

Created attachment 7427 [details]
Clamscan crash log

I'm also using clamav-unofficial-sigs.sh, and I'm having clamscan crash.

crash log says:

Application Specific Information:
Assertion failed: (sp =3D=3D 0), function yr_execute_code, file =
yara_exec.c, line 177.

Have attached it.

In my case, clamav is used for the mail traffic (amavis, postfix, dovecot) and the webproxy (squid over c-icap).
Hardware: Intel xeon, 24GB ECC-Ram, Raid5.
System: ArchLinux
After the update to clamav 0.100 it came to coredums and the accesses to the Internet over the squid-proxy became unbearably slow.
The following steps helped me to get the system working almost normally again. However, the system load on the CPU is considerably higher with clamav 0.100 than with clamav 0.99.4.
But at least I can now use the system again, without having to turn off the virus protection altogether. There are about 30 workstations on the system that use the mail server and the proxy.

Here are my steps:

1. Delete all signature databases that are located (in my case) under /var/lib/clamav.
2. Manual freshclam for the standard signatures
3. Setting default_dbs_rating="LOW" in /etc/clamav-unofficial-sigs/user.conf
4. Forcing reloading the signature databases with clamav-unofficial-sigs.sh -F

I use the following external sources:

sanesecurity_enabled = "yes"
securiteinfo_enabled = "yes"
linuxmalwaredetect_enabled = "yes"
malwarepatrol_enabled = "yes"
yararulesproject_enabled = "yes"
additional_enabled = "yes"

Maybe these steps will help you too.

*** Bug 12103 has been marked as a duplicate of this bug. ***

It seems to me that the assertion fail 'crash' when using antidebug_antivm.yar comes about after this commit:

https://github.com/Cisco-Talos/clamav-devel/commit/5891f83422e699f70e9f9bdcbcc9633f9a4cd5ef

Derived from:
https://bugzilla.clamav.net/show_bug.cgi?id=11567

I am guessing that what's going on is that before the change, it would abandon antidebug_antivm.yar rules when any of them failed to load, and that with the change, it only skips the ones that fail to load. 

Before the change, I see:
LibClamAV Error: cli_loadyara: failed to parse rules file /Users/micasnyd/antidebug_antivm.yar, error count 7

With the change, I see:
LibClamAV Warning: cli_loadyara: failed to parse or load 7 yara rules from file /Users/micasnyd/antidebug_antivm.yar, successfully loaded 92 rules.

I haven't yet taken the time to identify which rules in antidebug_antivm.yar are failing, remove them, and verify if one of them still causes a crash in 0.99 and 0.100

I agree that previously it looks as if the files failed to compile and as a result were ignored with the annoying side effect of the error messages coming out on stderr and appearing in places they shouldn't.

I think that it's more than a little worrying that it's possible for uploaded .yar files to take out a running production clamd daemon.

I would like to be able to compile the code with NDEBUG off - so that the assertions in the code don't trigger the abort signal. I've never had to get to grips with configure - it seems to always define NDEBUG as on - even when --enable-debug is not included.

I tried --enable-debug=no which theoretically should do reverse the sense of the option, but to no avail.

There does seem to be considerable magic involved with the setting of debug flags in the compilation system.

Hello , 
I have have this report https://bugzilla.redhat.com/show_bug.cgi?id=1590545 , and IMO we need a quick fix for clamav-0.100 ...

(In reply to Micah Snyder from comment #10)
(...)
> I haven't yet taken the time to identify which rules in antidebug_antivm.yar
> are failing, remove them, and verify if one of them still causes a crash in
> 0.99 and 0.100

for me crash just happens with 0.100 and just clamav-unofficial-sigs .
i.e , nobody complains about it in 0.99.[34]

My understanding (someone correct me if I'm wrong) is that the yara ruleset/database in question has been broken for a long time.  

In 0.99.x some of the rules failed entirely, so the entire database was dropped.  In 0.100, some of the rules failed, but it now allows it to partially load the ones that didn't outright fail.  However, there appears to be a bug wherein at least one that is getting loaded is causing a crash.  

Frankly, from my perspective this is an annoying bug that I want to fix, but it isn't a top priority because the yara ruleset in question didn't work with ClamAV from the get-go and therefore shouldn't have been published.  

Using 3rd party signature databases is purely optional, so it isn't exactly a security flaw.  I'd like to fix the yara parsing issues for 0.101, but I have no expectation of fixing it in an 0.100 patch release.

My solution to this was to remove the offending file from clamav-unofficial-sigs control file.

Change /etc/clamav-unofficial-sigs/master.conf to comment out the offending line:

#Antidebug_AntiVM/antidebug_antivm.yar|LOW # anti debug and anti virtualization techniques used by malware

and of course remove installed files. I had the advantage of compiling my own version of clamav and then could back up easily. This is not that easy of you are using yum packaged releases.

However, it is the case that if 100.0 is released for EPEL and used on systems where this file is installed - then clamd will just die.. and the ensuing complaint levels may not be good. Sadly it will look like a fault in clamd - and actually we are used to having faultless releases from you guys.

I don't know you already know but just in case, antidebug_antivm.yar and EMAIL_Cryptowall.yar makes clamav-0.100 crashes  

[1]
https://github.com/extremeshok/clamav-unofficial-sigs/issues/203

It wasn't quite clear at the offset of this bug, but ClamAV cannot support unofficial signatures from a development standpoint. For numerous reasons, we do not regress against those signatures, and in cases where sig writers publish non-functional signatures due to insufficient testing (which then cause crashes in newer versions of clam) we cannot devote our resources to fixing that problem.

We can only urge users to be more selective in which signature set they decide to trust, and ask sigwriters to push an update which removes the offending sigs.

All that said, we definitely encourage sigwriters to submit their signatures to undergo our official QA, signing, and distribution process. https://www.clamav.net/contact#partners

I don't want to dwell on "what could have beens", but if the writer of these sigs had taken advantage of our partner program, I imagine this problem would have been sussed out and fixed long ago.

Leaving this open for now, as we clearly have a bug in yara rule parsing. No promise on timeline. Please don't schedule around this issue.

Confirming that this is still an issue in 0.103.2, although it's happening not with third-party Yara rulesets but with my own, which should make it easier to investigate.  The crashes which I'm seeing seem to happen when clamd performs a scan after loading the breaking rules, not when it loads them.  Sometimes the rules are perfectly well-formed Yara syntax, which when written another way do not cause a crash.  For example version 140 of one of my rulesets causes a crash but version 141 does not:

8<----------------------------------------------------------------------
$ diff -U3 Garbage_Rules.yar.~140~.NBG Garbage_Rules.yar.~141~.OK 
--- Garbage_Rules.yar.~140~.NBG 2021-06-13 08:05:54.218256634 +0100
+++ Garbage_Rules.yar.~141~.OK  2021-06-13 08:08:11.025783287 +0100
@@ -30,7 +30,7 @@
    strings:
        $ = /update from GOV.{1,10}UK/ ascii nocase
        condition:
-               any of them and not Blacklist_1
+               not Blacklist_1 and any of them
 }
8<----------------------------------------------------------------------

I'm up to five different issues at the moment, not all crashes.  I'll keep track of them in my own way locally unless someone from the ClamAV team asks me to note the other examples here.

AFAICT we're still at Yara version 2 with ClamAV and it's flaky.  Is there any prospect in the foreseeable future of the code being brought up to date, to something like Yara version 4?  Is it a matter of pulling a bunch of code from some other project and shoe-horning it into the clamav codebase?  What sort of effort would that be likely to take?  It might be better to go for that than to try to fix broken code which is already well past its best-before date.

Ged.

(In reply to Ged from comment #17)

> Is it a matter of pulling a bunch of code from some other project and shoe-horning it into the clamav codebase? 

Yeah this is the gist of it. ClamAV uses Yara's lexer and grammar source plus some headers.  We are sorely out of date.  Updating these may resolve the parsing crashes.  If not, we should dig into those to ensure they're fixed.  

The scanning crashes you're seeing are not something I'm familiar with, and would probably not be resolved by updating to newer yara syntax parser code.  We don't use libyara to actually perform the matching (scan). We use our own pattern matchers. 

This is a bit of a digression, but I'm also interested in finding a space efficient way to transform .yara rules into a single-line-text format that we could include in CVD's in the future (e.g. a new .ydb database file format).  Our own malware research team has shown interest in publishing yara signature content, and currently can't due to limitations in we how we build CVD database archives.  We'd definitely need to update and stabilize yara support first.

Simplified down, this file with these two rules triggers the issue:

rule rule_with_error_in_condition
{
	strings:
		$str1 	= "abcd1234" ascii

	condition:
		all of ($str*) and blah
}

rule rule_no_error
{
	strings:
		$str1 	= "abcd1234" ascii

	condition:
		any of ($str*)
}

The first rule has a parse error and fails to load, but the second is loaded. Something appears to be improperly cleaned up, so when matching with the second rule, it triggers this assert: https://github.com/Cisco-Talos/clamav/blob/main/libclamav/yara_exec.c#L177

I suspect the improperly cleaned up stuff is within yyparse(), defined in here: https://github.com/Cisco-Talos/clamav/blob/main/libclamav/yara_grammar.c#L1453

I wasn't able to get my debugger to step in to this generated code though, and it's a huuuuge function, pulled from the Yara project. I'd rather figure out how to upgrade the Yara code to the latest from the Yara project before trying to debug this old code.

But we can at least prevent this crash by complaining about the unexpected stuff in the instruction stack instead of crashing with an assert. Eg:

-        assert(sp == 0);
+        if (sp != 0) {
+          cli_dbgmsg("error executing yara rule, stack should be empty when halt instruction reached\n");
+          return CL_EPARSE;
+        }

Here's a PR to resolve the crash: https://github.com/Cisco-Talos/clamav/pull/261

(In reply to Ged from comment #17)

> I'm up to five different issues at the moment, not all crashes.  I'll keep
> track of them in my own way locally unless someone from the ClamAV team asks
> me to note the other examples here.

I'd be happy to see the other yara issues you've uncovered.  I don't know when I or someone else will investigate, but it would be good to document these other issues.

We've just fixed this specific issue in a PR merged into main, for 0.105, and cherry-picked back to be included in 0.103.4 and 0.104.1:
https://github.com/Cisco-Talos/clamav/pull/261