Problem with a rfxn.yara rule, and mismatch with downloaded rfxn.yara vs upstream version

[taggart]

Today I was tracking down a problem I was having with a particular rule taking a long time to process a file. I eventually narrowed it down to a rule in rfxn.yara and then narrowed it down to the rule named "Backdoor_PHP_WPVCD_TempExecution".

The file is question is something we detected on our mailserver because it was taking so long to process it was exceeding the 120s timeout. To repeat, create a file containing 5000000 "1"s all on a single line, and then base64 encode it. On our server this rule takes over 2 minutes to process. That is the first problem...

So I decided to check if maybe there was a bug in that rule that had been fixed. I see that clamav-unofficial-sigs pulls this ruleset from https://cdn.rfxn.com/downloads/maldet-sigpack.tgz (and I downloaded to check and the above rule is in there). But if I download the current release listed on https://www.rfxn.com/projects/linux-malware-detect/ (which is http://www.rfxn.com/downloads/maldetect-current.tar.gz ) and compare it's maldetect-1.6.4/files/sigs/rfxn.yara with the unofficial-sigs downloaded version, I see some differences including that rule (and some with similar names) are missing.

So maybe the LMD release process isn't properly updating one of them? I don't know which one is considered the latest. But I do know that "Backdoor_PHP_WPVCD_TempExecution" has a potentially DoS'able bug, so if that rule is supposed to be in there it needs some adjusting.

Thanks

[taggart]

I just realized maybe this was solved with #269 and the 7.2.5 release? It looks like maybe there's a find ! command that strips rfxn.yara.

[extremeshok]

https://cdn.rfxn.com/downloads/maldet-sigpack.tgz is the latest.

"http://www.rfxn.com/downloads/maldetect-current.tar.gz " rules were last updated in 2019.

If you are using the latest version, you are able to whitelist the yararule.

[taggart]

Does the whitelist prevent the rule from running, or just ignore a positive result? In the case I found, clamav eventually completes with a negative result, so the problem is just the 2-3 min runtime (which exceeds clamav-milter's ReadTimeout of 120s).

As a workaround for now, I could make my own version of maldet-sigpack.tgz with that rule removed and override linuxmalwaredetect_sigpack_url with my own copy. Unless there is a better way to turn off just that rule.

I could not find an issue tracker for LMD so I mailed ryan@r-fx.org details about the rule directly.

[extremeshok]

whitelist prevents the rule from triggering, I assume clamav will still process the rules.

I started work on filtering and verifying yara rules, but yara rules are far to diverse in how they are written and formatted. Unless I have allot of free time (or paid time), I cant see that being completed any time soon

[extremeshok]

What would be a solution ?

[taggart]

Because c-u-s downloads the rule sets and give them to clamd, I guess maybe there could be a way to exclude particular rules from even being run?
My mail to ryan@r-fx.org about the broken rule just bounced back after 14 days.